SOPS and Sealed Secrets: keep plaintext out of Git for MSP Kubernetes

SOPS encrypts config files before they hit Git; Sealed Secrets encrypts a Kubernetes Secret so only the target cluster can decrypt it. Together they cover the GitOps secrets gap.

In this article

What each tool does
Where they fit, and what they don't replace
The habit worth adopting

Two established open-source projects, getsops/sops and bitnami/sealed-secrets, cover a common gap in GitOps pipelines: keeping secret values out of plaintext in version control while still letting the right cluster decrypt them automatically.

A large circular steel bank vault door visible through a building's windows — Photo: Beyond My Ken (CC BY-SA 4.0), Wikimedia Commons.

What each tool does

SOPS, with roughly 22,000 GitHub stars, encrypts configuration and secret files before they are committed, using age, PGP or cloud KMS-style backends. Decryption access is controlled by who holds the key, separate from whoever has read access to the repository. Sealed Secrets, maintained at roughly 9,000 stars, takes a cluster-bound approach: a client-side tool encrypts a Kubernetes Secret against the target cluster's public key, producing a SealedSecret custom resource that is safe to store in Git. Only the in-cluster controller, which holds the matching private key, can turn it back into a usable Secret.

Where they fit, and what they don't replace

Used together, the two tools cover complementary halves of the same problem: SOPS protects arbitrary files before they reach Git, and Sealed Secrets protects the specific case of a Kubernetes Secret bound to one cluster. Neither replaces credential rotation, role-based access control or network isolation -- a SealedSecret is safe to commit, but it is still ciphertext for a specific decrypt boundary, not a substitute for least-privilege access. Practical hygiene matters here: restrict who can run a decrypt operation in CI, never print decrypted values to build logs, and monitor the Sealed Secrets controller's health and its sealing-key rotation schedule. Validate any change to either pipeline in a non-production cluster before rolling it out.

The habit worth adopting

The value of either tool is the control it enforces -- a build that fails when a plaintext secret sneaks into a commit, or a decrypt boundary that only one cluster can cross -- not the tool's name on a slide. Pin versions, keep the encrypted files reviewable in pull requests, and treat key rotation as a scheduled task rather than an incident response.

Sources: getsops/sops, bitnami/sealed-secrets.