Read AWS_CONTAINER_CREDENTIALS_FULL_URI env variable if set when reading a profile with credential_source.

[Madrigal]

Context

EKS (Elastic Kubernetes Service) is a managed service for running Kubernetes clusters. Pods are the smallest deployable units in Kubernetes, consisting of one or more containers, and are managed within a cluster.EKS Pod identity is a new feature of AWS, which allows individual pods to be mapped to a specific IAM roles

For the SDKs, this means that EKS Pod Identity sets AWS_CONTAINER_CREDENTIALS_FULL_URI and AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE, which are used to retrieve credentials.

This IAM role must exist within your own AWS account.

use case

Customers want to be able to easily be able to assume the role of another AWS account, since it's a common pattern to have one AWS account managing the EKS cluster and others that host things like DynamoDB tables or S3 buckets. Right now, customers can setup IAM role chaining via code, but they want to be able to do it via profiles, like

[profile other-account]
role_arn = arn:aws:iam::1234567890:role/other-account-role
credential_source = EcsContainer

Problem

Go SDK currently didn't read from AWS_CONTAINER_CREDENTIALS_FULL_URI when resolving credentials from a shared AWS config file, it only read AWS_CONTAINER_CREDENTIALS_RELATIVE_URI. Since this is not what EKS Pod identity sets, the request failed.

Additionally, while we have a SEP that defines the priority between these variables, this wasn't implemented.

[lucix-aws]

Why remove the fallback?

[Madrigal]

This wasn't really a fallback but rather a function call after checking the args are valid

if (!isValid(a)) {
    return error
}
func(a)

This is however building an ECS path, and you are correct that we could pass an empty path to ecsContainerURI to resolve to the base path directly. However, the SEP doesn't like this

If none of the above sources (the two env variables) yield a value, the provider MUST fail to resolve indicating as such.