Sealed Secrets
gunkanmaki.sealed-secrets
A Docker Compose file for Sealed Secrets alone, generated from the catalog and checked by the safety inspector. No account needed.
Kubernetes controller that decrypts SealedSecret resources into ordinary Secrets inside the cluster, so encrypted secret manifests can be committed to a Git repository safely.
Sealed Secrets pairs a cluster-side controller holding a private key with a client tool that encrypts a secret against the matching public key. The result is a custom resource only that controller can decrypt, scoped by namespace and name so it cannot be relocated elsewhere in the cluster to sidestep access control. Because the encrypted form is safe in public, secret manifests can live in the same repository as everything else, which is what makes a fully declarative workflow possible. Key rotation happens on a schedule with previous keys retained so existing resources continue to decrypt.
You know it worked when
- The controller starts and its custom resource definition is registered.
- The client tool retrieves the controller's public key.
- A secret encrypted with that key is accepted as a SealedSecret resource.
- The controller produces a matching Secret containing the original value.
- A SealedSecret applied to the wrong namespace is refused rather than decrypted.
Known sharp edges
- The controller's private key is the only thing that can decrypt existing resources, and losing it without a backup makes every SealedSecret in the repository permanently unreadable.
- Encryption is bound to namespace and name by default, so renaming or moving a resource requires re-encrypting it from scratch.
- Bitnami moved most Docker Hub images to an unmaintained legacy repository during 2025, so this reference may stop resolving or stop receiving security updates.
- The controller decrypts into ordinary Kubernetes Secrets, which are only base64-encoded at rest unless cluster encryption is configured separately.