Solving Secrets: Sealed Secrets and SOPS

Two popular tools solve the secrets-in-Git problem using different approaches to asymmetric encryption. Asymmetric encryption uses a key pair: a public key (safe to share) for encrypting data, and a private key (kept secret) for decrypting it. Data encrypted with the public key can only be decrypted by the holder of the private key.

1. Sealed Secrets (by Bitnami)

Sealed Secrets is the easiest approach to start with. It keeps everything self-contained within your Kubernetes cluster.

How it works:

1. You install the Sealed Secrets Controller into your cluster (via Helm or a manifest). On startup, it generates an RSA key pair and stores the private key as a Kubernetes Secret in the kube-system namespace.
2. Developers fetch the public key using kubeseal --fetch-cert.
3. A developer creates a standard Kubernetes Secret YAML locally (never committed), then runs kubeseal to encrypt it into a SealedSecret CRD using the public key.
4. The SealedSecret YAML is committed to Git — it is safe because it can only be decrypted by the controller holding the private key.
5. When ArgoCD/Flux syncs the SealedSecret to the cluster, the controller decrypts it and creates the standard Kubernetes Secret that your pods consume.

A developer generates a raw Kubernetes Secret locally (never committed), runs kubeseal against it using the cluster's public key to produce an encrypted sealed-secret.yaml, and commits only that sealed version to Git. The resulting SealedSecret object stores the same key names as the original Secret, but its values are RSA-encrypted ciphertext rather than reversible base64 — safe to commit.

Key rotation: The Sealed Secrets controller supports key rotation. When the private key is rotated, old SealedSecrets must be re-sealed with the new public key. This is a maintenance overhead to plan for.

2. SOPS (Secrets OPerationS — by Mozilla)

SOPS is more flexible and integrates with external Key Management Systems (KMS) — cloud services that manage cryptographic keys on your behalf. Instead of a key living inside the cluster, the key lives in AWS KMS, Azure Key Vault, GCP KMS, or HashiCorp Vault.

How it works:

1. You configure SOPS with a KMS key ARN (or equivalent). Access to this key is controlled by IAM policies — only authorized IAM roles (your developers, your cluster's node IAM role) can use the key.
2. You use the SOPS CLI to encrypt specific values within your YAML file before committing, pointing it at that KMS key. The resulting file keeps the YAML structure readable — apiVersion, kind, and metadata.name stay plaintext — but each secret value under data becomes an encrypted ciphertext string, with a sops metadata block recording which KMS key was used.
3. Your GitOps tool (ArgoCD with the SOPS plugin, or Flux with the ksops generator) decrypts the file just before applying it to the cluster, using the cluster node's IAM role to call KMS.

Choosing between them:

Use Sealed Secrets for simplicity when you need in-cluster decryption and don't have a KMS requirement. Use SOPS when you need cloud IAM integration, multi-cluster support, or centralized key management across teams.