Use same KMS key, but use a different role to decrypt vs encrypt

[geota]

Hi,

I have a single KMS key that two different roles have access to. I am trying to encrypt the secret using one role, but then decrypt it using a different role (this constraint is due to some security policies at my company).

KMS Key:
arn:aws:kms:us-east-1:123456789:key/123456

Encrypt Role:
arn:aws:iam::123456789:role/encrypt-role

Decrypt Role:
arn:aws:iam::123456789:role/decrypt-role

My .sops.yaml config looks like:

creation_rules:
    - kms: 'arn:aws:kms:us-east-1:123456789:key/123456+arn:aws:iam::123456789:role/encrypt-role'

The encryption works fine, but it fails to decrypt because the role is persisted to the enc.yaml metadata file.

Example:

super_secret:
    token: ENC[AES256_GCM,data:asdasdasdasdasdas/wM=,iv:asdasdasdasdasdasd=,tag:asdasdasdasdasdasd==,type:str]
sops:
    kms:
    -   arn: arn:aws:kms:us-east-1:123456789:key/123456
        role: arn:aws:iam::123456789:role/encrypt-role
        created_at: '2020-07-14T18:28:18Z'
        enc: stuff
        aws_profile: ""
    gcp_kms: []
    azure_kv: []
    lastmodified: '2020-07-14T18:28:19Z'
    mac: mac-stuff
    pgp: []
    unencrypted_suffix: _unencrypted
    version: 3.5.0

If I manually edit the role to be the decrypt role then decryption works fine.

What I think I am looking forward is to somehow be able to configure a different decryption config... e.g. have .sops.yaml support a decrypt_rules section where we could configure this or provide a way to supply multiple roles that would be attempted in serial until one is able to access the kms key.

This seems like it might of been supported with the key_groups stuff, but I hit two issues. One is that it requires shamir-secret-sharing-threshold >= 2 AND it fails when it can't assume one of the roles.

[autrilla]

I believe this is a duplicate of #634

[geota]

@autrilla

It is a similar issue, but not exactly the same. In my case, this is around persisting the role in the config. I am not specifying profiles anywhere. Ill add that comment to the thread.

[oblogic7]

This is definitely not duplicate of #634 and doesn't deal with profiles but with KMS key access that is managed by assuming a role. I have a CICD role that is scoped to only allow decrypt permissions, but since sops insists on using the original role that is encoded into the file (which cannot be assumed by my CICD user for reasons) the decrypt action is not able to be completed by my CICD user. The only way around this is to allow my CICD user to assume the original role, which has WAY more privileges than CICD needs. This breaks the best practice of least privileged access. Sops should allow a custom role to be provided when decrypting that overrides whatever role is in the file metadata.

[ajvb]

I'll reopen, as though it's related to #634 in principle, it is a different issue.

For both #634 and for this issue, I believe that the best path forward is for sops to stop embedding any auxiliary authentication information into the sops metadata. This will be a big change though and will probably take a few stages to move away from as to not break people's deployment flows.

@geota @oblogic7 In the meantime, my hacky recommendation to deal with this for now would be to edit the yaml before your decryption step and replace the role value in the sops metadata with your decryption-specific AWS role.