CKS Cluster Hardening Practice Question
You are hardening a kubeadm-managed cluster running Kubernetes v1.28. The kubelet's read-only port (10255) is still listening on every node, exposing pod and node metadata without authentication. You must disable it across the cluster. Which action is correct?
⚠ Common exam trap
The trap here is assuming pod-level network controls or apiserver flags can suppress a node-level kubelet listener that is bound in the host network namespace.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Edit each node's kubelet configuration to set readOnlyPort: 0, then restart the kubelet service.
The unauthenticated kubelet read-only port is controlled solely by the readOnlyPort setting inside the kubelet's configuration. Setting it to 0 disables the listener, eliminating anonymous metadata disclosure. NetworkPolicies, apiserver flags, and credential rotation act on different layers and cannot close a listener bound in the node's host network namespace. The fix must be applied per node and followed by a kubelet restart.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add a NetworkPolicy to the kube-system namespace that denies ingress to TCP port 10255 on all pods.
Why it's wrong here
NetworkPolicy applies to pod network traffic selected by pod labels, not to host-network listeners like the kubelet. The kubelet binds on the node's network namespace, so a NetworkPolicy targeting pods in kube-system will never match traffic destined to the node IP on 10255. The port would remain reachable from any host that can route to the node.
- ✓
Edit each node's kubelet configuration to set readOnlyPort: 0, then restart the kubelet service.
Why this is correct
Setting readOnlyPort: 0 in the KubeletConfiguration disables the unauthenticated read-only endpoint entirely. Because the port is deprecated and unauthenticated, it leaks pod specs, node metrics, and mounted volume details to anyone who can reach TCP 10255. Applying the change in the kubelet config file and restarting kubelet on every node removes that exposure without affecting the authenticated API on 10250.
- ✗
Change the kube-apiserver --kubelet-preferred-address-types flag to InternalIP so the read-only port is bypassed.
Why it's wrong here
That flag only influences which node address apiserver uses when proxying logs, exec, and metrics to kubelet. It does not open or close the kubelet's own listeners, so the unauthenticated read-only port continues accepting connections. The exposure comes from kubelet configuration, not from how apiserver reaches kubelet.
- ✗
Rotate the kubelet client certificate and enable NodeRestriction so the read-only port requires authentication.
Why it's wrong here
NodeRestriction is an admission plugin that limits what a kubelet's credentials can modify through the API server; it has no effect on the kubelet's local HTTP listeners. Rotating client certificates strengthens kubelet-to-apiserver authentication but does nothing to secure port 10255, which by design serves unauthenticated data. The listener must be disabled in kubelet configuration.
Go deeper
Related to this question
About these practice questions
One of 845 original CKS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.