Skip to main content

More Info:

Do not override node hostnames.

Risk Level

High

Address

Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CIS EKS
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Manual Steps

  1. On every worker node, check how kubelet is started and whether --hostname-override is present:
    Note whether kubelet is started via systemd and if --hostname-override appears in the command.
  2. On every worker node, open the kubelet systemd drop-in file for editing:
  3. In that file, locate any line that includes --hostname-override (commonly within a variable like KUBELET_SYSTEM_PODS_ARGS=) and remove only the --hostname-override=... portion, leaving the rest of the arguments unchanged. Save and exit.
  4. Still on the same worker node, reload systemd and restart kubelet so the change takes effect:
  5. If /var/lib/kubelet/config.yaml contains a hostnameOverride field, remove it as well to avoid configuration drift:
    Delete the hostnameOverride: ... line, save, and restart kubelet again:
  6. Verify on each worker node that kubelet is running without --hostname-override:
kubectl cannot modify kubelet process flags or host-level configuration files such as /etc/systemd/system/kubelet.service.d/10-kubeadm.conf or /var/lib/kubelet/config.yaml. To remediate this finding, make the changes directly on every worker node’s filesystem and systemd configuration as described in the Manual Steps section.

Additional Reading: