Sealed Secrets in Kubernetes: How It Works

Sealed Secrets in Kubernetes lets you keep encrypted secret manifests in Git without putting the secret values in the repo. The flow is simple: kubeseal encrypts a Kubernetes Secret with the cluster’s public key, then an in-cluster controller turns it back into a usable Secret.

We analyzed 33 comments and questions from YouTube, Reddit and Quora about Sealed Secrets for Kubernetes and found that 24% asked about key rotation and backup concerns.

That helps with GitOps, but it doesn’t solve every secret-management problem. Here’s how the pieces fit, where teams run into trouble, and when a different approach may suit your setup better.

What Sealed Secrets Does in Kubernetes

Kubernetes Sealed Secrets is an open-source pattern for storing encrypted secret manifests alongside other cluster config. Instead of committing a plain Kubernetes Secret, you commit an encrypted manifest. The encrypted data can be read in the repo, but it can’t be turned back into the original values without the controller’s private key.

The system has three main parts. The kubeseal command-line tool seals a Secret manifest. An encrypted manifest holds the sealed result. The controller runs in the cluster and decrypts that manifest into a normal Kubernetes Secret for workloads to use.

This makes Git a place to store the encrypted form, not the source of readable secret values. Teams can review changes to the manifest in a pull request and use their GitOps process to apply it. For the wider picture, see our guide to Kubernetes secrets management.

Once the controller creates the native Secret, Kubernetes handles it like other Secret objects. That means the sealed form protects data in Git, but it doesn’t change who can read the resulting Secret in the cluster. Access rules still matter, as does encryption at rest for the cluster’s data store.

Think of Sealed Secrets as a secure bridge between a Git repo and a cluster, not as a full replacement for access control or a central secrets service.

How Encryption and Decryption Work

The controller holds a private key. It makes the matching public key available to kubeseal. Anyone with the public key can encrypt a secret, but only a controller with the matching private key can decrypt it.

The encryption uses an asymmetric key pair.

The secret’s namespace and name also affect encryption. By default, a sealed secret is tied to both. A manifest sealed for payments-prod in the production namespace won’t decrypt if someone changes its name or applies it to another namespace. This strict scope helps stop encrypted data from being copied into a place where different users can access the resulting Secret.

Other scopes can loosen those ties. Namespace-wide scope allows a different name in the same namespace. Cluster-wide scope allows a secret to be used across namespaces. That can help with reuse, but it also removes safeguards. Keep strict scope for production unless you have a clear need to change it.

The public certificate isn’t secret, but it must match the controller key you intend to use. You can fetch it from the cluster or keep a trusted copy for offline sealing. If the controller’s key changes, a stale certificate can cause new SealedSecrets to be encrypted for the wrong key.

EnvManager takes a different route for teams that manage environment files across developers and CI/CD. It uses AES-256 encryption at rest, version control, and an immutable audit trail for secret changes. Those controls address team workflows, while Sealed Secrets focuses on encrypting Kubernetes manifests for a specific cluster.

Where kubeseal and the Controller Fit

kubeseal runs on a developer machine or in a controlled pipeline. The controller runs inside Kubernetes. You install both, then use the CLI to turn a valid Secret manifest into a SealedSecret manifest.

The project supports installation through a Helm chart or a Kubernetes manifest. A manifest-based install can be customized for the environment. In environments where cluster-wide RBAC resources can’t be created, the project also documents a restricted manifest that omits those resources. Check the chosen deployment’s permissions and scope before applying it.

After installing the controller, fetch its public certificate. For an offline workflow, save that certificate in a trusted location and pass it to kubeseal with the --cert option. This is useful when a developer or build runner can’t reach the Kubernetes API. But the certificate needs an owner and a refresh process, or the team may keep sealing with an old key.

A simple flow looks like this:

kubeseal --format yaml --cert public-cert.pem < secret.yaml > sealed-secret.yaml

Review the generated file before committing it. The input file contains plaintext, so keep it out of Git, build artifacts, and logs. In production, let your GitOps controller apply the sealed manifest rather than relying on a developer to apply it by hand.

Flux can apply SealedSecret resources through its normal GitOps flow. Argo CD can do the same once the controller and resource definition are installed. The controller then watches for SealedSecrets and creates or updates the matching Kubernetes Secret. A useful next step is to check the EnvManager CLI commands if your workflow also needs to generate Kubernetes Secret manifests from managed environment values.

If a SealedSecret doesn’t produce a Secret, check that the controller is running and that the resource’s name and namespace match its sealed scope. Then inspect the controller logs for a decryption or permission error. Those checks often separate a stale key problem from a deployment or access issue.

