etcd is the key-value database that stores all Kubernetes cluster state, every object, configuration, and Secret. By default Secrets are stored only base64-encoded, not encrypted, so anyone who can read etcd can read every credential in the cluster. etcd listens on port 2379, and if it is reachable without client-certificate authentication, it is a full cluster compromise. Protect it with mutual TLS, network isolation, and encryption of Secrets at rest.
What etcd is
Kubernetes itself is stateless logic; the state lives in etcd, a distributed key-value store. When you create a pod, a config map, or a Secret, it is written to etcd. The API server is essentially a guarded front end over etcd.
That makes etcd the crown jewels: it contains everything, including Secrets. Critically, Secrets are stored base64-encoded by default, which is encoding, not encryption, so reading etcd reveals them in usable form.
The abuse and payload
If etcd (port 2379) is reachable without client-cert auth:
- Read every key, including Secrets:
etcdctl --endpoints=https://NODE:2379 get / --prefix --keys-onlythen fetch Secret values. - The returned Secret data is base64, trivially decoded into real credentials, tokens, and TLS keys.
- With those, authenticate to the API server or downstream systems and take over the cluster and its cloud account.
A backup of etcd left unprotected is the same exposure. Documented techniques shown for defenders.
How to defend
- Require mutual TLS (client certificates) for all etcd access; never allow anonymous connections.
- Network-isolate etcd so only the API server (control plane) can reach 2379.
- Enable encryption at rest for Secrets so etcd does not store them in recoverable form.
- Protect etcd backups with the same controls and encryption as the live store.
- Audit and test that etcd is unreachable from workloads and the network.
References
- [1]Kubernetes docs: Securing a cluster(Kubernetes)
- [2]MITRE ATT&CK: Containers Matrix(MITRE)
- [3]NIST SP 800-190 Application Container Security Guide(NIST)