More Info:
The —client-cert-auth argument must be set to true so etcd requires valid client certificates for all client connections. If disabled, any client that can reach etcd can read or modify all cluster state and secrets.Risk Level
CriticalAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
On every etcd (control plane) node, back up the current manifest and open it for editing:
-
In the
spec.containers[0].command(orargs) section for theetcdcontainer, ensure the--client-cert-authflag is present and set to true. For example, add or modify this line:Make sure there is no other--client-cert-authflag with a different value in the list. -
Save the file and exit the editor. The kubelet will automatically detect the change to
/etc/kubernetes/manifests/etcd.yamland restart the etcd static pod. This will temporarily restart the etcd process on that control plane node. -
Wait for the etcd pod to be recreated and become Running on that node:
Confirm the etcd pod for this node is in
Runningstatus. -
Verify on that node that etcd is now running with
--client-cert-auth=true:Confirm the etcd process arguments include--client-cert-auth=trueand do not include--client-cert-auth=false. - Repeat steps 1–5 on every etcd (control plane) node in the cluster.
Using kubectl
Using kubectl
kubectl cannot modify the etcd static pod manifest or its process flags, so this finding cannot be fixed via the Kubernetes API. To remediate, you must edit
/etc/kubernetes/manifests/etcd.yaml directly on every etcd (control plane) node as described in the Manual Steps section.Automation
Automation

