Skip to main content

More Info:

etcd should be configured to make use of TLS encryption for client connections.

Risk Level

Medium

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. On every control plane node, identify the API server manifest and existing etcd TLS files:
If your etcd client cert/key live elsewhere, adjust the paths in the next step accordingly.
  1. On every control plane node, back up the API server manifest before editing:
  1. On every control plane node, edit /etc/kubernetes/manifests/kube-apiserver.yaml to add or correct the --etcd-certfile and --etcd-keyfile arguments under the kube-apiserver container’s command list. For example (snippet only, keep existing args):
Adjust the certificate/key paths in the command if your etcd client certificate/key are different. Saving this file will cause the kubelet to restart the kube-apiserver static pod on that node.
  1. On every control plane node, ensure the specified cert and key are readable by the kube-apiserver process (typically user root inside the pod):
  1. Wait for the kube-apiserver pod to be recreated, then verify it is running (from any machine with kubectl access):
Ensure all kube-apiserver pods are in Running status.
  1. On every control plane node, verify the kube-apiserver process now includes the --etcd-certfile and --etcd-keyfile flags with the correct paths:
Confirm that the output shows --etcd-certfile= and --etcd-keyfile= pointing to your intended certificate and key files.
kubectl cannot modify the kube-apiserver static pod manifest or its process flags, so it cannot be used to set --etcd-certfile and --etcd-keyfile. This must be fixed directly on every control plane node by editing /etc/kubernetes/manifests/kube-apiserver.yaml; see the Manual Steps section for the required host-level changes.

Additional Reading: