Describe the bug
The Vault CLI uses an AWS credential chain implemented by hashicorp/go-secure-stdlib. This credential chain orders the providers in a different manner than the official AWS implementation of the default credential chain.
In particular, the credential chain that's being used by the Vault CLI places the WebIdentityRoleProvider at a higher precedence than the EnvProvider, when it should be the opposite.
To Reproduce
On a host with the Vault CLI installed, configure environment variables for AWS authentication:
- Set up static credentials with the environment variables
AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN
- Set up web identity token authentication with the environment variables
AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE.
Then, use the Vault CLI to login to a Vault server with AWS IAM authentication configured:
$ vault login -method aws role=foo region=us-east-1
This will cause the Vault CLI to craft signed STS.GetCallerIdentity headers for the identity associated with the web identity token, when it should be using the static credentials instead.
You can verify this by running aws sts get-caller-identity, which will return the identity associated with the static credentials, not the web identity token.
Expected behavior
When both static credentials and web identity token authentication methods are specified, the Vault CLI should prefer the static credentials, similar to the official AWS implementation for the default credential provider chain.
Supporting documentation:
Also, as described above, you can observe the expected behavior using the AWS CLI. When both static credentials and web identity token authentication are configured, the AWS CLI will prefer the static credentials.
Suggested Fix
I believe the fix should be made within hashicorp/go-secure-stdlib, by moving the code that configures the EnvProvider ahead of the code that configures the WebIdentityRoleProvider. I would be happy to submit a PR for this.
Thanks!
Describe the bug
The Vault CLI uses an AWS credential chain implemented by hashicorp/go-secure-stdlib. This credential chain orders the providers in a different manner than the official AWS implementation of the default credential chain.
In particular, the credential chain that's being used by the Vault CLI places the
WebIdentityRoleProviderat a higher precedence than theEnvProvider, when it should be the opposite.To Reproduce
On a host with the Vault CLI installed, configure environment variables for AWS authentication:
AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY, andAWS_SESSION_TOKENAWS_ROLE_ARNandAWS_WEB_IDENTITY_TOKEN_FILE.Then, use the Vault CLI to login to a Vault server with AWS IAM authentication configured:
This will cause the Vault CLI to craft signed
STS.GetCallerIdentityheaders for the identity associated with the web identity token, when it should be using the static credentials instead.You can verify this by running
aws sts get-caller-identity, which will return the identity associated with the static credentials, not the web identity token.Expected behavior
When both static credentials and web identity token authentication methods are specified, the Vault CLI should prefer the static credentials, similar to the official AWS implementation for the default credential provider chain.
Supporting documentation:
Also, as described above, you can observe the expected behavior using the AWS CLI. When both static credentials and web identity token authentication are configured, the AWS CLI will prefer the static credentials.
Suggested Fix
I believe the fix should be made within hashicorp/go-secure-stdlib, by moving the code that configures the
EnvProviderahead of the code that configures theWebIdentityRoleProvider. I would be happy to submit a PR for this.Thanks!