CKS System Hardening Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Disable peer client cert authentication

  Why it's wrong here

  Disabling peer client cert authentication is wrong because etcd cluster peers must mutually verify each other's identity via client certificates to establish a secure communication channel. Without this mutual TLS authentication, an attacker can introduce a rogue etcd member, intercept inter-node traffic, or tamper with cluster state. This would compromise the integrity and availability of the entire Kubernetes control plane.

• ✓

  Bind etcd to localhost only if not required to be accessible from other nodes

  Why this is correct

  Binding etcd to localhost only is a recommended practice when the etcd instance does not need to be reached from other nodes, such as when kube-apiserver runs on the same host. By listening only on the loopback interface, you eliminate the entire external network attack surface, preventing remote attackers from even connecting to etcd. This is a simple but effective network-layer security control that reduces exposure to unauthorized access.

• ✗

  Allow anonymous access to etcd for performance

  Why it's wrong here

  Allowing anonymous access to etcd for performance is dangerous because it removes all authentication mechanisms, meaning anyone who can reach the etcd endpoint can read or modify the cluster's entire state, including secrets, configuration, and certificates. This dramatically increases the risk of data exfiltration and cluster takeover. Performance gains are negligible and never justify such a critical security hole; proper authentication via client certificates is mandatory.

• ✓

  Enable encryption at rest for etcd data

  Why this is correct

  Enabling encryption at rest for etcd data is correct because etcd stores all Kubernetes objects, including Secrets, which would otherwise be written as plaintext to the host's disk. If an attacker gains physical or filesystem-level access, they could easily read these sensitive values. Encryption at rest, typically implemented with a KMS provider and envelope encryption, ensures that even if the disk is compromised, the data remains unreadable without the appropriate decryption keys.

• ✓

  Use TLS for all etcd client-to-server communication

  Why this is correct

  Using TLS for all etcd client-to-server communication is recommended because it encrypts all data transmitted between clients, such as kube-apiserver, and the etcd server, preventing eavesdropping and man-in-the-middle attacks on the network. TLS also provides server authentication, ensuring clients are communicating with the genuine etcd server and not an imposter. This is a fundamental requirement for maintaining confiidentiality and integrity of control plane traffic.

Go deeper

Related to this question