Security Boundaries and Operational Risks

Sealed Secrets protects encrypted manifests outside the cluster. It doesn’t hide the Secret after decryption. A user or workload with enough Kubernetes permissions may still read the native Secret, and base64 encoding is not encryption. Limit API access and configure encryption at rest for cluster data.

Key recovery is the biggest operational risk. The controller’s private keys are stored as Kubernetes Secret objects in its namespace. If those keys are lost, existing SealedSecrets may no longer decrypt. Include the controller keys in backups, protect those backups carefully, and test restoring them before a real recovery event.

Key rotation needs a plan, too. The controller can retain older keys so it can still decrypt existing sealed values after a new key is added. But don’t assume that every backup contains the latest key set. If a cluster is rebuilt with an old or missing backup, the controller may fail to decrypt the manifests in Git.

There’s a second rotation task: refreshing the public certificate used by developers and CI jobs. If a pipeline seals a new value with an outdated certificate, the controller may not be able to decrypt it. Track the certificate source and test the sealing step when keys change.

Cluster scope deserves extra care in shared environments. If a person can copy a cluster-scoped SealedSecret into a namespace they control, the controller may create a readable Secret there. Strict scope blocks that kind of move by binding the encrypted data to its intended name and namespace.

Sealed Secrets also doesn’t provide a complete audit view of who read a decrypted value. Git history can show changes to the encrypted manifest, but it doesn’t show every access to the Secret inside Kubernetes. If you need to review access or prove who changed a value, pair the workflow with access logs and a secrets system that records those events.

When Sealed Secrets Is a Good Fit

Sealed Secrets fits teams that want secret manifests in Git and already use Kubernetes as the place where workloads consume those values. It keeps plaintext out of the repo while preserving a declarative deployment flow. That can be enough for a small number of secrets in one cluster, especially when updates are planned and a team can manage key backups.

It can also work well when the team wants to keep its existing Kubernetes Secret model. The controller creates a normal Secret, so applications don’t need a new way to read credentials. For a deployment pipeline, the key question is whether the process can securely handle the plaintext input before sealing it.

Sealed Secrets is less convenient when the same secret must move often between clusters. A sealed value is tied to its controller’s key, so a target cluster with a different key needs a newly sealed manifest. Multi-cluster setups can still use it, but each cluster needs a clear key and certificate process.

Consider a different pattern when secrets need to stay in a central store and rotate often. SOPS encrypts files with keys held outside the cluster, while a backend-sync approach syncs values into Kubernetes. Each shifts where the source of truth and decryption step live. Choose based on who needs access and how the value reaches the running workload.

EnvManager is aimed at teams that need a shared place to manage .env files and sync secrets to local machines or CI/CD pipelines. It may fit alongside Kubernetes delivery when you want team-level control over environment values, rather than relying on sealed manifests as the only source of secret history.

Use this quick decision rule:

• Choose Sealed Secrets when encrypted manifests in Git match your deployment model.
• Plan for another system when you need centralized secret access across many clusters or services.
• Use strict scope for production values and keep controller keys in tested backups.

Frequently Asked Questions

Can you store SealedSecrets in Git?

Yes, you can store SealedSecret manifests in Git because their secret values are encrypted for the controller’s public key. Keep the original plain Secret file out of the repository, logs, and build artifacts. Also protect the controller’s private key, since anyone with that key and the sealed data may be able to recover the secret values.

Can a SealedSecret be used in another Kubernetes cluster?

Usually, no. A sealed value is encrypted for the key held by its target cluster’s controller. A different cluster won’t have the matching private key, so you need to seal the Secret again with that cluster’s public certificate. Treat each cluster as a separate key boundary unless you have deliberately designed another arrangement.

What happens if the Sealed Secrets key is lost?

If the controller’s private key is lost, it may not be able to decrypt existing SealedSecrets. Restore the key from a protected backup before applying the encrypted manifests to a rebuilt cluster. Test that recovery path ahead of time, and include keys created during rotation in the backup process.

Does Sealed Secrets rotate the secret inside my app?

No. Sealed Secrets helps encrypt and deliver a Kubernetes Secret, but your application still needs to pick up a changed value. Some workloads read secrets only when they start, so a rotation may require a restart or redeploy. Test the full path, from updating the credential to confirming the app uses it.

Conclusion

Use Sealed Secrets when encrypted manifests in Git fit your Kubernetes workflow, and treat key backup, scope, and rotation as part of the design. Start by installing the controller in a test cluster, then run a restore test before you trust the setup with production secrets.