Should be able to assume a role using AWS_PROFILE and 'credential_source=Environment'

[alewando]

I have a profile configured that should assume a role, and wants to use the Environment (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) as the “source credentials” (those used to issue the ‘assume role’ request), as documented here:

~/.aws/config:

[profile myprofile]
region = myregion
credential_source = Environment
role_arn = arn:aws:iam::0123456789:role/myrole

Observe the identity that ends up being used: $ AWS_PROFILE=myprofile AWS_ACCESS_KEY_ID=AKIAXXXXX AWS_SECRET_ACCESS_KEY=XXXXXXX aws sts get-caller-identity The results show that the role was not assumed, and that the specified credentials were used directly.

Actual:

{
    ....
    "Arn": "arn:aws:iam::xxxxxxxxxxxx:user/<owner of the supplied access key>"
}

Expected:

{
    ....
    "Arn": "arn:aws:sts::yyyyyyyyyyyy:assumed-role/myrole/botocore-session-xxxxxxx"
}

I have seen the documentation regarding credentials precedence (which states that all three of these environment variables cannot be used together) but find this to be confusing. What is the purpose of credential_source = Environment in the config file then? If specifying the source credentials via the environment, would you not also want to specify the profile to be using the same mechanism? What is the usage where credential_source = Environment would be honored?

Apparently I'm not the only one confused by this (see #3304).

For clarification, the use case I'm trying to support is an automated process (or individual end user) that does not want to (or cannot) keep the AWS credentials in a plaintext file and instead needs to put them into temporary environment variables. This user wants to utilize the CLI to assume a role in order to execute commands (an AWS-recommended best practice).

It is my (experientially confirmed) understanding that this is a use case that is not currently supported by the AWS CLI (other than manually invoking the role assumption and using the temporary credentials directly). My question is: will this use case ever be supported? Would a pull request that implements support for it be accepted? #3304 suggests an alternate environment variable to specify a profile for role assumption, is that acceptable?

[justnance]

@alewando - Thank you for reaching out. I have separated out some of your questions as follows:

will this use case ever be supported?

At this time, it may not be in order to preserve backward compatibility. As per @joguSD under #3304, "While it is common in many tools for environment variables that map to CLI arguments to have exactly the same behavior, this isn't the pattern the AWS CLI has. In general, we treat explicit arguments to the CLI with a higher priority than settings in the environment. In this case, setting credentials via environment variables results in the profile set in the environment being ignored entirely (not just the credentials from it). This interaction between AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_PROFILE was defined before assume role configuration was added. For backwards compatibility reasons we can't change the way those three environment variables interact.".

Would a pull request that implements support for it be accepted?

I will label this issue as feature-request spending further review and discussion.

#3304 suggests an alternate environment variable to specify a profile for role assumption, is that acceptable?

Again, any new features would need to preserve backward compatibility for it to be acceptable.

[frezbo]

@justnance Any plans to move this forward, using a new environmental variable? I have been using the ruby SDK and it seems the credential_source=Environment is not at all supported, I patched the code to support it, but the the way the CredentialResolver parses the env vars makes it unusable when a profile is assuming a role with role_arn. We could have a proper implementation with support for backward compatibility.

[alewando]

I just came across this issue again, forgetting the previous attempts. I was confused by some (newer?) AWS documentation which states that credential_source is supported by the AWS CLI. https://docs.aws.amazon.com/credref/latest/refdocs/setting-global-credential_source.html

I think this issue (and #3304) prove that this is not the case. The AWS documentation should be updated to reflect that, or at least provide some explanation in the "Notes or more information". The published documentation is misleading at best.

[lukeplausin]

Having issues setting a named profile with a role ARN in AWS EKS due to this problem. Now it seems like there is no way to use cross-account IAM roles with from a pod unless this is supported?

[gposton]

This is of particular usefulness to me as we have MFA required, which means we have to use STS to generate keys (supplying an MFA token). It would be nice to use those generated keys (which are set as ENV vars) combined with chaining to assume roles in other accounts. I don't know of any other way to support this use case, and it's a particularly common use-case for secure (MFA) multi-account AWS architectures.

[adrian-skybaker]

We've worked around by writing temporary env vars into .aws/credentials/config, which works but can be less secure.

[gposton]

@adrian-skybaker arguably less secure, but also terribly annoying. I've found that another workaround is to add --profile to the aws-cli commands. For some reason this works while setting AWS_PROFILE does not. As a side-note, boto has the same issue, but there's no option for --profile when running python scripts. I mention this as I'm pretty sure the aws-cli leans on botocore.

[gurpalw]

Having issues setting a named profile with a role ARN in AWS EKS due to this problem. Now it seems like there is no way to use cross-account IAM roles with from a pod unless this is supported?

I was also trying to use a profile defined in my AWS config file inside an EKS pod.

the paramaters i set were web_identity_token_file and role_arn. it worked when the pod was assuming a role in the same AWS account. but cross-account assumption was failing when using the web_identity_token_file

[frimik]

As mentioned in several other linked issues, want to assume a role, from a Amazon EKS (IRSA) Pod.

The particular purpose is for making configuration straight forward and simple for git-remote-codecommit. But turns out I have to complicate it with some workarounds as mentioned.

[lumattr]

Is there any additional solutions to this that help with the cross account problem?