CKS Practice Question: Restrict access to etcd so that only the API…

Answer analysis

Option-by-option breakdown

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

• ✓

  Configure etcd with TLS client certificates and require authentication

  Why this is correct

  When etcd is started with --client-cert-auth=true and a --trusted-ca-file, it requires every client to present a valid X.509 certificate signed by that CA. The kube-apiserver is configured with its own client certificate and key, enabling mutual TLS (mTLS) so etcd verifies both the identity of the API server and the integrity of the encrypted channel. This cryptographically guarantees that only the API server—and any other explicitly trusted client—can read or write cluster state, preventing both unauthorized access and eavesdropping.

• ✗

  Set the etcd flag --peer-auto-tls=true

  Why it's wrong here

  The --peer-auto-tls=true flag only affects the etcd cluster's peer-to-peer communication; it tells etcd to automatically generate self-signed certificates for inter-node traffic between etcd members. It has no impact on the client-facing port (2379) and does not require or validate any client certificates, so the API server can still connect without proving its identity. In fact, relying on auto-generated peer TLS can create a false sense of security because the peer certificates are not signed by a trusted CA, leaving client interfaces unauthenticated.

• ✗

  Configure etcd to use RBAC with a role that allows only the API server

  Why it's wrong here

  etcd RBAC (enabled with --auth-token and user/role definitions) can restrict access based on usernames and roles, but the Kubernetes API server does not authenticate itself to etcd using an etcd user or password; it presents a TLS client certificate instead. Without mapping the API server's certificate identity to an etcd role, the RBAC layer would reject or ignore the API server, or require complex and non-standard authentication proxying that is not part of a normal Kubernetes deployment. The ecosystem-wide convention is to rely on client certificate authentication (--client-cert-auth) rather than etcd RBAC, which is designed for native etcd clients, not for the Kubernetes control plane.

• ✗

  Use a firewall rule to restrict access to etcd's port from the API server's IP

  Why it's wrong here

  A firewall rule that only allows traffic from the API server's IP address provides coarse network-level filtering, but it does not authenticate the client or protect the data in transit. An attacker who has already achieved code execution on the API server host, or who spoofs its source IP, would still be able to access etcd; conversely, firewalls do not stop lateral movement from other control-plane components that might share the same network segment. In a zero-trust Kubernetes architecture, mTLS is the required authentication mechanism because it validates identity at the application layer and encrypts payloads, whereas a firewall is at best a defense-in-depth control that cannot replace certificate-based authentication.

Go deeper

Related to this question