Creating new sops file fails with `creation_rules` and `key_groups`

[snovikov]

In short: Cannot create new sops file when using configuration .sops.yml with multiple kms_groups configured, if user lacking permission to at least on of the kms_groups. On the other hand - already created sops file with the same list of KMS keys could be decrypted/encrypted without error.

Expected behaviour: Creating new sops file and editing existing sops file works in the same way - permissions to at least one of the KMS key is enough to decrypt/ecrypt.

SOPS: v3.11.0

TL;DR

I have following configuration in .sops.yml

---
creation_rules:
    - path_regex: .*/secrets/*
      key_groups:
          - kms:
                - arn: "arn:aws:kms:eu-central-1:123456789101:alias/sops-key"
                  role: "arn:aws:iam::123456789101:role/role1"
                - arn: "arn:aws:kms:eu-central-1:123456789101:alias/sops-key"
                  role: "arn:aws:iam::123456789101:role/role2"

I have permissions to assume both roles (role1, role2), but other person has permissions only to assume role2.

When I try to create a new file - it works perfectly fine:

$ sops secrets/ok.yml
test: test

secrets/ok.yml

test: ENC[AES256_GCM,data:3WDdPA==,iv:QfKCgdcCjUBzZGomqdn7s9ZhWqgxm8yqTohuIEC8WGE=,tag:jvTCI24HUH1BVpO4Dl91jQ==,type:str]
sops:
    kms:
        - arn: arn:aws:kms:eu-central-1:123456789101:alias/sops-key
          role: arn:aws:iam::123456789101:role/role1
          created_at: "2026-01-14T12:13:16Z"
          enc: AQICAHjJMh6hKQi9wz2gM8xaJRTT3gb7CPEk4M8iczAeceeN+AH1yotCoJkUQVtS8vkUwYieAAAAfjB8BgkqhkiG9w0BBwagbzBtAgEAMGgGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQMgY/1rdpBQqzIGUVKAgEQgDv3XdNEgUvetfeJw+maSf/+ViDqlpj3p+p4Gb9PSXWbkjbuf0wOblLq7CfpWt7NWnN4pVTyOle8kBnRyw==
          aws_profile: ""
        - arn: arn:aws:kms:eu-central-1:123456789101:alias/sops-key
          role: arn:aws:iam::123456789101:role/role2
          created_at: "2026-01-14T12:13:16Z"
          enc: AQICAHjJMh6hKQi9wz2gM8xaJRTT3gb7CPEk4M8iczABceeN+AFeHM5udHhIgffj/FSfENTLAAAAfjB8BgkqhkiG9w0BBwagbzBtAgEAMGgGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQMhVys+I2DXMAMmSyUAgEQgDsKvBeI5pj4n0UGcjdgJCatpUtAyWbtB9U8ZZ0q1IUVHPh344ZBP1qU1JJvJhnZ3GLLElRSoQ/31eJCFA==
          aws_profile: ""
    lastmodified: "2026-01-14T12:18:20Z"
    mac: ENC[AES256_GCM,data:OA+MDQPIyMvB4c1m/GZbbObd1bKbPAXNSnceJCN5sgkHWNY0R1IaAr/Pkdlx+JgwL9fXBaRMLH6RlkndT13Lkq/HyB/pblyfAPspUJWDgEDHmhX+hEIu0Ss8xWsZiRhEeB1BG73UWtnhp8GHQP/IkuMVgUz/S31zoWSdPjYhSC0=,iv:wedVY/TYaS7Efn656EHWGTsvHQTCXBdkCmfkW42hJ6g=,tag:wDkudc1O1BmGRYDoz0ytkg==,type:str]
    unencrypted_suffix: _unencrypted
    version: 3.11.0

And another person could decrypt/encrypt that file without problem.

But when that person tries to create a new file from scratch he gets an error:

$ sops secrets/error.yml
Error encrypting the data key with one or more master keys: [failed to encrypt new data key with master key "arn:aws:kms:eu-central-1:123456789101:alias/sops-key+arn:aws:iam::123456789101:role/role1": failed to assume role 'arn:aws:iam::123456789101:role/role1': operation error STS: AssumeRole, https response error StatusCode: 403, RequestID: aac37ad1-0886-4925-a6b6-c6f347538f60, api error AccessDenied: User: arn:aws:sts::123456789101:assumed-role/login-role2/other-user@example.com is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::123456789101:role/role1]

[felixfontein]

Expected behaviour: Creating new sops file and editing existing sops file works in the same way - permissions to at least one of the KMS key is enough to decrypt/ecrypt.

That is your expectation, but it's very different from how SOPS works. :)

If you create a new file, SOPS must be able to encrypt the file's secret key with all identities. So it needs access to all KMS keys.

If you decrypt or modify a file, SOPS only needs to get hold of the file's secret key, so being able to decrypt it with a single identity is enough.

[snovikov]

@felixfontein thanks for you feedback. This is generally measleading - I don't understand what is the principal difference between "encrypting first time" and "encrypting Nth time". Is it about content of enc field which should be be generated once at the beginning?

Also there is a case, when the KMS key is the same - just IAM roles are different. Maybe there some other solution is possible in our case?

[felixfontein]

@felixfontein thanks for you feedback. This is generally measleading - I don't understand what is the principal difference between "encrypting first time" and "encrypting Nth time". Is it about content of enc field which should be be generated once at the beginning?

Basically yes. enc contains the file's secret key encrypted by the identity. This has to be generated once for every identity (and updated whenever the secret key is updated), so when these already exist, you only need one identity to update the file's contents. But when they don't exist, you need all identities to create all enc values.

Also there is a case, when the KMS key is the same - just IAM roles are different. Maybe there some other solution is possible in our case?

SOPS doesn't know this, and thus it can't help you with this. What you can do is only encrypt the file with one identity, and manually add the other if the key is actually the same. (I'd test whether it really works though first before relying on it.)