Sealed Secrets

The core mechanism relies on public-key cryptography. The kubeseal client fetches the public key from the controller and encrypts the Secret data locally. Only the controller running in the cluster possesses the corresponding private key to decrypt it. This ensures that the SealedSecret custom resource, which is a purely encrypted blob, can be safely committed to public or private Git repositories without exposing sensitive values.

Instead of storing a standard Kubernetes Secret, users define a SealedSecret CRD. The controller watches for these resources and performs a one-way transformation:

• Input: A SealedSecret containing encrypted data fields.
• Output: A standard Secret object with decrypted values.
• Cleanup: The original SealedSecret can be garbage-collected or retained as the declarative source of truth. This decoupling allows Git to be the source of truth for encrypted secrets while the live cluster holds the plaintext only in memory.

Decryption is strictly cluster-bound. The private key is generated and stored as a standard Kubernetes Secret within the controller's namespace on first install. A SealedSecret encrypted for one cluster cannot be decrypted by a controller in a different cluster unless the private key is explicitly shared. This prevents lateral movement of secrets across environments and enforces a strict identity-binding between the encrypted artifact and its target runtime.

The controller supports automatic key rotation to maintain cryptographic hygiene. It maintains a list of active and deactivated private keys. When a new key is generated, it becomes the primary encryption target for kubeseal. Old keys are retained solely for decrypting existing SealedSecret resources. This allows for a seamless re-encryption process:

• Existing secrets continue to decrypt using the old key.
• New secrets are encrypted with the latest key.
• A manual re-seal operation can update old secrets to the new key without downtime.

To prevent secret replay attacks, the encryption process can be scoped to a specific namespace and secret name. By default, kubeseal binds the encrypted data to the exact namespace/name combination specified during sealing. If a malicious actor copies the SealedSecret manifest to a different namespace or renames it, the controller will refuse to decrypt it. This strict binding can be relaxed with the --scope flag for broader use cases, but strict mode is the secure default.

Sealed Secrets is inherently suited for disconnected environments. The entire encryption operation is performed client-side by kubeseal using a public key that can be fetched once and cached. No network connectivity is required during the sealing process. The controller operates entirely within the cluster, requiring no external dependencies or calls to a cloud Key Management Service. This makes it a critical component of a sovereign AI infrastructure stack where external API calls are prohibited.

The native Kubernetes object for storing sensitive data such as passwords, OAuth tokens, and SSH keys. By default, Secrets are stored unencrypted in the etcd key-value store, making them a critical security boundary. They can be mounted as data volumes or exposed as environment variables to pods.

• Base64 encoding is not encryption
• Requires explicit RBAC permissions for access
• Limited to 1MB in size per Secret
• Can be consumed as files, env vars, or image pull secrets

Role-Based Access Control is the primary authorization mechanism for protecting Kubernetes Secrets. By defining fine-grained Roles and RoleBindings, cluster administrators can restrict which users and service accounts can read, create, or modify specific Secrets within a namespace.

• Use least privilege principle: only grant get on specific named Secrets
• Audit access with kubectl auth can-i get secrets
• Combine with Pod Security Admission to prevent privileged container escapes
• Service accounts should never mount Secrets they don't explicitly need