.png)
In the ever-evolving world of Kubernetes and DevOps, securing sensitive data like credentials, tokens, certificates, and keys is not just an operational requirement, it’s a security imperative. As more teams embrace GitOps workflows, where the entire system configuration is stored in version-controlled repositories, managing secrets securely becomes even more critical. That’s where Sealed Secrets come into the picture.
Sealed Secrets, introduced by Bitnami, solve one of the most pressing problems for Kubernetes operators and developers: how to manage Kubernetes secrets securely in a Git-centric, declarative infrastructure. With Sealed Secrets, developers can safely store encrypted secrets in a public or private Git repository, knowing they will be decrypted only by the intended Kubernetes cluster and controller.
The central idea is simple but powerful: encrypt secrets before committing them to Git, using a controller in the Kubernetes cluster that holds the private decryption key. This lets teams fully embrace GitOps principles while maintaining strict security standards.
At the core of Sealed Secrets is the Sealed Secrets controller, a Kubernetes-native component that performs the essential job of decrypting SealedSecrets resources and transforming them into traditional Kubernetes Secrets. It runs inside the Kubernetes cluster and is deployed as a controller, typically within the kube-system or a custom namespace.
When you install this controller, it automatically generates a cryptographic key pair. The private key remains secure inside the cluster, used only by the controller, while the public key is made accessible so that developers can encrypt secrets before they reach the cluster. This split of responsibility ensures that sensitive data never leaves the developer's machine in an unencrypted format.
To encrypt Kubernetes Secrets into Sealed Secrets, developers use the kubeseal command-line tool. This tool interacts with the Sealed Secrets controller to retrieve the public key and use it to encrypt secrets. This encryption happens entirely on the client side, meaning the actual secret values never need to travel over the network unencrypted or touch any CI/CD pipeline in plaintext.
Developers create a standard Kubernetes Secret manifest, then use kubeseal to convert it into a SealedSecret manifest. This new SealedSecret resource is safe to commit to Git, push to remote repositories, and include in GitOps automation pipelines.
When the Sealed Secrets controller is deployed into a Kubernetes cluster, it automatically generates an asymmetric RSA key pair. This key pair plays a pivotal role in ensuring that secrets can be encrypted externally and decrypted securely within the cluster.
This asymmetric encryption model ensures that even if someone has access to the public key, they cannot decrypt any data sealed with it unless they also have access to the private key.
After fetching the public key, the next step is to encrypt a standard Kubernetes Secret into a SealedSecret. This encryption includes both:
This hybrid encryption strategy provides a strong balance of performance and security. Once encrypted, this SealedSecret object is safe to store in Git, even in public repositories, without exposing sensitive information.
Once committed to the Git repository, Sealed Secrets become part of your infrastructure-as-code (IaC). Tools like FluxCD, ArgoCD, or custom CI/CD scripts will apply the SealedSecrets to your Kubernetes cluster.
Upon detecting a new SealedSecret resource, the controller does the following:
This workflow integrates seamlessly with GitOps practices, offering both automation and security without compromise.
Sealed Secrets supports multiple scoping strategies that dictate where and how a sealed secret can be decrypted. These options give teams flexibility based on their security policies:
The scoping mechanism adds a powerful layer of security by enforcing contextual binding. Even if a SealedSecret is somehow leaked, it can only be decrypted in the intended context.
Access to Sealed Secrets can be tightly managed using Kubernetes RBAC policies. By restricting who can create SealedSecrets or fetch the public key, administrators ensure that only trusted CI/CD processes or developers can contribute new secrets to the system. This makes it easy to integrate with enterprise-grade security and auditing practices.
Sealed Secrets drastically improve the developer experience by simplifying secret management. Developers no longer need to manage shared vaults, rotate credentials manually, or worry about secrets leaking in Git history.
With just one command, they can encrypt a secret and push it to Git, knowing that it's safe by design. No change in deployment logic, no separate tools for decrypting at runtime, and no runtime secrets injection issues.
Sealed Secrets ensures that secrets are never stored in plaintext, either locally or in CI/CD pipelines. Every SealedSecret is write-only, once created, it cannot be decrypted by the developer or pipeline. Only the controller inside the Kubernetes cluster can decrypt and use it. This provides immutable, tamper-proof secret management.
Because Sealed Secrets can be safely committed to Git, they align perfectly with GitOps principles. Every infrastructure component, including secrets, can be version-controlled, reviewed, audited, and deployed automatically. This consistency makes it easy to:
The controller supports automatic key rotation. Best practices include:
Regular rotation ensures that even if a key is compromised, previously sealed secrets cannot be decrypted.
Backup of both the controller’s private key and SealedSecrets manifests ensures complete recovery in case of disaster. The manifest itself is not sufficient, if the private key is lost, the secrets become unrecoverable. Therefore, store private keys securely in offline or vaulted systems.
You can automate Sealed Secret creation in CI/CD pipelines by:
No secret ever exists unsealed in logs or persistent storage. This security-by-default design makes Sealed Secrets one of the most GitOps-friendly solutions available.
Unlike external vault solutions that require service accounts, complex access controls, or external dependencies, Sealed Secrets:
While vaults are powerful and necessary for multi-environment secrets management, Sealed Secrets are simpler and purpose-built for GitOps use cases.
As GitOps adoption grows, the demand for robust, developer-friendly secret management continues to rise. The Sealed Secrets project is rapidly evolving with:
This makes Sealed Secrets a strong contender for default secret management in GitOps-native Kubernetes ecosystems.
In today’s cloud-native, security-conscious world, managing secrets safely is no longer optional, it’s essential. Sealed Secrets offers a powerful solution for developers, DevOps teams, and platform engineers who want to integrate secrets into their GitOps workflow without compromising security.
It encrypts secrets before they’re ever committed, decrypts only within the cluster, and supports scoping, automation, and auditing, all while remaining intuitive and easy to use.
If your team manages Kubernetes at scale and values automation, transparency, and security, adopting Sealed Secrets could be one of the most impactful decisions you make for your platform.
.png)
