More Info:
Do not bind the scheduler service to non-loopback insecure addresses.Risk Level
CriticalAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
On every control plane node, open the kube-scheduler static pod manifest for editing:
-
In the
spec.containers[0].command(orargs) section, locate any existing--bind-addressflag. If present and not127.0.0.1, change it to: -
If no
--bind-addressflag exists, add it under the scheduler container’s command/args list, for example: -
Save the file and exit the editor. The kube-scheduler static pod will be automatically restarted by the kubelet because
/etc/kubernetes/manifests/kube-scheduler.yamlchanged. Allow 10–20 seconds for it to restart. -
On the same control plane node, verify the running kube-scheduler process is using the correct bind address:
-
Confirm in the output that the kube-scheduler command line includes:
and that there is no conflicting
--bind-addresswith a different value. Repeat all steps on every control plane node.
Using kubectl
Using kubectl
kubectl cannot change the bind address for the kube-controller-manager or kube-scheduler because this setting is defined in the static pod manifest on each control plane node (for example,
/etc/kubernetes/manifests/kube-controller-manager.yaml or /etc/kubernetes/manifests/kube-scheduler.yaml). To remediate this finding, follow the guidance in the Manual Steps section and edit the manifest directly on every control plane node.Automation
Automation

