support --kms, --aws-profile options when decryption

[Shikugawa]

I think that options should be passed when decryption like

sops --kms ${KMS_ARN} --aws-profile ${AWS_PROFILE} -d encrypted.json > decrypted.json

But, this proposal may be not appropriate to this project. Do you think about it?

[autrilla]

I think what you're saying is somewhat similar in scope to #305. Does the workaround suggested there work for you?

[Shikugawa]

@autrilla In my case, KMS ignorance is not so important so that --kms option is not needed at least. But, when team members share same KMS resource and encrypted files, decryption must be failed if they use different AWS profile name.

[ChrisCooney]

I think this is distinct. We've got a similar issue. We have users that encrypt data on their local machines using one AWS role and the CI server which will decrypt using a different AWS role. The idiomatic way to do this in sops seems to be the following in the .sops.yaml file:

arn://...-key+arn://...-developer-role

The issue is, the CI server can not assume the developer-role, it can only assume the ci-role. The ideal for me would be a switch like --aws-role where we can override what is in the .sops.yaml file.

[ajvb]

@ChrisCooney Could you use the kms key ARN without including the role? Would require authing to the AWS role out of bound of sops, but would solve your problem.

[ChrisCooney]

@ChrisCooney Could you use the kms key ARN without including the role? Would require authing to the AWS role out of bound of sops, but would solve your problem.

That is our present workaround, but without the role there are like five AWS environment variables that need to be set. This is mitigated by engineers passing around scripts they've bundled together to set the correct environment variables, but it is quite undesirable. The simple ability to override the role at runtime would be far more preferable and create a much better use journey.

[ChrisCooney]

So we've found a slightly easier way of handling this that we're going with for the time being. It was found by a few engineers that I work with. If you export the following env vars:

AWS_SDK_LOAD_CONFIG=1
AWS_DEFAULT_PROFILE=<your profile name>

Sops will encrypt and decrypt using that role and your config doesn't need to change. This is a much nicer workaround than manually authing all the time.

[mr-karan]

This definitely needs a patch. CD environments shouldn't assume any other role besides their own and probably hardcoding aws_profile in the generated yaml file is not the best idea.

Taking a look at the code right now, will take a stab at it 👍