For AI agents: A markdown version of this page is available at https://docs.datadoghq.com/security/default_rules/def-000-c8j.md. A documentation index is available at /llms.txt.

An EKS's Kubelet should use TLS authentication

An EKS’s Kubelet should use TLS authentication

Description

This rule maps to CIS Amazon EKS Benchmark 3.2.3 and requires that the Kubelet on each EKS worker node authenticates API clients using X.509 client certificates (TLS authentication).

By default a Kubelet that is not given a client CA bundle will treat requests that do not present a valid client certificate as anonymous. Combined with permissive authorization this allows unauthenticated access to the Kubelet API, which exposes pod logs, exec, and other sensitive operations. Configuring a client CA file forces the Kubelet to validate the certificate presented by each connecting client, ensuring that only trusted, authenticated callers can talk to the Kubelet API.

Audit

A worker node is considered compliant when its Kubelet declares a client CA bundle through one of the following:

  • The authentication.x509.clientCAFile setting in the Kubelet configuration file (components.kubelet.config.content.authentication.x509.clientCAFile).
  • The legacy --client-ca-file command-line argument (components.kubelet.client-ca-file).

If neither is present the node fails the check. When the node has no components/kubelet data available the result is skip because the configuration cannot be evaluated.

Remediation

Provision a trusted client CA bundle on each worker node and set authentication.x509.clientCAFile in the Kubelet configuration file (or pass --client-ca-file), then restart the Kubelet so it validates client certificates. See the Kubelet authentication and authorization documentation for details.

References