sops: Decryption failed when different aws-profile names used

So this is definitely a bug. sops should ignore that field when decrypting

Why? It’s stored exclusively to use the same profile (by name) every time you decrypt.

, and/or override it when the --aws-profile flag is set on the command line. So long as both users have access to the same KMS keys it should work regardless of the aws-profile name.

I think --aws-profile should just not work unless you’re creating a file. Similar to --pgp or --kms, I guess.

Well then shouldn’t --aws-profile override whatever profile name the user that created the file used.?

Otherwise all users in a company would need to make sure they use the exact same AWS profile name when working with sops. Which seems silly because the profile name is totally arbitrary and has no impact on whether they can access the same KMS keys or not.

Having the same issue.

# Does work
AWS_PROFILE=production sops -i production/secrets.yaml

# Does not work
sops --aws-profile=production -i production/secrets.yaml

I was having a similar issue. I was able to get around needing to use any aws-profile name but running aws sts assume-role --role-arn [rolearn] --role-session-name [name].

The AWS_PROFILE env var behaves the same - it will only decrypt the file if the same profile name was used that encrypted the file.

The docs say that “Similarly the --aws-profile flag can be set with the command line with any of the KMS commands.” And earlier in this ticket you agreed that the name should not matter. 😃

May be worth adding something to do the docs saying that you have to use the same AWS Profile name for both encrypting and decrypting. That is not clear, and in all other AWS operations the profile name is totally arbitrary and local to your machine, the name alone shouldn’t impact your access/permissions/ability to do something.

In that case there is a bug. Reproduce with:

1. Computer 1: Encrypt a file with an aws profile named “foo”
2. Computer 2: Try and decrypt the same file with an aws profile named “bar”

Even though both computers/users are using the same KMS ARN it will fail

For me assuming of aws roles did not work in any way through a profile. I found the following workaround for the assuming role:

$(aws sts assume-role --role-arn $ARN_OF_ROLE_TO_ASSUME --role-session-name manual | jq -r '.Credentials | "export AWS_ACCESS_KEY_ID=\(.AccessKeyId) AWS_SECRET_ACCESS_KEY=\(.SecretAccessKey) AWS_SESSION_TOKEN=\(.SessionToken)"')
sops -i production/secrets.yaml
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN

I have this issue when I configure sops with .sops.yaml to use a specific AWS_PROFILE but it seems to break when AWS_PROFILE is not set in my bash. Once I run export AWS_PROFILE=$myprofile it does work.

According to this documentation https://github.com/mozilla/sops#25kms-aws-profiles I understand that this value should be taken from the sops configuration.

Example file:

sops:
  kms:
  - arn: '$AWS_KMS_KEY_ARN'
    aws_profile: '$AWS_PROFILE'

creation_rules:
- path_regex: ./secrets/
  kms: '$AWS_KMS_KEY_ARN'

@richstokes seem to be running into this too. I don’t know what changed. I was working with a developer the other day and nothing would work until added a role into the .sops.yaml and/or the encrypted file. Simply would not assume a role no matter what env vars we set.

OK I found something else, if I manually edit the encrypted file and edit the aws_profile: <name> field to match my local AWS profile name (instead of the AWS profile name used by the file creator) I am able to decrypt it!

So this is definitely a bug. sops should ignore that field when decrypting, and/or override it when the --aws-profile flag is set on the command line. So long as both users have access to the same KMS keys it should work regardless of their local aws-profile name.

Before manually editing the aws_profile: field:

sops --aws-profile il -d test.yaml                                                                                                                                                                                                               

Failed to get the data key required to decrypt the SOPS file.

Group 0: FAILED
  arn:aws:kms:us-west-2:abc123:key/abc123-abc123-4258-83fc-6603f37eeda6: FAILED
    - | Error decrypting key: ExpiredTokenException: The security
      | token included in the request is expired
      | 	status code: 400, request id:
      | 853579d7-1579-4cbe-af0c-9e51706de807

  arn:aws:kms:us-east-2:abc123:key/abc123-abc123-4245-a4bc-ad7324959fa6: FAILED
    - | Error decrypting key: ExpiredTokenException: The security
      | token included in the request is expired
      | 	status code: 400, request id:
      | ce0a9008-d447-4976-ae5e-ce4648146f59

Recovery failed because no master key was able to decrypt the file. In
order for SOPS to recover the file, at least one key has to be successful,
but none were.

After manually editing the aws_profile: field:

sops --aws-profile il -d test-editted.yaml
                                                                                                                                                                                                      
hello: This is a test 123123
example_key: example_value
# Example comment
example_array:
- example_value1
- example_value2
example_number: 1234.5679
example_booleans:
- true
- false

I tried reauthing, and can encrypt and decrypt my own files OK. I only see the problem when trying to decrypt files created by another user (even though we both use the same KMS keys).

And they see the reverse, they are unable to decrypt my files.

However if we both establish our AWS Credential file (~/.aws/credentials) using the “default” profile instead of a named one, everything works fine.

The profiles are different - they are different users who have named their block of credentials differently