Kubernetes Secrets: Encrypting Data at Rest
By default, Kubernetes Secrets are only base64-encoded, not encrypted. Encryption at rest makes the API server encrypt Secret data before saving to etcd, protecting against compromised backups.
WHY IT EXISTS: To solve the problem that Kubernetes Secrets are, by default, stored in etcd as base64-encoded plain text. Anyone with access to the etcd database or its backups can easily decode these Secrets. Encryption at rest adds a necessary layer of security for sensitive data.
THE MENTAL MODEL: Think of it as a safe deposit box inside the bank vault. The vault is etcd, and the safe deposit box is the encryption layer. Even if someone breaks into the vault (gets a copy of etcd data), they still need a separate key (the encryption key) to open the box and read your Secrets.
HOW IT WORKS: You provide the kube-apiserver with an EncryptionConfiguration file. This file specifies which resources to encrypt (like secrets) and which encryption provider to use, such as AES-CBC or an external KMS. When a Secret is created or updated, the API server uses this configuration to encrypt the data before writing it to etcd. When a Secret is read, the API server decrypts it on the fly before sending it to the client.
WHEN TO USE IT: Always use it in production clusters that handle any sensitive information. It's a baseline security measure and often a requirement for compliance standards like PCI DSS or HIPAA. It protects against data exposure from compromised etcd backups or direct access to control plane node storage.
WHEN NOT TO USE IT: The primary risk of using it is operational: you must have a robust process for managing and backing up your encryption keys. Losing the key means losing access to all your encrypted Secrets. For this reason, some may skip it in temporary, local development environments, but it is essential for production.
ONE CANONICAL EXAMPLE: After enabling encryption by passing an --encryption-provider-config flag to the kube-apiserver, you must force existing secrets to be re-written to be encrypted. You can do this by running a command like kubectl get secrets --all-namespaces -o json | kubectl replace -f -. This reads each secret and then writes it back, triggering the new encryption policy.
Read the original → kubernetes.io
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.