Skip to main content

lacework-global-327

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

note

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

Profile Applicability​

• Level 1

Description​

Do not override node hostnames.

Rationale​

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.

Impact​

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.

Audit​

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.

Remediation​

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:

--hostname-override

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

References​

https://kubernetes.io/docs/admin/kubelet/
https://github.com/kubernetes/kubernetes/issues/22063
https://kubernetes.io/docs/tasks/administer-cluster/reconfigure-kubelet/