Use the Kubelet Client to attack the Kubernet Cluster

Use the Kubelet Client to attack the Kubernet Cluster


Use the Kubelet Client to attack the Kubernet Cluster

On this weblog publish, we’re going to have a look at the Kubernetes agent, kubelet (see Determine 1), which is answerable for the creation of the containers contained in the nodes and present how it may be exploited remotely to assault the cluster. We’ll assessment totally different misconfigurations of kubelet which have been deployed with default settings as a part of a Kubernetes set up and the way these misconfigurations may finally open avenues to the Kubernetes cluster in addition to a number of efficient mitigation steps.
Highlights of this publish embrace:

  • Protecting the fundamentals of kubelet, what it’s and its main purpose
  • Why default Kubernetes set up leaves unsecured kubelet
  • Expose the complete kubelet API
  • Introduce a brand new CLI shopper for kubelet named “kubeletctl”
  • Overview an assault circulate on kubernetes by unsecured kubelet
  • Present the way to configure kubelet in a safe solution to higher stop assaults

Use the Kubelet Client to attack the Kubernet Cluster
Determine 1 – Kubernetes Structure


Kubelet is the first “node agent” that runs on every node and is used to register the nodes within the Kubernetes cluster by the API server. After a profitable registration, the first position of kubelet is to create pods and hearken to the API server for directions. The kubelet receives the directions from the API server and communicates with the container runtime (or a CRI shim for the runtime, a typical instance is Docker) over Unix sockets utilizing the gRPC, the place kubelet acts as a shopper and the CRI shim because the server (see Determine 2).

Use the Kubelet Client to attack the Kubernet Cluster
Determine 2 – Kubelet communication with Container Runtime Interface (CRI)

Whereas creating new pods, kubelet continues to watch the state of the pods and the containers inside it and stories again to the API server on a well timed foundation. This makes Kubelet a profitable goal for attackers making an attempt to compromise containers inside Kubernetes clusters. On the time of scripting this weblog we had been unable to search out any public shopper for kubelet (kubectl is barely a shopper for the Kubernetes API server however not for the kubelet API), so to raised perceive its interior workings, we created a shopper that implements its API.

You would possibly ask your self “what’s the potential of a shopper like this that requires credentials to speak with kubelet?” The reality is that in a default kubernetes set up, kubelet doesn’t require authentication and authorization.

Unauthenticated Kubelet

In a default Kubernetes set up, kubelet runs unsecured — leaving it susceptible for an assault. The explanations it’s not secured is as a result of anybody can authenticate to kubelet by default because it runs with the anonymous-auth flag set to true. Subsequently, requests to the kubelet’s API endpoints are usually not rejected and handled as nameless requests. Then the request can be licensed, as a result of by default the authorization mode (authorization-mode flag) is about to AlwaysAllow.

From this level on, we’ll look at what we will do when there may be privileged entry to kubelet. The very first thing that pops in thoughts is what API can we name and what are the undocumented calls that is likely to be of curiosity.

Undocumented Kubelet API

When kubectl is used to retrieve the standing of pods in a namespace, behind the scenes the API server collects this data from kubelet. However is there a manner for a person to speak instantly with a kubelet? Sure, there may be! Kubelet exposes an API that can be utilized instantly with out connecting to Kubernetes API server. Sadly, the Kubernetes web site offers little or no documentation in regards to the API and the remainder of the undocumented APIs could be seen within the supply code (the absence of a documented API is a sign that the API is inclined to alter). We created a full record of kubelet APIs (based mostly on Kubernetes 1.18; we’re holding the desk up to date right here). In Desk 1 you’ll be able to see a snippet of some undocumented API calls:

Kubelet API Examples to be used Description
/pods GET /pods Record the pods within the kubelet’s employee
/run POST /run///
POST /run////
Run command in a container
/exec GET  /exec///?command=
POST /exec///?command=
GET  /exec////?command=
POST /exec////?command=
Run command utilizing a stream in a container
/configz GET /configz Kubelet’s configuration file settingst
/debug GET /debug/flags/v
PUT /debug/flags/v (physique: )
GET /debug/pprof/
Debug data

Desk 1 – Kubelet API desk

To speak with the kubelet API utilizing a few of the above APIs, we will use curl:

curl -k -X https://:10250//

Among the API instructions are extra advanced to make use of with curl, subsequently we created a shopper to simplify the method.

Introducing kubeletctl

