CKS Practice Question: Which etcd security measure should be implemented…

Answer analysis

Option-by-option breakdown

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

• ✗

  Enable anonymous authentication on etcd

  Why it's wrong here

  Enabling anonymous authentication on etcd is the opposite of what security hardening requires. With --client-cert-auth disabled or anonymous auth allowed, any user or process that can reach the etcd port can issue reads and writes without presenting any credential, directly exposing all Kubernetes Secrets, ConfigMaps, and cluster state stored in etcd. Anonymous access bypasses identity verification entirely and must be explicitly disabled so that only mutually authenticated clients can interact with the datastore.

• ✗

  Configure etcd to listen on localhost only

  Why it's wrong here

  Binding etcd to localhost only reduces the attack surface by preventing remote network connections, but it does not verify the identity of a client. Any local process, a compromised container that has host network access, or a user with shell access on the control-plane node can still connect to the loopback address and issue arbitrary etcd operations. Without TLS client certificates, there is no authentication; localhost binding is merely a network-layer restriction, not a security control that establishes client identity.

• ✓

  Enable TLS client-to-server authentication

  Why this is correct

  Enabling TLS client-to-server authentication, also known as mutual TLS, requires every client to present a certificate signed by a trusted CA that etcd validates using --client-cert-auth=true and --trusted-ca-file. This ensures that only the Kubernetes API server and other explicitly trusted clients can connect, while also protecting the data in transit from eavesdropping and man-in-the-middle attacks. It is the primary authentication mechanism for etcd because it cryptographically proves the identity of each client before any request is processed.

• ✗

  Use etcd RBAC with role-based access control

  Why it's wrong here

  Etcd RBAC provides authorization—constraining what operations an already-identified user can perform—but it does not establish who the user is in the first place. Without TLS client certificates to verify the identity of a connecting client, RBAC can be trivially bypassed because the username and roles are tied to unauthenticated or spoofable identifiers. TLS client-to-server authentication is the prerequisite that makes RBAC meaningful; RBAC alone cannot authenticate clients and thus cannot be the primary security measure.

Go deeper

Related to this question