Sealed Secrets

Definition

Sealed Secrets is an open-source Kubernetes controller, originally developed by Bitnami, that encrypts a Kubernetes Secret into a SealedSecret custom resource that is safe to commit to a public or private Git repository, since only the specific controller instance running in the target cluster holds the private key needed to decrypt it back into a usable Secret. It solves the problem of storing Kubernetes secrets safely in version control for GitOps workflows, where the entire cluster configuration, including secrets, is meant to be declared as code.

Overview

Kubernetes Secrets are only base64-encoded by default, not encrypted, so committing a raw Secret manifest to a Git repository exposes its contents to anyone with repository access, which conflicts directly with GitOps practices that want the entire cluster state, including secrets, declared in version control. Sealed Secrets was built specifically to let teams keep encrypted secrets in Git safely, decrypting them only inside the specific cluster they are meant for. Mechanically, Sealed Secrets works as an asymmetric encryption scheme scoped to a single cluster. The Sealed Secrets controller running in the cluster generates a public and private key pair, keeping the private key inside the cluster and never exposing it. An operator uses the accompanying kubeseal command-line tool, which fetches the controller's public key, to encrypt a plain Kubernetes Secret into a SealedSecret resource. Because encryption uses the public key, anyone can create a SealedSecret without needing the private key, but only the controller holding the matching private key inside the target cluster can decrypt it, and it does so automatically, watching for SealedSecret resources and creating the corresponding regular Kubernetes Secret from them. By default, SealedSecrets are also bound to a specific namespace and resource name, preventing an encrypted secret from being reused in an unintended location within the same cluster. Sealed Secrets differs from a tool like SOPS in that it is Kubernetes-native end to end, producing a custom resource the cluster understands directly rather than encrypting a generic file that a separate process must decrypt before applying. It also differs from cert-manager in scope: cert-manager issues certificates from external authorities, while Sealed Secrets focuses narrowly on making arbitrary Kubernetes Secret data safe to store in Git. In practice, platform teams adopt Sealed Secrets specifically to support GitOps tools like Argo CD or Flux, committing SealedSecret manifests alongside other Kubernetes resources so the entire desired cluster state, secrets included, lives in a single Git repository that the GitOps controller reconciles automatically. The main limitation is that Sealed Secrets is tightly coupled to a single cluster's key pair, so migrating secrets between clusters or recovering after losing the controller's private key requires careful backup and key management, since there is no external key management system holding a copy the way SOPS delegates to a cloud KMS. It also does not offer secret rotation or dynamic credential generation, functioning purely as a one-way encryption mechanism for values destined to become static Kubernetes Secrets.

Key Features

• Encrypts Kubernetes Secrets into a SealedSecret custom resource
• Uses asymmetric encryption scoped to a single cluster's key pair
• Keeps the private decryption key inside the target cluster only
• Allows anyone to encrypt with the public key via the kubeseal tool
• Automatically decrypts SealedSecrets into regular Secrets in-cluster
• Binds encrypted secrets to a specific namespace and resource name
• Enables safe storage of Kubernetes secrets in Git repositories
• Integrates naturally with GitOps tools like Argo CD and Flux

Use Cases

Alternatives

Frequently Asked Questions

Related in DevOps