A Kubernetes controller and tool for encrypting Secrets into SealedSecrets that can be safely stored in Git.
Sealed Secrets is a Kubernetes-native solution for managing sensitive configuration data like passwords and API keys in a GitOps workflow. It encrypts standard Kubernetes Secrets into SealedSecret custom resources that can be safely stored in version control. The SealedSecret can only be decrypted by a controller running inside the target Kubernetes cluster, preventing exposure of plaintext secrets.
Kubernetes administrators and DevOps engineers who practice GitOps and need a secure way to manage secrets within their configuration repositories. Teams deploying to multiple clusters or requiring audit trails for secret changes will find it particularly valuable.
Developers choose Sealed Secrets because it seamlessly integrates with existing Kubernetes tooling and Git workflows, providing strong encryption without complex external key management. Its client-side tool (`kubeseal`) is simple to use, and the controller automatically handles key renewal, reducing operational overhead compared to manual secret management.
A Kubernetes controller and tool for one-way encrypted Secrets
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Encrypts Kubernetes Secrets into SealedSecrets that can be safely committed to version control, enabling full Git-based configuration management as highlighted in the README's philosophy.
Controller automatically rotates sealing keys every 30 days (configurable), reducing manual security overhead and ensuring long-term encryption integrity without user intervention.
Supports strict, namespace-wide, and cluster-wide decryption scopes, allowing precise control over where and how secrets can be unsealed, detailed in the Scopes section.
The kubeseal CLI can work offline with a fetched certificate, making it usable in restricted or air-gapped environments, as noted in the Public key / Certificate section.
Secrets can only be decrypted by the controller in the target cluster; loss of cluster access means secrets are irrecoverable without prior key backups, a limitation admitted in the FAQ.
While keys auto-renew, updating existing SealedSecrets to use new keys requires manual re-encryption with kubeseal --re-encrypt, adding operational complexity as described in the Re-encryption section.
Currently lacks native support for HSM or cloud KMS integration, relying on cluster-managed keys, which the README notes is a work in progress and may not meet high-security compliance needs.