CKS · Question #6
Fix all of the following violations that were found against the ETCD:- a. Ensure that the --auto-tls argument is not set to true
This question tests your ability to harden etcd by disabling automatic TLS certificate generation, which is a CIS Kubernetes Benchmark requirement. The --auto-tls flag, when true, allows etcd to use self-signed, unverified TLS certificates that undermine transport security.
Question
Explanation
This question tests your ability to harden etcd by disabling automatic TLS certificate generation, which is a CIS Kubernetes Benchmark requirement. The --auto-tls flag, when true, allows etcd to use self-signed, unverified TLS certificates that undermine transport security.
Approach. Locate the etcd static pod manifest at /etc/kubernetes/manifests/etcd.yaml and find the --auto-tls argument under the etcd container's command section. Either remove the argument entirely or explicitly set it to --auto-tls=false. Save the file - the kubelet will automatically restart the etcd static pod. Verify the fix with: ps aux | grep etcd | grep auto-tls to confirm the flag is absent or false. The correct posture is to use explicitly provisioned, CA-signed certificates via --cert-file, --key-file, and --trusted-ca-file instead of auto-generated ones.
Concept tested. etcd TLS hardening - CIS Kubernetes Benchmark control 2.2 (etcd auto-tls). When --auto-tls=true, etcd generates self-signed certificates with no chain of trust, making peer and client connections vulnerable to man-in-the-middle attacks. Disabling it forces the use of properly issued certificates, ensuring mutual TLS authentication between etcd and the API server.
Reference. CIS Kubernetes Benchmark v1.8 - Section 2.2 'Ensure that the --auto-tls argument is not set to true'; etcd documentation: https://etcd.io/docs/latest/op-guide/security/
Topics
Community Discussion
No community discussion yet for this question.