CoursesSOPSBeginner

The secrets-in-Git problem & SOPS

Why plaintext in Git is dangerous.

Intermediate12 min · lesson 1 of 12

Every team hits the same wall: infrastructure and app config live in Git, but some of it is secret — database passwords, API tokens, TLS keys — and plaintext secrets must never sit in a repository. Committed secrets are exposed to everyone with read access, live forever in Git history even after deletion, and are a top cause of breaches when a repo leaks. SOPS (Secrets OPerationS, from Mozilla) solves this by encrypting the secrets so the ciphertext is safe to commit, while keeping the workflow of “config in Git.”

What makes SOPS pleasant is partial encryption: it encrypts only the values in a structured file (YAML, JSON, env, ini), leaving the keys and structure readable. So a committed secrets file still shows which settings exist and produces meaningful diffs — you can review that a password changed without seeing the password — while the sensitive values are ciphertext. It is format-aware and editor-friendly, which is why it became the default “secrets in Git” tool across GitOps and IaC.

Secrets that are safe to commit
1secret file
plaintext values
2sops encrypt
with your key
3ciphertext
safe in Git
4decrypt on use
only with the key
Values encrypted, structure readable. The repo holds ciphertext; only key-holders can decrypt.

Encryption, not encoding

The distinction that matters: SOPS actually encrypts with a real key, unlike base64 (Kubernetes Secrets) or a bare secretGenerator, which merely encode and are trivially reversible. A SOPS-encrypted value is unreadable without the key, and SOPS records which keys can decrypt it in the file’s metadata. So the security reduces to protecting the key — which is the whole story of the backend lessons — but the secret itself is genuinely safe at rest in Git.

The key is the whole security boundary
SOPS moves the problem from “protect the secret” to “protect the key that decrypts it” — which is a much better problem, but still a problem. Whoever holds the decryption key can read every secret it covers, so the security of your whole scheme rests on how you store and scope that key. Everything else in this course is, ultimately, about protecting and managing that key well.