What Is kubelet Security? Security Definition

Imagine a large apartment building with many individual apartments (containers). Each floor has a building manager (the kubelet). This manager's job is to make sure every apartment on that floor is clean, secure, and has working utilities.

The manager also reports to the central building office (the Kubernetes control plane) about the status of each apartment. Now, what if someone breaks into the manager's office on the third floor? That intruder could turn off water to certain apartments, change the locks, or even let strangers into empty units.

That is exactly what happens when a kubelet is not secured. An attacker who gains control of a kubelet can run malicious containers, steal data from running applications, or even disable the node entirely. The kubelet has a special API (a communication channel) that the control plane uses to give it orders.

If that API is left open to the network without authentication or encryption, anyone with network access could send commands to the kubelet. Think of it like a walkie-talkie channel that every security guard in the building uses. If that channel is not encrypted, anyone with a similar radio can listen in and give fake orders.

Securing the kubelet involves three main things: first, making sure only the control plane can talk to it by using TLS certificates (like showing a special ID badge). Second, limiting what the kubelet is allowed to do on the node through authorization policies (like giving the manager a list of tasks he is permitted to do). Third, turning off or restricting the kubelet's read-write API endpoints that are not strictly needed.

In the Certified Kubernetes Security Specialist (CKS) exam, you must know how to configure these protections. This includes enabling kubelet authentication and authorization, using the NodeRestriction admission plugin, and setting up the kubelet to read from a read-only port for metrics while keeping the secure port for administrative commands. Without these steps, a compromised kubelet can be the beachhead for a full cluster takeover.

The kubelet is the primary node agent that runs on every node in a Kubernetes cluster. It registers the node with the API server, watches for Pod specs assigned to its node, and ensures the containers described in those Pod specs are running and healthy. To perform these tasks, the kubelet exposes an API on two ports: a read-only port (usually 10255) that serves non-sensitive data like metrics and health status, and a secure port (usually 10250) that requires authentication and authorization for all operations. Kubelet security focuses on hardening this API surface.

Kubelet authentication is typically handled by TLS client certificates. When the kubelet connects to the API server, it presents a certificate signed by the cluster's certificate authority (CA). Conversely, when the API server or a user (via kubectl) connects to the kubelet, the kubelet can request a client certificate. By default, the kubelet uses TLS bootstraping to automatically generate and sign certificates. However, for production security, operators often pre-provision certificates or use a dedicated CA for node certificates. The Kubernetes API server authenticates to the kubelet using the --kubelet-client-certificate and --kubelet-client-key flags.

Kubelet authorization is governed by the --authorization-mode flag. The recommended mode is Webhook, which delegates authorization decisions to the API server. When the API server receives a request, it makes a SubjectAccessReview (SAR) to determine if the requester (e.g., a user, a service account) has permission to perform the action on the kubelet's resources. Common kubelet authorization modes include AlwaysAllow (insecure, used only for testing), AlwaysDeny (too restrictive), and Webhook (the production standard). The Node authorizer and NodeRestriction admission plugin work together with the kubelet to ensure that a kubelet can only modify its own node and the Pods running on it.

Additional security measures include disabling the read-only port entirely by setting --read-only-port=0, enabling anonymous authentication (which should generally be disabled by setting --anonymous-auth=false), and configuring the kubelet to use a secure kubeconfig file with explicit credentials. The --authentication-token-webhook flag allows the kubelet to validate bearer tokens from the API server. In CKS-focused environments, you must also know how to use the --protect-kernel-defaults flag to enforce sysctl security settings, and how to configure the kubelet to use a read-only filesystem for its static pod manifests. All of these configurations are set in the kubelet configuration file (usually /var/lib/kubelet/config.yaml) or via command-line flags. Security audits and CIS benchmarks for Kubernetes specifically check that the kubelet is configured with authentication, authorization, and that the read-only port is closed.

In real IT work, especially in production Kubernetes clusters, the kubelet is one of the most exposed components. Unlike the API server which is usually behind multiple layers of authentication and network policies, the kubelet often runs on worker nodes that may be in less controlled network segments, such as public cloud subnets or edge locations. If the kubelet is compromised, an attacker can effectively take over that node. They can deploy new containers with elevated privileges, mount host paths to read sensitive files, or use the node's network to launch further attacks against internal services. For security engineers and platform teams, kubelet security is a high priority because it prevents lateral movement. If a developer's container is compromised, the attacker might try to reach the kubelet API. If the kubelet is not secured, the attacker can use the kubelet to run a privileged Pod that breaks out of container isolation, gaining root access on the host node. That one compromised node can then be used to attack other nodes or access the cluster's internal databases.

