Secrets, Sealing, and the Cost of Exposure

Doctrine

A secret is a promise: access is limited, rotation is possible, and exposure is detectable. Kubernetes Secrets are a mechanism, not a guarantee.

Kubblai doctrine demands explicit sealing practices because credential exposure is an inevitability at scale.

Kubernetes realities

Secrets are base64-encoded. Encryption at rest depends on control plane configuration. Access is governed by RBAC and service account identity.

If you treat Secrets as safe by default, you have already lost the incident.

• Limit who can read Secrets; avoid broad list/watch permissions.
• Prefer short-lived credentials where possible.
• Audit Secret access and changes.

Rotation as an operational requirement

Rotation is not a security checkbox; it is the ability to recover from compromise. If you cannot rotate safely, you are trapped by your own credentials.

Design workloads and libraries to reload secrets without downtime where feasible.

External secret systems (tradeoffs)

External secret managers can reduce blast radius and improve lifecycle control, but they introduce dependencies and failure modes (latency, availability, caching semantics).

Kubblai doctrine: don’t replace one kind of fragility with another without measuring it.