fix(aws-auth): follow full credential chain and honor AWS_DEFAULT_REGION - #75
fix(aws-auth): follow full credential chain and honor AWS_DEFAULT_REGION#75ozpool wants to merge 1 commit into
Conversation
RetrieveAwsCredentials only returned the credentials resolved by the default provider chain when a region had already been detected. When the region was unknown it fell through to GetAwsRegion, which queries the EC2 instance metadata service directly. On ECS Fargate there is no instance metadata endpoint, so aws-iam auth failed even though valid task-role credentials were available via AWS_CONTAINER_CREDENTIALS_RELATIVE_URI (or plain AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY env vars). Resolve credentials from the standard provider chain unconditionally, and only look up the region separately: SDK config first, then AWS_REGION / AWS_DEFAULT_REGION, and the metadata service last. Region detection no longer short-circuits credential resolution. GetAwsRegion now also honors AWS_DEFAULT_REGION before reaching for IMDS.
|
| Filename | Overview |
|---|---|
| packages/util/auth.go | Credentials are now always resolved via the AWS SDK provider chain before region is consulted; region falls back through SDK config → env vars → EC2 IMDS. The raw IMDS call in GetAwsEC2IdentityDocumentRegion still does not respect AWS_EC2_METADATA_DISABLED. |
| packages/util/auth_test.go | New unit tests cover AWS_REGION precedence and AWS_DEFAULT_REGION fallback using t.Setenv for safe isolation; no issues found. |
Comments Outside Diff (1)
-
packages/util/auth.go, line 209-218 (link)SSRF note — raw IMDS HTTP call still reachable
GetAwsEC2IdentityDocumentRegionmakes two raw HTTP requests to169.254.169.254(the link-local EC2 Instance Metadata Service). The URLs are hardcoded constants so there is no user-controlled redirect, but the function is now the last-resort fallback for any caller — includingRetrieveAwsCredentials— on every platform that lacksAWS_REGION/AWS_DEFAULT_REGION. In a non-EC2 network environment a misconfigured or attacker-controlled routing table could theoretically redirect169.254.169.254to an internal endpoint. The risk is low in practice (link-local is typically not routable), but worth acknowledging in the context of the custom instruction to flag SSRF vectors.Context Used: Flag SSRF risks (source)
Reviews (1): Last reviewed commit: "fix(aws-auth): follow full credential ch..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| if awsRegion == "" { | ||
| awsRegion, err = GetAwsRegion() | ||
| if err != nil { | ||
| return aws.Credentials{}, "", err | ||
| } |
There was a problem hiding this comment.
AWS_EC2_METADATA_DISABLED still bypassed for region resolution
The PR correctly moves credential retrieval through the AWS SDK (which honours AWS_EC2_METADATA_DISABLED=true), but when awsCfg.Region is empty the fallback reaches GetAwsRegion() → GetAwsEC2IdentityDocumentRegion, which issues a raw resty HTTP request to 169.254.169.254. That raw call does not check AWS_EC2_METADATA_DISABLED, so an operator who disables IMDS but forgets to set AWS_REGION / AWS_DEFAULT_REGION will still see a timeout attempt against the metadata service in the region-resolution path. Credentials succeed; region resolution hangs until the 5-second timeout fires and then returns an error.
For ECS Fargate the fix is sufficient as long as a region env var is set, but the IMDS-disabled bypass is a residual gap worth documenting (or mitigating by checking the env var before the raw HTTP call).
|
Hi @varonix0 — gentle first nudge on this one, no rush. It's been green since open (GitGuardian + Greptile pass) and fixes aws-iam auth on ECS Fargate, where there's no instance-metadata endpoint so the current region-detection path fails even with valid task-role / env credentials. The change just follows the full AWS provider chain and honors AWS_DEFAULT_REGION before falling back to IMDS. Happy to rebase or add a test if useful. |
📝 Contributor License Agreement requiredBefore this PR can merge, every contributor must sign the Infisical CLA. Still needs to sign: Once everyone has signed, the check updates automatically — no need to close and reopen the PR. |
1 participant
Description
RetrieveAwsCredentialsonly returned the credentials resolved by the default AWS provider chain when a region had already been detected. When the region was unknown, it fell through toGetAwsRegion, which calls the EC2 instance metadata service (169.254.169.254) directly.On ECS Fargate there is no instance metadata endpoint, so aws-iam auth failed even when valid credentials were available — task-role credentials via
AWS_CONTAINER_CREDENTIALS_RELATIVE_URI, or plainAWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEYenv vars. SettingAWS_EC2_METADATA_DISABLED=truedidn't help because the metadata call is a raw HTTP request rather than going through the SDK.This was reported for the CLI in Infisical/infisical#6523; the CLI delegates aws-iam login to this SDK, and the KMIP/gateway/relay flows call
RetrieveAwsCredentialstoo, so they share the same gap.Changes
RetrieveAwsCredentials: resolve credentials from the standard provider chain unconditionally (env vars → shared config → ECS/EKS container credentials → EC2 IMDS), then resolve the region separately. Region detection no longer short-circuits credential resolution, so an environment without IMDS still authenticates as long as credentials are present.AWS_REGION→AWS_DEFAULT_REGION→ EC2 metadata service.GetAwsRegion: honorAWS_DEFAULT_REGIONin addition toAWS_REGIONbefore reaching for IMDS.Testing
Added unit tests for the region precedence (
AWS_REGIONoverAWS_DEFAULT_REGION, and theAWS_DEFAULT_REGIONfallback).go build ./...,go vet ./packages/util/and the new tests pass locally.