Git is Not a Secrets Store
GitOps sounds elegant until you hit a fundamental contradiction: you cannot store sensitive data (database passwords, API keys, TLS private keys) in plain text in a Git repository.
Even if your repository is private today, consider:
- Git history is permanent. A secret committed and later deleted is still in git log.
- Repositories get cloned to developer laptops, CI runners, and backup systems.
- Private repos can be accidentally made public, or access controls can be misconfigured.
- Insider threats: any developer with repo access can read all secrets.
A raw Kubernetes Secret YAML file stores its values under a data field as base64-encoded strings — for example, a password key holding the base64 encoding of super-secret-123.
Note that base64 is not encryption — it is trivially reversible with a single decode command. Committing this to Git is equivalent to committing the plaintext password.
So, how do we achieve the "everything in Git" goal without exposing secrets? We need a way to store encrypted secrets in Git that can only be decrypted inside the cluster by authorized parties.