From a compliance perspective, regulations like PCI-DSS, HIPAA, and SOC 2 require that all components in a data processing environment are hardened. The kubelet is explicitly listed in the CIS Benchmark for Kubernetes, which provides dozens of checks related to its authentication, authorization, and encryption settings. A failure to secure the kubelet can lead to audit findings and, in worst cases, data breaches. For cluster administrators, daily tasks like monitoring node health, draining nodes, and upgrading kubelet versions all depend on a trust relationship between the control plane and the kubelet. If that trust is broken due to misconfiguration, routine operations fail, causing downtime.

Moreover, cloud managed services like EKS, AKS, and GKE handle some kubelet security automatically, but not all. For instance, while cloud providers enforce TLS on the kubelet port, they often leave the authorization mode as AlwaysAllow in some configurations, unless the customer configures a custom kubelet config. This means security-conscious teams must still verify and harden kubelet settings in managed clusters. In short, ignoring kubelet security is like leaving the back door of a bank vault unlocked, because the vault door (the API server) is well guarded.

Kubelet security appears in multiple question formats across the CKS exam. First, scenario-based multiple-choice questions describe a cluster that was breached, and you must identify the misconfigured kubelet setting. For example, a question might state that an attacker was able to query all Pods running on a worker node using only a network scan tool. The correct answer would point out that the kubelet was running with --read-only-port enabled, allowing unauthenticated access to Pod information. Another common scenario involves a malicious Pod that accessed the kubelet API and deployed additional containers. The question asks which configuration would have prevented this. The answer involves setting authorization-mode to Webhook and enabling NodeRestriction.

Second, troubleshooting questions present a kubelet that is failing to start or failing to register with the API server. You are given logs or configuration snippets. You must identify that the TLS certificate file path is incorrect, or that the kubelet is using an expired CA certificate. Some questions include a misconfigured kubelet config where authentication-token-webhook is set to false, causing the kubelet to reject valid API server requests. These questions test your ability to read configuration files and understand the impact of each flag.

Third, performance-based exam tasks require you to directly edit configuration files. You may be asked to SSH into a worker node, inspect the kubelet config at /var/lib/kubelet/config.yaml, and make changes. For instance, you might be told to disable anonymous authentication, turn off the read-only port, and enable the webhook authorization mode. You then need to restart the kubelet and verify that unauthenticated curl requests to the secure port are rejected. Another task may ask you to configure the kubelet to use a specific kubeconfig file with TLS client credentials.

Fourth, architecture questions may ask you to describe the flow of a kubectl exec command. You must explain that the API server authenticates the user, then forwards the request to the kubelet on the secure port, and the kubelet authorizes the request using its configured mode. Understanding this flow is essential to answer questions about why exec or logs commands fail. Finally, some questions test your knowledge of the Node authorizer and NodeRestriction plugin, asking what a kubelet is allowed to do under those restrictions. These questions often appear in a true/false or matching format within the exam's multiple-choice section.

Securing the kubelet in a real Kubernetes environment requires both configuration changes and ongoing monitoring. Start by understanding the kubelet configuration file, which by default is located at /var/lib/kubelet/config.yaml on most Linux distributions. Within that file, you set fields like authentication.anonymous.enabled to false, authentication.webhook.enabled to true, authorization.mode to Webhook, and readOnlyPort to 0. These four changes alone eliminate the most common attack vectors.

Next, you must ensure that the API server is also configured correctly. The API server's --kubelet-client-certificate and --kubelet-client-key must be set to a valid certificate pair. Without these, the API server will use a default, unauthenticated connection to the kubelet. This is a common misconfiguration in self-managed clusters. On the API server side, you must also enable the Node and NodeRestriction authorizers. If you are running a managed Kubernetes service, you may need to use a custom kubelet configuration via the cloud provider's node configuration tools. For example, in EKS, you create a custom AMI or use a node group with a custom kubelet extra args field.

What can go wrong? The most frequent issues include restarting the kubelet with invalid flags, causing the node to become NotReady, or accidentally locking yourself out. To avoid this, always make one change at a time and test. Use a test node in a non-production pool first. Also, be aware that the kubelet uses certificates that must match the node's hostname or IP. If you change the node's hostname or IP, the kubelet's TLS handshake may fail. Plan for certificate rotation as part of your routine cluster upgrades.

In practice, security professionals pair kubelet hardening with network policies that restrict pod-to-pod traffic, but the kubelet itself must be hardened regardless of network segmentation because a pod can still reach the kubelet via localhost if it runs on the same node. The kubelet should never rely solely on network controls for security. This lesson connects to the broader concept of defense in depth. Even if the API server is perfectly hardened, a single misconfigured kubelet can be the weak link that allows an attacker to pivot into the cluster. Therefore, treat kubelet security as a non-negotiable part of any Kubernetes security baseline.