Hands-on Lab·Certified Kubernetes Security Specialist
Managing Kubernetes Secrets
Encryption at rest protects the datastore. This guide is about everything above it: how a Secret is consumed, where it ends up, what immutability buys, and the Role that looks like it restricts access and does not.
Microservice Vulnerabilities Guide 21 of 40 Intermediate
- Kubernetesapiserver v1.36.4, kubelet v1.36.3
- Runtimecontainerd 2.2.6
- CNICilium 1.18.1
- Built withkubeadm v1.36.3
- TimeAbout 16 min
Secret volumes are tmpfs on Linux nodes and mounted read-only when the Pod asks for it. immutable: true cannot be reversed - the Secret has to be replaced.
- Host kernel7.0.0-29
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA6001 | 192.168.0.46 | Ubuntu 26.04 LTS | Control Plane Node (tainted NoSchedule) | 2 Core | 4 GB | 50 GB |
| CKA6001-NODE01 | 192.168.0.47 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA6001-NODE02 | 192.168.0.48 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this once encryption at rest is done, because that only ever protected the datastore. This matters because a Secret still reaches a node and a container - and how it is consumed decides how far it spreads from there.
- consuming one Secret two ways, as an environment variable and as a volume
- using immutability, and writing a Role that looks careful
- finding what the node sees - the value, and where it physically lives
Before you start
- guide 11 - the other credential in a Pod.
-
The same Secret, consumed two ways
-
The parts that are not about mounting
-
What the node sees