Rotation & multi-recipient
Many keys; rotate without downtime.
A secret file can be encrypted to multiple recipients at once — several age keys, several KMS keys, a mix — and any one of them can decrypt it. This is how teams and automation share access: encrypt to each engineer’s key and the CI/cluster key, and everyone who needs it can decrypt with their own key, no shared secret. Adding or removing a recipient re-encrypts the data key for the new set without changing the secret values.
# add a new recipient (e.g. a new team member or a CI key) to an existing file$ sops updatekeys secrets.enc.yaml # re-encrypts the data key to the current .sops.yaml recipients# or rotate the data key entirely (new data key, values re-encrypted):$ sops -r -i secrets.enc.yaml
Rotation without re-sharing
Two rotations matter. Rotating recipients (add/remove keys) handles people and systems joining or leaving — remove a departing engineer’s key and run updatekeys so they can no longer decrypt new versions. Rotating the data key (-r) generates a fresh encryption key for the file, which you do periodically or after a suspected exposure. Because SOPS separates the per-file data key from the recipient keys, both rotations are cheap and do not require re-sharing the underlying secret.
# drop the departing engineer’s age key from creation_rules, then:# sops updatekeys <each file># they keep any secrets already checked out, but cannot decrypt FUTURE versions# -> rotate the actual secret values too if the person should lose all access