Sops: Ignore KMS when decrypting

[jashandeep-sohi]

Is there someway to prevent sops from attempting to use KMS and prefer PGP instead when decrypting a file?

[autrilla]

Not currently, no. I suppose you could reorder the keys in the encrypted YAML, as SOPS goes through them in order.

[jvehent]

Out of curiosity: why do you think having the ability to ignore KMS is a feature we need?

[mccutchen]

At $JOB we're wrapping sops in some higher-level tooling, which takes care of assuming the right role for a user working with secrets and populating the environment with appropriate AWS credentials before invoking sops.

We also provide a --recover-secrets flag for this tooling, which basically has the effect you're looking for here @jashandeep-sohi. It does the simplest thing we could think of: When --recover-secrets is given, we do not populate the environment with AWS credentials, which means sops's attempts to use KMS will fail and it will automatically fall back to PGP.

So even though this functionality is not built into sops, you can at least simulate it by manipulation of the environment in which sops is running. Hope this helps!

[jvehent]

would a --use-key pgp[i] option, where i is the position of the key, address your need?

[jashandeep-sohi]

@jvehent I work offline/near-offline a lot and sometimes the latency of trying to reach the KMS is too much. I do like the idea of a generic solution like --use-key (pgp|kms)[i].

[jpadilla]

I'm actually running into this too. We're using sops in development with PGP and KMS for production. KMS will always be tried first and fail while in development. A --use-key flag would be pretty useful, I guess you could optionally specify the index of the key to use, but would expect --use-key pgp to just try to decrypt with all PGP keys.

[brad-jones]

Not currently, no. I suppose you could reorder the keys in the encrypted YAML, as SOPS goes through them in order.

@autrilla I did attempt this and it appeared to make no difference what so ever, still attempts to call out to KMS.

You were referring to simply moving sops.pgp to appear above sops.kms?

Whats more the second you edit the file sops then reorders it such that the pgp "YAML" key is last again.

Obviously each and every time a developer decrypts a secret locally thats a KMS call that costs money. If they happened to have a valid PGP key it would make sense to try that first. So the operation is cheaper and faster.

Ideally we would like to keep secrets encrypted at rest at all times and then use something like https://cyberark.github.io/summon/ to inject secrets at runtime. Hence the need to decrypt lots and lots.

[brad-jones]

Update: If you delete sops.kms then it will use PGP to decrypt and not bother trying KMS.

[autrilla]

@brad-jones no, simply moving the entry in a mapping won't work. I was suggesting using key groups and making sure your PGP key group appears first in the file. If you use a Shamir threshold of 1, and then list your PGP key group first, and the KMS key group second, either one of those groups would be enough to decrypt the file, and sops will try the first key group first.

[brad-jones]

Ah nice, I'll give it a shot.

[ajvb]

@autrilla In taking a look at the base AWS client struct in the sdk (https://docs.aws.amazon.com/sdk-for-go/api/aws/client/#Client) - it looks like there is a retryer with a back-off, which is probably why this can take a while if you can't use the AWS KMS key for whatever reason.

It might be worth including an option (--use-key X, --offline), including our own Retryer with a shorter retry window, or changing the decryption functionality to always try pgp first?

My first choice would be the include a shorter retry window, as that is probably the simplest and will be similar to what we want to do for https://github.com/mozilla/sops/issues/402

[autrilla]

@ajvb that could be good, yeah.

Another option would be #266 since we'd try PGP at the same time as KMS, and that would succeed before KMS times out.

[ajvb]

@autrilla :+1: sounds good

[SinisterMinister]

I just submitted PR #638 which, while it doesn't allow for specifying specific ones to run, it runs all in parallel with success winning and returning immediately. This solved the problems described as they were similar to ours.

We're using the sops vars plugin in our deploys and with it, Ansible calls sops with each task run. This is no big deal on an AWS machine or one with credentials. Ones without that rely on PGP would literally take a minute for each task to run sops, however. This solved the problem and now sops runs as fast as the quickest successful key.

[dt-darren]

Adding my support for the option to choose which key to use during decrypt. Our use case is we would be using one vault as a backup and using another as the "everyday vault". The backup would have strict access policies so the machines that would do the everyday access wouldn't have access to the backup. So performing all the attempts in parallel is a waste of effort.

If the parallel method is chosen can sops be made to only output error logging if no method succeeds, not for every one that fails even if one works please? :)

[james-callahan]

This is a pretty high usability issue for me. Could we get a higher priority?