Kubernetes and Cloud Native Security Associate (KCSA) free question 2 / 10 · Domain 2: Kubernetes Cluster Component Security
After TLS is set up for etcd, an operator wants etcd to accept clients that present a certificate from a specific CA. Which etcd flags does "Operating etcd clusters for Kubernetes" use for this?
- --client-cert-auth=true together with --trusted-ca-file pointing to that CA
- --etcd-certfile together with --etcd-keyfile set on the etcd server itself
- --tls-cert-file together with --tls-private-key-file set on the etcd server
- --peer-key-file together with --peer-cert-file for the client certificate
Show the answer and explanation
Answer: A
Why this is correct
"Securing etcd clusters" says access to etcd is equivalent to root permission in the cluster, so ideally only the API server should have access. Under "Limiting access of etcd clusters" the page says that after configuring secure communication you restrict access to the Kubernetes API servers using TLS authentication. "When etcd is configured with --client-cert-auth along with TLS, it verifies the certificates from clients by using system CAs or the CA passed in by --trusted-ca-file flag." The example: "Specifying flags --client-cert-auth=true and --trusted-ca-file=etcd.ca will restrict the access to clients with the certificate k8sclient.cert." The API servers are then given that certificate with --etcd-certfile, --etcd-keyfile, and --etcd-cafile. The page also notes that etcd authentication is not planned for Kubernetes.
Why the other options are wrong
"--peer-key-file together with --peer-cert-file for the client certificate" … The page uses --peer-key-file and --peer-cert-file for secure peer communication between etcd members. They protect member-to-member traffic and do not decide which clients may connect.
"--etcd-certfile together with --etcd-keyfile set on the etcd server itself" … --etcd-certfile, --etcd-keyfile, and --etcd-cafile are API server flags on the page. They give the API server its client certificate for etcd, rather than telling etcd which clients to accept.
"--tls-cert-file together with --tls-private-key-file set on the etcd server" … --tls-cert-file and --tls-private-key-file are API server flags on the controlling-access page. They set the certificate and key the API server presents to its own clients, not which clients etcd accepts.
etcd side: client-cert-auth and trusted-ca-file
On etcd, --client-cert-auth=true with --trusted-ca-file limits clients to certificates from that CA. On the API server, --etcd-certfile, --etcd-keyfile, and --etcd-cafile present one.