The secrets-in-Git problem & SOPS
Why plaintext in Git is dangerous.
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.
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.