Hands-on Lab·Certified Kubernetes Security Specialist
Encrypting Secrets at Rest in etcd
Secrets are base64 in the API and plaintext in etcd, and turning that off means editing the apiserver. This guide does it on a real control plane, proves it from inside etcd, and then finds the Secrets that encryption did not touch.
Microservice Vulnerabilities Guide 20 of 40 Advanced
- Kubernetesapiserver v1.36.4, kubelet v1.36.3
- Runtimecontainerd 2.2.6
- CNICilium 1.18.1
- Built withkubeadm v1.36.3
- TimeAbout 22 min
Run on cka8001, the single-node cluster this path uses for control-plane changes. The manifest was backed up first and restored at the end, and the test namespace was deleted before the revert.
- Host kernel7.0.0-29
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA8001 | 192.168.0.56 | Ubuntu 26.04 LTS | Single Node (control plane, untainted) | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when Secrets must not sit in plaintext inside etcd. This matters because turning encryption on changes nothing for the Secrets that already exist - they stay readable until something rewrites them.
- reading a Secret straight out of etcd, and finding it in plaintext
- writing the encryption configuration, and the three apiserver changes that load it
- reading two Secrets back from etcd, where only the new one has actually changed
- rewriting every existing Secret so the old ones are covered too
Before you start
-
What a Secret looks like in etcd
-
The configuration, and the flag that loads it
-
The new Secret, and the old one
-
Rewrite what is already there