Skip to main content

More Info:

Do not bind the scheduler service to non-loopback insecure addresses.

Risk Level

Critical

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. On every control plane node, open the kube-scheduler static pod manifest for editing:
  2. In the spec.containers[0].command (or args) section, locate any existing --bind-address flag. If present and not 127.0.0.1, change it to:
  3. If no --bind-address flag exists, add it under the scheduler container’s command/args list, for example:
  4. 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.yaml changed. Allow 10–20 seconds for it to restart.
  5. On the same control plane node, verify the running kube-scheduler process is using the correct bind address:
  6. Confirm in the output that the kube-scheduler command line includes:
    and that there is no conflicting --bind-address with a different value. Repeat all steps on every control plane node.
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.

Additional Reading: