Kubernetes Secrets: External or Sealed Secrets?
Kubernetes secrets are only Base64 encoded, not encrypted. How External Secrets and Sealed Secrets keep secrets secure in plaintext and safely out of Git.
A Kubernetes Secret stores sensitive values in its default state as nothing more than Base64-encoded text. Anyone who knows where to look can decode those values in seconds. The real danger comes when these Secrets end up in a Git repository, where they persist in the history forever. Two established approaches move secrets out of plaintext without abandoning the GitOps workflow. The right choice depends on where you want the source of truth to live.
Key Takeaways
- Base64 is not encryption: Kubernetes Secrets are stored in etcd encoded by default, not encrypted. Anyone with access to etcd or the API can read them in plaintext. Real protection only comes from encryption at rest and tightly scoped API permissions.
- Plaintext in Git is the expensive mistake: A secret committed even once stays in the history. In 2025 alone, GitGuardian found 28.65 million hardcoded secrets in public repositories – a third more than the year before.
- Source of truth is the deciding factor: External Secrets pulls credentials from an external vault; Sealed Secrets encrypts them for Git. The choice depends on which system should own the secret.
Related:Cloud-native matures with Kubernetes 1.34 / OpenTofu vs. Terraform
Why a Kubernetes Secret is not actually secret
What is a Kubernetes Secret? A Kubernetes Secret is an object that separates sensitive data – passwords, tokens, keys – from the application configuration. Values are stored Base64-encoded in the central data store etcd by default. Base64 is an encoding scheme, not encryption, which means the Secret is readable in plaintext by anyone with access to etcd or the API.
That is precisely where the operational risk begins. Many teams treat the Secret object as protected because the value does not look immediately readable. In practice, the encoding is just a transport format. Without additional measures, the secret is exposed: in etcd, in every API response object, and in every cluster backup that captures state.
The first line of defense is therefore encrypting etcd itself, combined with strict API access controls. That protects the secret at rest – but it does not solve the second, larger problem: how the secret travels into configuration in the first place. That is where the real operational mistake happens.
When Plaintext Ends Up in Git
GitOps deliberately moves configuration into the repository. Committing the secret along with it is the actual mistake. A secret committed even once remains in the history, even if the next change removes it. Rotating the key doesn’t eliminate the old secret – it only adds a second one.
This public figure actually understates the internal risk. According to the same analyses, internal repositories contain hardcoded secrets roughly six times more often than public ones – because the perception of being closed off reduces diligence. The risk doesn’t fade over time: a significant share of secrets leaked years ago and still valid remains exploitable today. A secret in the Git history is an open risk for as long as it stays valid.
Two Ways Out: External Secrets and Sealed Secrets
Both approaches solve the same problem, but intervene at different points in the workflow. The External Secrets Operator keeps the secret outside the cluster and fetches it on demand. Sealed Secrets encrypts the secret so that no plaintext ever sits in the repository. The deciding factor is which system should own the secret.
| Criterion | External Secrets Operator | Sealed Secrets |
|---|---|---|
| Source of truth | external vault | the Git repository |
| What lives in Git | a reference only | encrypted secret |
| Rotation | centrally in the vault, automatic | re-encrypt and commit again |
| Dependency | external service must be reachable | controller key inside the cluster |
| Best suited for | existing vault, multiple clusters | pure GitOps without an external vault |
For teams with a central vault such as HashiCorp Vault or a cloud secret manager, the External Secrets Operator is usually the better choice. The secret stays in one place, rotation happens there, and Kubernetes receives only a temporary copy. Teams that want to avoid an external service and keep everything in the repository are well served by Sealed Secrets – but they must secure and rotate the controller key inside the cluster. The tooling itself also requires upkeep: a vulnerability reported in Sealed Secrets in 2026 shows that even the protective mechanism can become a patch target.
What Makes or Breaks Secure Secret Management
Whether a practice truly protects or merely feels secure comes down to implementation details. The following patterns separate one from the other.
What undermines security
- Treating a Base64 secret as protected while leaving etcd unencrypted
- Committing secrets once and trusting they’ll be removed later
- Long-lived keys with no rotation and no expiry date
- Granting controller or vault access as broadly as regular cluster access
What holds up
- Encrypting etcd and strictly limiting API access
- Never committing secrets in plaintext, and consistently applying one approach
- Short validity periods and automatic rotation as the default
- Keeping vault and controller keys separate and tightly scoped
The common denominator is a simple principle: a secret is only as secure as its least-protected location. Seeing through Base64, encrypting etcd, and consistently applying one approach takes far less effort than cleaning up after a leaked key. The tools are mature and freely available. What’s usually missing is simply the decision to take the secret more seriously than its encoding.
Frequently Asked Questions
Are Kubernetes Secrets encrypted?
Not by default. Values are stored Base64-encoded in etcd, and Base64 is an encoding, not encryption. Anyone with access to etcd or the API can read them in plain text. True encryption at rest must be enabled separately for etcd, alongside strict access controls.
What does the External Secrets Operator do?
It reads secrets from an external vault such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault, then automatically creates native Kubernetes Secrets from them. The source of truth stays in the vault; the cluster holds only a synchronised copy. The repository contains nothing but a reference – never the secret itself.
How do Sealed Secrets work?
A secret is encrypted with a public key that only a controller inside the cluster can decrypt. The encrypted object can safely be committed to the Git repository. When applied in the cluster, the controller decrypts it into a regular Secret. This keeps true GitOps possible without ever storing a secret in plain text.
Which approach is the right one?
It depends on where the source of truth should live. If a central vault already exists and multiple clusters are in play, the External Secrets Operator is the better fit. If everything should stay in the repository with no external service required, Sealed Secrets are the simpler path. Both are well-established – the difference comes down to where the secret resides.
What about secrets that are already in Git?
They are considered compromised and must be rotated – not just removed. Deleting them from the current version leaves the secret behind in history. The only safe course of action is to invalidate the affected key or password, reissue it, and then migrate the workflow to one of the two clean approaches.
Image credit: Title image AI-generated (June 2026), C2PA certificate embedded in image