We created a brand new open supply instrument named “kubeletctl” that implements all of the kubelet’s API. It was constructed with the intention to make it easier to run instructions than utilizing curl, and to permit extra superior requests, which we’ll cowl later. It’s accessible on GitHub at this hyperlink:

Discovery: All of it Begins with Port 10250/TCP

Kubelet exposes its API over the default port 10250/TCP and this is among the issues that we’ll verify when attacking Kubernetes cluster. A privileged entry to kubelelt’s port, whether or not because of no authentication or because of possessing the required permissions, will enable us to record the pods, entry them, and possibly even breakout to the host (if one of many containers is privileged).

To seek for nodes with opened kubelet’s port we will use kubeletctl scan command on a particular subnet as seems in Determine 3:

Use the Kubelet Client to attack the Kubernet Cluster
Determine 3 – Scanning for open kubelet ports with kubeletctl

Reconnaissance: Record Pods on the Employee

After figuring out an accessible kubelet API, we’ll wish to verify what data we will extract. The commonest and vital piece of data is the /pods endpoint which is able to get us the record of pods:

Use the Kubelet Client to attack the Kubernet Cluster
Determine 4 – Kubelet pods from kubeletctl

Distant Code Execution in Containers

As soon as we have now the small print about our pods and containers, we will run instructions inside them. Kubelet has Three API requires executing instructions inside a container:

  1. /run → Run command contained in the container
  2. /exec → Run command contained in the container utilizing a stream
  3. /cri → Run command contained in the container after a stream was opened by /exec

Utilizing the /run endpoint with curl is straightforward:

curl -ks -X POST https://:10250/run/// -d “cmd=ls /””

However utilizing /exec endpoint with curl is extra advanced as a result of it requires an preliminary POST request and a follow-up GET with SPDY succesful shopper (or websocket shopper which can also be supported).

In older variations of Kubernetes (v1.9 for instance) you may use this request:

curl -k -H “Connection: Improve”
-H “Improve: SPDY/3.1”
-H “X-Stream-Protocol-Model:”
-H “X-Stream-Protocol-Model:”
-X POST “https://:10250/exec///?command=ls&command=/&enter=1&output=1&tty=1”

It will then open a stream and response with 302 requests which is able to seem like this:


You’ll need to make use of different instruments like wscat to attach the stream and use /cri/exec/?cmd= to execute the command. In more moderen Kubernetes variations, we is not going to get the cri worth anymore as a result of it doesn’t ship 302 request.

With kubeletctl you need to use /run or /exec with out the complexity of dealing with streams and to make it even simpler, we added a scan that checks every container, individually, to see if working a command inside it’s attainable:

Use the Kubelet Client to attack the Kubernet Cluster
Determine 5 – Kubelet pods and containers susceptible to distant code execution

Then select the one you wish to execute a command inside it:

Use the Kubelet Client to attack the Kubernet Cluster
Determine 6 – Working command with /exec command

Onelinear Assault

kubelectl is just not solely a shopper that implements the kubelet’s API, nevertheless it additionally has extra superior capabilities. It may run a command on all of the pods contained in the nodes with out specifying every pod and container individually:

Use the Kubelet Client to attack the Kubernet Cluster
Determine 7 – Working one command on all current containers by kubeletctl

Utilizing this characteristic, it’s attainable to extract data from a number of containers with one command. However one of the crucial frequent issues that attackers in Kubernetes environments will do is to seek for tokens, so there’s a particular command to view the tokens from all of the containers:

Use the Kubelet Client to attack the Kubernet Cluster
Determine 8 – Kubeleltctl collects the tokens from all current containers

With these talents, we will acquire data from a number of containers quick and avoid wasting precious time.

For extra details about the totally different instructions or the utilization of the instrument, you’ll be able to at all times go to the README web page on GitHub or simply use -h or –assist switches when working the instrument and you will notice the outline of every command and the way to use it.


A easy solution to mitigate the assaults we lined within the earlier sections is to make use of well-known deployment instruments and managed Kubernetes providers like AWS EKS, Azure AKS AKS, kubeadm, and so forth. These deployments are constructed with a protection in depth structure, therefore “covering-up” for these unsecured settings.

If this isn’t the case and you might be utilizing the Kubernetes default set up or in case you simply wish to confirm that kubelet settings in your nodes are secured, there are two vital issues you are able to do to forestall the assaults we highlighted in earlier sections:

  1. Authentication: Disable nameless requests to the Kubelet server
  2. Authorization: Don’t enable all requests and allow specific authorization

