Skip to main content

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

Critical

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. On every etcd (control plane) node, back up the current manifest and open it for editing:
  2. In the spec.containers[0].command (or args) section for the etcd container, ensure the --client-cert-auth flag is present and set to true. For example, add or modify this line:
    Make sure there is no other --client-cert-auth flag with a different value in the list.
  3. Save the file and exit the editor. The kubelet will automatically detect the change to /etc/kubernetes/manifests/etcd.yaml and restart the etcd static pod. This will temporarily restart the etcd process on that control plane node.
  4. Wait for the etcd pod to be recreated and become Running on that node:
    Confirm the etcd pod for this node is in Running status.
  5. Verify on that node that etcd is now running with --client-cert-auth=true:
    Confirm the etcd process arguments include --client-cert-auth=true and do not include --client-cert-auth=false.
  6. Repeat steps 1–5 on every etcd (control plane) node in the cluster.
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.