AWS CLI login credentials are not resolved for KMS AssumeRole unless exported to environment

Summary

When using SOPS 3.11.0 with AWS KMS and the KMS ARN + Role ARN syntax for cross-account encryption, SOPS fails to resolve the same AWS credentials that the AWS CLI can use successfully after aws login. Exporting the resolved AWS CLI credentials to environment variables makes the exact same SOPS command succeed.

This looks like a credential provider compatibility issue between AWS CLI login credentials and the AWS SDK for Go v2 credential chain used by SOPS, rather than a KMS permission or IAM trust issue.

Version

$ sops --version
sops 3.11.0

Environment

• macOS
• AWS CLI is authenticated via aws login
• aws sts get-caller-identity succeeds and returns the expected source account
• aws sts assume-role to the target role succeeds from the same shell/session

What works

After aws login, AWS CLI commands work:

$ aws sts get-caller-identity
# returns SOURCE_ACCOUNT_ID

Assuming the target role also works:

$ aws sts assume-role \
  --role-arn arn:aws:iam::TARGET_ACCOUNT_ID:role/sops-role \
  --role-session-name sops-test
# succeeds

What fails

Running SOPS with cross-account KMS role syntax fails:

$ AWS_EC2_METADATA_DISABLED=true \
  sops -e -i \
  --kms 'arn:aws:kms:ap-northeast-2:TARGET_ACCOUNT_ID:key/KMS_KEY_ID+arn:aws:iam::TARGET_ACCOUNT_ID:role/sops-role' \
  secret.sops.yaml

The original failure without AWS_EC2_METADATA_DISABLED=true was:

Could not generate data key: [failed to encrypt new data key with master key "arn:aws:kms:ap-northeast-2:TARGET_ACCOUNT_ID:key/KMS_KEY_ID+arn:aws:iam::TARGET_ACCOUNT_ID:role/sops-role": failed to assume role 'arn:aws:iam::TARGET_ACCOUNT_ID:role/sops-role': operation error STS: AssumeRole, get identity: get credentials: failed to refresh cached credentials, no EC2 IMDS role found, operation error ec2imds: GetMetadata, request canceled, context deadline exceeded]

Workaround

If I export the AWS CLI-resolved credentials into environment variables, the exact same SOPS command succeeds:

$ aws configure export-credentials --format env > /tmp/aws-creds.env
$ source /tmp/aws-creds.env

$ AWS_EC2_METADATA_DISABLED=true \
  sops -e -i \
  --kms 'arn:aws:kms:ap-northeast-2:TARGET_ACCOUNT_ID:key/KMS_KEY_ID+arn:aws:iam::TARGET_ACCOUNT_ID:role/sops-role' \
  secret.sops.yaml
# succeeds

Expected behavior

SOPS should be able to resolve the same AWS login credentials that aws sts get-caller-identity and aws sts assume-role can use from the same shell/session, or the documentation should clarify that aws configure export-credentials --format env / explicit environment credentials are required for this AWS CLI login flow.

Actual behavior

SOPS falls through to IMDS credential resolution and fails with no EC2 IMDS role found, even though AWS CLI can resolve credentials and assume the target role successfully in the same environment.

Additional notes

The successful workaround confirms that:

• the SOPS KMS ARN + Role ARN syntax works;
• the target role trust policy allows the source identity to assume the role;
• the target role and KMS permissions are sufficient for encryption;
• the failure appears to happen before the target KMS call, while resolving source credentials for the STS AssumeRole call.

Reproduce the KMS ARN + Role ARN command after aws login, then trace SOPS’s AWS SDK for Go v2 credential resolution and the STS AssumeRole path. Compare it with aws configure export-credentials --format env; done means SOPS can use the AWS CLI login credentials directly, or the required environment-credential workaround is documented.