The above configurations could be applied by modifying the kubelet’s settings. These settings could be configured in one in every of two methods:

  1. Utilizing arguments when working the kubelet executable
  2. Utilizing arguments taken from the kubelet configuration file

If each are specified, the executable argument takes priority.

1. Utilizing kubelet’s executable arguments

kubelet settings could be set by executable arguments, on this case we will edit the kubelet service file /and so forth/systemd/system/kubelet.service.d/10-kubeadm.conf (could be discovered by working service kubelet standing | grep Drop-In) on every employee node and set the under parameters:

1. Set KUBELET_SYSTEM_PODS_ARGS variable to:


2. Set KUBELET_AUTHZ_ARGS variable to:


After these adjustments, you have to to restart the kubelet service based mostly in your working system. For instance in Ubuntu:

systemctl daemon-reload
systemctl restart kubelet.service

2. Utilizing kubelet’s configuration file

To seek out the kubelet’s configuration file, run ps -ef | grep kubelet | grep config or service kubelet standing | grep config and seek for –config. This file may very well be in JSON or YAML format relying in your distribution.

Edit the kubelet’s config file /var/lib/kubelet/config.yaml (default location) with the next adjustments:

1. Set authentication: nameless: enabled to false
2. Set authorization: mode to Webhook

Right here is an instance of the way it ought to take care of the adjustments:

enabled: false -> ensure that it’s set to false

# mode: AlwaysAllow -> ensure that this line is just not exist
mode: Webhook -> set to Webhook

However I nonetheless want entry to some Kubelet endpoints!

Within the occasion you continue to must entry to Kubelet’s endpoints, you’ll be able to create a task with the foundations you want. In Kubernetes documentation, you’ll be able to view all kubelet API sources and sub-resources:

Use the Kubelet Client to attack the Kubernet Cluster
Determine 9 – Kubelet API sources and sub-resouces

In reviewing Determine Eight above, it’s attainable to set particular permissions for kubelet. For instance, granting learn entry solely to the metrics endpoint:

sort: ClusterRole
title: metrics-clusterrole
namespace: default
– apiGroups: [“”]
– nodes/metrics
– get
– record

x509 Authentication

Assign this position to a person within the cluster, a one with certificate-based authentication X509 to authenticate with kuebelt however it’s going to work provided that the next flags are set:

  1. The kubelet had been began with –client-ca-file flag or its configuration file (ex. /var/lib/kubelet/config.yaml) had authentication: x509: clientCAFile: < ca.crt_path>
  2. The kubernetes API server had been began with –kubelet-client-certificate and –kubelet-client-key (ex. verify the API server YAML cat /and so forth/kubernetes/manifests/kube-apiserver.yaml | grep kubelet-client)

Which means that solely customers with certificates signed with the certificates authority file (ca.crt) will be capable of authenticate to kubelet.

Service Account Token Authentication

For cloud-managed clusters (e.g. EKS – Elastic Kubernetes Service, AKS – Azure Kubernetes Service, and so forth.) it will likely be tougher as a result of grasp node not being accessible to the person and subsequently additionally the ca.crt file. On this case, a service account token can be utilized with the /proxy endpoint of /nodes like that:

curl -k –header “Authorization: Bearer ” https://:6443/api/v1/nodes//proxy/configz

It’s going to return the identical data as was utilized in kubelet however require secured authentication.


Kubelet has a cardinal position in Kubernetes – it’s the agent that creates the containers and it has full management over any pod working within the node. Subsequently, attackers will set it as one in every of their targets and can scan for clusters with opened entry to kubelet. An entry to kubelet permits attackers to collect details about the cluster, entry to purposes contained in the containers, and carry out lateral motion which may finally result in full compromise of the cluster.

Kubeletctl generally is a good possibility to speak with kubelet, particularly for builders who must run some API towards the kubelet, blue groups who wish to verify if they’ve susceptible kubelet within the cluster or for pink groups who need automate a few of its APIs to run on all of the pods.

Though many of the frequent distributions safe kubelet, IT/DevOps groups ought to ensure that their kubelet configuration is just not default and do the mandatory adjustments to make it secured.


Latest Articles By Writer

*** This can be a Safety Bloggers Community syndicated weblog from CyberArk authored by Eviatar Gerzi. Learn the unique publish at:

kubernetes python client examples,kubernetes architecture,kubectl cluster-info,kubernetes api,kubernetes java client examples,kubernetes rest api example,kubectl connect to cluster,kubernetes api server port 6443