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.
Interview question
What specific security risk does Kubernetes Secrets Encryption at Rest primarily mitigate?
- a.Malicious actors intercepting Secret data during network transmission.
- b.Exposure of Secret data from a compromised etcd database or its backups.Correct
- c.Sensitive information being readable within a running container's memory.
- d.Unauthorized users gaining access to Secret values through the Kubernetes API.
Why? this is the answer
The card explicitly states that encryption at rest protects against "compromised etcd backups or direct access to control plane node storage" because Secrets are otherwise stored as base64-encoded plain text in etcd. Option D is incorrect because access to Secrets via the Kubernetes API is controlled by RBAC, not by encryption at rest, which secures the underlying storage.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #security
- #etcd
- #secrets
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles