.png)
In modern cloud-native development, Kubernetes has emerged as the de facto standard for orchestrating containerized applications. While Kubernetes excels at managing workloads, scaling pods, and automating deployments, it also exposes a critical challenge: managing sensitive data securely. Whether it’s API keys, database passwords, authentication tokens, or TLS certificates, secrets in Kubernetes need special handling. Unfortunately, Kubernetes’ native Secret resources fall short on this front.
Enter Sealed Secrets, a powerful and production-friendly solution to this gap. Sealed Secrets allow you to encrypt your Kubernetes secrets into a "sealed" format that is safe to store in public or private Git repositories. This transforms how teams approach secure secret management in Kubernetes, especially in GitOps workflows, CI/CD pipelines, and collaborative infrastructure as code.
In this comprehensive blog post, we’ll explore the foundational need for secure secret handling in Kubernetes, unpack what Sealed Secrets are, how they work, how to implement them, their benefits over traditional secret methods, and real-world tips to avoid common mistakes. This blog is tailored for developers and DevOps professionals who are building secure, scalable, and maintainable cloud-native systems.
One of the biggest misconceptions among Kubernetes newcomers is the belief that a Kubernetes Secret is inherently secure. But this is only partially true. In reality, a Kubernetes Secret is just a Base64-encoded key-value store. This means the data is not encrypted, merely obfuscated. Anyone with access to etcd, or to a backup of it, can easily decode secrets. For instance, an API key encoded in Base64 is trivially reversible.
In many organizations, secrets are managed using GitOps, where manifests are committed into Git repositories. If Kubernetes Secrets are directly committed, even Base64-encoded, they are exposed to all users who have access to the repository. This introduces major vulnerabilities, especially in organizations with large development teams or in environments with multi-tenant GitOps pipelines. Storing plain secrets in Git is akin to leaving a house key under the welcome mat, convenient, but risky.
Without a robust secret encryption solution, companies may fall short of compliance requirements such as SOC2, GDPR, or HIPAA. Auditors often flag Base64 Kubernetes secrets, especially if stored in version control, as insecure. This can lead to operational slowdowns, forced migrations, or even data breaches if not addressed properly.
A Sealed Secret is a Kubernetes custom resource created and maintained by Bitnami. It is designed to allow developers to store encrypted secrets safely in Git repositories. The encryption is asymmetric, using a public/private key pair. The public key is used to seal (encrypt) the secret, and the private key is held by the controller in the Kubernetes cluster to unseal (decrypt) the secret when the manifest is applied.
One of the biggest advantages of Sealed Secrets is their seamless integration into GitOps workflows. Sealed Secrets are declarative, version-controllable, and can be applied like any other Kubernetes manifest. This allows teams to manage secrets the same way they manage deployments, services, and ingress configurations, with clarity, consistency, and automation.
Because the secret is encrypted with a one-way process (public key encryption), it can be committed to version control with zero risk. Even if the sealed secret is made public, it cannot be decrypted without the corresponding private key, which resides only inside the Kubernetes cluster.
There are two main components involved in the Sealed Secrets ecosystem:
This design ensures complete separation between the encryption and decryption processes, enhancing security and reliability.
The heart of the system lies in its asymmetric cryptography. The public key is used to encrypt data and can be freely distributed, even embedded in CI/CD pipelines or committed to Git. The private key is kept secure within the cluster and is never exposed externally.
This ensures that even if the encrypted SealedSecret file is leaked, it cannot be decrypted outside the cluster, preserving confidentiality.
Sealed Secrets also supports key rotation, scope scoping, and re-sealing. This adds operational resilience and flexibility. Secrets can be scoped to a specific namespace, or made reusable across multiple environments. Teams can rotate keys periodically without losing backward compatibility, allowing previously sealed secrets to remain valid even as new keys are introduced.
With Sealed Secrets, secrets become first-class citizens in infrastructure as code. Teams can declaratively manage secrets in the same Git repositories where they store Helm charts, deployments, services, and other manifests. This aligns security with DevOps best practices.
Storing encrypted secrets in Git provides an audit trail. Every change to a secret is versioned, timestamped, and subject to code review. This drastically improves traceability, helping organizations meet audit requirements.
Because Sealed Secrets work like any other Kubernetes object, they can be integrated into CI/CD pipelines without any special runtime secrets management logic. This simplifies automated deployments and improves reliability across environments.
Kubernetes’ native Secret object lacks encryption by default and must rely on third-party encryption at the etcd level, which is often misconfigured. Sealed Secrets, on the other hand, encrypt secrets client-side and ensure safe storage from source to runtime.
HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault are powerful tools but come with complexity, operational overhead, and cost. They require service integrations, runtime calls, tokens, and access policies. Sealed Secrets simplifies the workflow by encrypting secrets once and storing them in Git, avoiding external dependencies entirely.
Mozilla SOPS is another Git-friendly encryption tool but lacks the Kubernetes-native controller that automatically unseals secrets inside the cluster. With Sealed Secrets, no manual key handling or inline decryption logic is needed, just apply the sealed manifest.
The default mode, strict scoping, ties a sealed secret to a specific name and namespace. This offers the highest level of safety, ensuring secrets cannot be misapplied or reused unintentionally.
This allows the sealed secret to be reused within the same namespace. It is useful for shared secrets across multiple applications or deployments.
This is the most permissive and should be used with caution. It allows the sealed secret to be unsealed anywhere in the cluster. This is sometimes useful in multi-tenant environments but should be paired with strong RBAC controls.
In real-world Kubernetes environments, CI/CD systems like Jenkins, GitLab CI, GitHub Actions, and ArgoCD play a central role. Sealed Secrets easily fits into these workflows. A pipeline can generate a secret, seal it using the public key, commit the manifest to Git, and trigger a deployment, all without exposing any secret data at any point in the process.
This guarantees a secure and reproducible pipeline that minimizes human error and ensures no sensitive data is ever logged or stored inappropriately.
Proper key rotation is essential in any cryptographic system. Sealed Secrets supports automated and manual key rotation. Best practices include:
These practices ensure that secrets remain secure over time, even as access needs evolve.
In scenarios where development, staging, and production environments share infrastructure, Sealed Secrets allow each environment to use its own encryption key, minimizing blast radius in case of compromise.
For developers maintaining open source projects, Sealed Secrets allow you to safely share example manifests with encrypted secrets included. Users can apply them to their clusters without fear of exposure.
Because SealedSecrets are stored in Git and the decryption logic exists in the cluster, recovery from failure is easy. Redeploying the controller with its private key and applying the manifests brings the system back to life without re-entering credentials manually.
Sealed Secrets offer a compelling way to manage secrets in Kubernetes, especially in GitOps-driven environments. With client-side encryption, Git-safe storage, and automated decryption within clusters, it bridges the gap between security, convenience, and automation.
For developers building modern, cloud-native systems, whether on public cloud, hybrid setups, or internal infrastructure, Sealed Secrets provide a scalable, lightweight, and effective solution for managing secrets without sacrificing the benefits of version control, CI/CD integration, or developer velocity.
If your team uses Kubernetes, and you’re still managing secrets manually, through environment variables, or via third-party vaults with high operational overhead, Sealed Secrets might be the game-changer you’ve been looking for.
.png)
