CertGrid CertGrid
Hands-on Lab·Kubernetes and Cloud Native Security Associate

etcd Security and Access Control

Every object in the cluster is a row in etcd, so etcd access is cluster access - and on a default kubeadm cluster the Secrets in it are not encrypted. This guide proves both halves of that sentence.

Cluster Component Security Guide 11 of 42 Intermediate

etcd 3.6.8 with --client-cert-auth=true, as kubeadm configures it. The encryption-at-rest gap is also kubeadm's default: no --encryption-provider-config is set.

The cka5001 cluster: one control plane and 3 schedulable workers, on Cilium.
Server NameIP AddressOSRolesCPURAMHDD
CKA5001192.168.0.41Ubuntu 26.04 LTSControl Plane Node (tainted NoSchedule)2 Core4 GB50 GB
CKA5001-NODE01192.168.0.42Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB
CKA5001-NODE02192.168.0.43Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB
CKA5001-NODE03192.168.0.44Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB

This guide includes

Use this when you have to explain why etcd access is cluster access. This matters because every object is a row in etcd, Secrets are stored base64 rather than encrypted by default, and one absent flag is the whole of the difference.

Before you start

  1. How etcd is protected, and where it listens

  2. The handshake refusal, which `-s` hid

  3. A distroless component, which is the hardening working

  4. The Secret, three ways

  5. The flag that would have stopped it

Official sources

← All KCSA guides