A base64-encoded string in a Git repo is not a secret. It's plaintext with one extra step, and echo "cGFzc3dvcmQ=" | base64 -d undoes that step in about a second. Plenty of teams discover this the hard way when a secret scanner flags their carefully "encoded" data: block as a live database password sitting in the commit history, readable by anyone who ever cloned the repo.
That's the core tension of GitOps. You want Git to be the single source of truth for everything in the cluster, but "everything" includes API keys, TLS private keys, and database passwords, and committing those in the clear is how breaches start. SealedSecrets resolves that tension with a small controller and a CLI, and it's the lightest-weight tool I know of that does the job properly. If you run ArgoCD or Flux and you're still keeping a secrets/ folder out of version control "for now," this is the post for you.
The false starts I'd warn you about
Before SealedSecrets clicks, most people cycle through the same set of wrong answers. I did too.
The first instinct is to just base64-encode the value and call it encrypted. Kubernetes stores secret data as base64, so it looks scrambled, and that visual scramble fools a surprising number of code reviews. Base64 is an encoding, not encryption. There is no key. Anyone with the repo has the secret. Cross this one off immediately.
