Secrets management usually forces a bad trade: keep secrets out of git (and then juggle them out-of-band) or check them in (and leak them). SOPS (Secrets OPerationS, from Mozilla) offers a third way. It encrypts only the values in a YAML or JSON file - leaving the keys readable - using a key from AWS KMS, GCP KMS, Azure Key Vault, age, or PGP. The result is a file you can safely commit: the structure is visible and diffable, the secret values are ciphertext.
Encrypt Values, Keep Structure
You edit secrets in plaintext locally; SOPS encrypts on save and decrypts on demand:
# Encrypt a file in place
sops --encrypt --in-place secrets.yaml
# Edit it (decrypts, opens editor, re-encrypts)
sops secrets.yaml
# Decrypt to stdout for an app to consume
sops --decrypt secrets.yaml
Git-Friendly Secrets
Because keys stay readable and only values are encrypted, a SOPS file produces meaningful diffs (you can see which secret changed, if not its value) and lives happily in version control. Access is controlled by who can use the underlying key, which ties neatly into cloud IAM.
Rough Edges and Limitations
- Key management is the real work. SOPS secures the file; securing and sharing the encryption key is on you (KMS, age, etc.).
- A decryption step everywhere. Apps and CI need to decrypt at runtime, which is wiring to set up.
- Not a live secret store. For dynamic secrets and leasing, a dedicated vault fits better.
For keeping configuration secrets in git without leaking them, SOPS is a pragmatic, widely-adopted answer.
Internal link suggestion: link "decrypts on demand" to the direnv post, which can load SOPS-decrypted values into a project's environment.