hardMultiple ChoiceObjective-mapped
CKS Practice Question: A security engineer for a financial services…
You are a security engineer for a financial services company running a Kubernetes cluster on-premises. The cluster uses kubeadm for bootstrapping and Calico for network policy. Recently, a compliance audit revealed that all nodes in the cluster have the kubelet port 10250 open to the public network, allowing unauthenticated access to the kubelet API. This poses a severe security risk. The cluster has 10 worker nodes and 3 control plane nodes. You need to remediate this without disrupting running workloads. The nodes are behind a corporate firewall, but the internal network is considered untrusted. You have access to the node's iptables and can modify configuration files. Which course of action best secures the kubelet port while maintaining cluster functionality?
⚠ Common exam trap
Test-takers frequently confuse Kubernetes network policies (like Calico) with host-level firewall rules, assuming they can block node ports, when in fact network policies only apply to pod-to-pod traffic and cannot control access to the kubelet's host network interface.
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
✓
Use iptables on each node to allow incoming connections to port 10250 only from the cluster's CIDR (e.g., 10.0.0.0/8).
Using iptables to restrict access to port 10250 to only the cluster's internal CIDR (e.g., 10.0.0.0/8) directly addresses the audit finding by blocking unauthenticated public access while allowing necessary kubelet API communication from within the cluster. This approach does not disrupt running workloads, as it only modifies firewall rules without restarting kubelet or changing its configuration. It leverages the existing network infrastructure (iptables) and is consistent with the principle of least privilege for an untrusted internal network.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Use iptables on each node to allow incoming connections to port 10250 only from the cluster's CIDR (e.g., 10.0.0.0/8).
Why this is correct
The kubelet serves its API on port 10250 bound to all node interfaces, and the Kubernetes control plane accesses it for operations like exec, logs, and metrics. An iptables rule filtering by cluster CIDR at each node is an effective host-level network boundary control: it lets matching traffic from the API server and other nodes reach the kubelet while preventing arbitrary external hosts from even connecting to this sensitive endpoint. For robustness, you would combine this with kubelet authentication and authorization, but the firewall rule is what actually blocks network exposure to the outside.
- ✗
Configure a Calico GlobalNetworkPolicy to block inbound traffic to port 10250 on all nodes.
Why it's wrong here
Calico GlobalNetworkPolicy targets workload endpoints—pods and, when explicitly configured, host endpoints—through the Kubernetes resource model. However, by default a GlobalNetworkPolicy has no effect on a host process such as kubelet, whose socket is in the default network namespace and is not represented as a workload endpoint. Since the kubelet listener on port 10250 is a host port, you must either configure Calico HostEndpoint objects with selector rules or use node-level iptables/nftables; simply declaring a GlobalNetworkPolicy that blocks 10250 will not touch that traffic.
- ✗
Change the kubelet port to a non-standard port (e.g., 10260) and update all kubelet configurations.
Why it's wrong here
Moving the kubelet to a non-standard port like 10260 is a classic security-through-obscurity measure: it does not reduce an attacker’s ability to scan or connect to the service; it merely shifts the port number. It also incurs significant operational overhead because the API server must be told the new port (via the kubelet’s address and port in the node object), and every kubelet restart or config change must be coordinated. The underlying security issue—unauthenticated or unauthorized access to the kubelet—remains exactly as serious, so this option is not an appropriate hardening control.
- ✗
Set the --anonymous-auth flag to false on each kubelet and restart them one by one.
Why it's wrong here
Setting --anonymous-auth=false disables the kubelet’s anonymous authentication, which is a useful security setting, but it is not a substitute for network filtering. The kubelet port remains open on the host network and is still reachable by any system that can route to it; an attacker who has compromised another node or can impersonate a valid client can then present credentials or extract node credentials to make authenticated requests. Because this control is application-level and not network-level, it fails to block the attack scenario of external or lateral network access to port 10250.
Visual reference
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 114-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.