Skip to main content


3.2.8 Ensure that the --hostname-override argument is not set (Automated)


This rule has been changed to automated, see Automated Policies for CIS Amazon EKS 1.1.0 for details.

Profile Applicability

• Level 1


Do not override node hostnames.


Overriding hostnames could potentially break TLS setup between the kubelet and the apiserver. Additionally, with overridden hostnames, it becomes increasingly difficult to associate logs with a particular node and process them for security analytics. Hence, you should set up your kubelet nodes with resolvable FQDNs and avoid overriding the hostnames with IPs.

Also note that - from the reference link kubernetes/issues/22063 - using the --hostname-override option on a cloud-provided Kubernetes cluster may cause unexpected behaviour with node hostnames.


Some cloud providers may require this flag to ensure that hostname matches names issued by the cloud provider. In these environments, this recommendation should not apply.


Verify that the kubelet process is not running with the --hostname-override flag:

  1. Run ps -ef | grep kubelet to find the kubelet process
  2. Check the CMD string does not contain the --hostname-override flag

Note This setting is not configurable via the Kubelet config file.


If using executable arguments, edit the kubelet service file /etc/systemd/system/kubelet.service.d/10-kubelet-args.conf on each worker node and remove the below parameter at the end of the KUBELET_ARGS variable string:


Based on the node's service manager (the example below is for systemctl), restart the kubelet service and check status:

systemctl daemon-reload
systemctl restart kubelet.service
systemctl status kubelet -l