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 Policies 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 --hostname-override parameter from the KUBELET_ARGS variable string.

Based on the node's service manager (the example below is for systemctl), restart the kubelet service and inspect 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/