Enabling encryption at rest in Kubernetes protects the stored copy of resources such as Secrets in the API server's data store. It does not protect data in volumes mounted into containers, and it does not stop an authorized user or Pod from reading a Secret. It is one layer, not the whole answer.
What the feature is
The Kubernetes documentation says the APIs that let you write persistent resource data support at-rest encryption, and Secrets are the usual example. This is additional to any system-level encryption of the etcd cluster or the host filesystems.
It also states the scope: the task covers resource data stored through the Kubernetes API, including Secret objects and the key-value data inside them.
What it protects against
Think of someone who obtains a copy of the storage behind the API server, for example a backup or a disk. Without encryption at rest, Secret values are readable in that copy. The docs caution that Secrets are by default stored unencrypted in the data store.
With the feature on, that stored copy holds encrypted values. The attacker needs the encryption keys as well.
What it does not protect against
Several routes stay open.
Anyone with API access can retrieve a Secret through the API, because the API decrypts for authorized callers. RBAC decides who that is.
The docs also say anyone who can create a Pod in a namespace can read any Secret in it, including indirectly through a Deployment. Encryption at rest does not change that.
For files mounted into containers, the docs say you need a storage integration with encrypted volumes, or you need to encrypt the data inside your application. API-level encryption does not reach there.
Where it fits in a plan
The docs list a minimum set of steps for using Secrets safely. Encryption at rest is the first. The others are least-privilege RBAC, restricting Secret access to specific containers, and considering external secret store providers.
A reasonable order for a small team: first look at who can read Secrets and who can create Pods in sensitive namespaces, because that costs nothing. Then enable encryption at rest. Then decide whether a short-lived credential from an external store would beat a long-lived stored one.
A verification habit
Do not assume a managed cluster has it on in the way you expect. Check your platform's documentation for how encryption of API data is configured, and test by reading how the data is stored, if you operate the control plane. If someone else operates it, ask for the setting in writing.
When you change the configuration, check the current Kubernetes task page for the exact procedure for your version, including how objects that were stored before the change get covered. Do not assume they are protected until you have confirmed it.
Also ask who holds the encryption keys and where they live. If the keys sit next to the data on the same host with the same access, the protection is thin. A key held by an external key service raises the bar, and the Kubernetes documentation covers the provider options.
The honest summary
Encryption at rest narrows one exposure, the stored copy. Your biggest exposures are usually access rights. Fix those too.
Quick check
Does encryption at rest stop a developer from reading a Secret?
No. Authorized API users still get the decrypted value. Access is controlled by RBAC and by who can create Pods in the namespace.
Does it encrypt files mounted into containers?
No. The docs say mounted filesystem data needs encrypted volumes or encryption inside your application.
Sources
Last reviewed: 19 October 2026.
