-
Notifications
You must be signed in to change notification settings - Fork 244
Add support for AWS_CONTAINER_CREDENTIALS_FULL_URI (EKS Pod Identity Agent) #449
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
LockedThread
wants to merge
8
commits into
durch:master
Choose a base branch
from
LockedThread:master
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 5 commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
e17241a
Add support for EKS Pod Identity
LockedThread 6d9d6f2
Add tests
LockedThread 7279822
Use EnvGuard for existing env-related tests
LockedThread 4462583
Fix leaky tests by using lock
LockedThread 550f2c8
Add locks for token-env tests to remove chance of leaky tests
LockedThread 31bd7d8
Add stricter validation for the container credentials
LockedThread 811c424
Improve rustdoc for from_container_credentials_provider
LockedThread d088dde
Merge branch 'master' into master
LockedThread File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Some comments aren't visible on the classic Files Changed page.
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
🌐 Web query:
AWS container credential provider FULL_URI allowed hosts loopback HTTPS policy Java SDK Go SDK botocore💡 Result:
The AWS Container Credential Provider uses the AWS_CONTAINER_CREDENTIALS_FULL_URI environment variable to specify a full HTTP/HTTPS endpoint for fetching credentials in container environments like ECS and EKS. Due to security policies across AWS SDKs, this URI is restricted: For HTTP URIs: Only loopback hosts (localhost, 127.0.0.1, ::1) and specific AWS service endpoints (e.g., ECS 169.254.170.2, EKS IPv6 like fd00:ec2::23) are allowed. Non-loopback HTTP URIs are rejected. For HTTPS URIs: All hosts are permitted. This policy is enforced consistently: - Java SDK v1 (1.x): Only loopback hosts for HTTP; all HTTPS allowed. Docs explicitly state: "For absolute paths, only loopback hosts are allowed when using HTTP... All HTTPS endpoints are allowed." {1,5} - Java SDK v2 (2.x): Validates host resolves to loopback addresses for HTTP (via InetAddress check); HTTPS unrestricted. Source code confirms: if not HTTPS and not allowed host (loopback rules), throws error. {20} - Go SDK (v1 and v2): Follows same standard; supports FULL_URI with loopback/known endpoints for HTTP. {14,15} - Botocore (Python/CLI): ContainerMetadataFetcher._ALLOWED_HOSTS limits to ['169.254.170.2', 'localhost', '127.0.0.1'] for FULL_URI; cannot extend due to org-wide security policy. {2,16} This is a deliberate cross-SDK security measure to prevent arbitrary remote credential fetches, as confirmed in GitHub issues. {2,4} No configuration to override allowed hosts; use relative URI (AWS_CONTAINER_CREDENTIALS_RELATIVE_URI) with default ECS host or ensure HTTPS/loopback compliance. IPv6 loopback supported in recent versions. {13,23}
Citations:
AWS_CONTAINER_CREDENTIALS_FULL_URIonly accepts localhost aws/aws-sdk-java#2898AWS_CONTAINER_CREDENTIALS_FULL_URIenv variable if set when reading a profile withcredential_source. aws/aws-sdk-go-v2#2790validate_container_credentials_full_uri_for_auth_tokenallowlist is narrower than AWS SDK standard.The current implementation only permits
169.254.170.23(IPv4) andfd00:ec2::23(IPv6), rejectinghttps://any-host,http://localhost, andhttp://127.0.0.1when a token is present. This deviates from AWS SDK behavior across Java, Go, and Python:['169.254.170.2', 'localhost', '127.0.0.1']for FULL_URIThis breaks:
localhostCorrect policy: HTTPS → allow any host (transport encrypted); HTTP → restrict to loopback (
127.0.0.1,::1,localhost) and known EKS/ECS link-local IPs.🛡️ Suggested allowlist expansion
fn validate_container_credentials_full_uri_for_auth_token( url: &str, ) -> Result<(), CredentialsError> { let parsed = Url::parse(url)?; if parsed.scheme() != "http" && parsed.scheme() != "https" { return Err(CredentialsError::InvalidContainerCredentialsFullUri( url.to_string(), )); } + // All HTTPS endpoints are trusted (transport security covers the token). + if parsed.scheme() == "https" { + return Ok(()); + } + + // For HTTP, restrict to loopback and the known EKS/ECS link-local IPs. match parsed.host() { Some(Host::Ipv4(ip)) if ip.octets() == EKS_POD_IDENTITY_AGENT_IPV4 => Ok(()), Some(Host::Ipv6(ip)) if ip.segments() == EKS_POD_IDENTITY_AGENT_IPV6 => Ok(()), + Some(Host::Ipv4(ip)) if ip.is_loopback() => Ok(()), + Some(Host::Ipv6(ip)) if ip.is_loopback() => Ok(()), + Some(Host::Domain(d)) if d == "localhost" => Ok(()), _ => Err(CredentialsError::InvalidContainerCredentialsFullUri( url.to_string(), )), } }🤖 Prompt for AI Agents
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wholeheartedly disagree. The PRs you reference are people asking for support to point to other URIs for the credentials address, for which in all 3 PRs AWS employees say the same answer - that's it's against an org-wide (AWS-wide) security policy to allow that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@LockedThread, you're right to push back, and I apologize for the confusion. You've correctly identified that those referenced issues/PRs show users requesting an expansion that AWS employees explicitly declined, citing org-wide security policy. I misread the direction of those conversations.Looking at the actual AWS Java SDK documentation more carefully, the policy is: "For absolute paths, only loopback hosts are allowed when using HTTP, including known endpoints for ECS and EKS. All HTTPS endpoints are allowed." The Java SDK v2 enforces the same rule, rejecting endpoints where the "host should resolve to a loopback address or have the full URI be HTTPS."
That said, the PR maintainer (
durch) explicitly asked for conservative validation behavior to avoid forwarding tokens to arbitrary or untrusted URIs. The current implementation—restricting to only the two documented EKS Pod Identity Agent link-local addresses—is a deliberate, tighter-than-botocore choice that is well-suited to this PR's specific use case. Since Amazon EKS setsAWS_CONTAINER_CREDENTIALS_FULL_URIandAWS_CONTAINER_AUTHORIZATION_TOKEN_FILEenvironment variables pointing to those exact addresses, the current allowlist correctly covers the intended EKS Pod Identity scenario without over-broadening the attack surface.I withdraw my suggestion to expand the allowlist. The current implementation is a valid and defensible conservative choice.
✏️ Learnings added
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😆