CyberArk, a provider of access management tools, today issued an advisory describing multiple potential misconfigurations of kubelet, the agent software that registers a Kubernetes node with an application programming interface (API) server, that could lead to a cybersecurity breach.
As the agent software that creates the containers, kubelet has full control over any pod running in a Kubernetes node. In a default Kubernetes installation, kubelet runs unsecured because all requests are treated as anonymous, which means none of those requests are rejected. It also exposes an API that can be invoked directly without connecting to the Kubernetes API server. Kubelet exposes its API over port 10250/TCP by default.
Access to kubelet allows attackers to gather information about the cluster, access to applications inside the containers and laterally move about the cluster until it is completely compromised. Armed with that information, attackers can collect a list of pods in the cluster and run commands inside them.
To demonstrate how to compromise kubelet, CyberArk created a client to make anonymous requests using a new open source tool named “kubeletctl” that implements all the kubelet APIs. The tool, which CyberArk is making available to enable cybersecurity teams to test nodes, makes it possible to scan for all open kubelet ports.
Alternatively, developers can employ kubeletctl to communicate directly with the kubelet API if they so desire. The kubeletctl tool makes it possible to run a command on all the pods inside the nodes without having to specify each pod and container individually. There’s even a search function through which all the tokens on the pod can be discovered.
Nir Chako, security team research leader at CyberArk, says the two most critical actions IT teams need to take to mitigate this potential attack vector is to not allow all requests and disable any anonymous ones.
Given the level of control kubelet has over pods, Chako says it’s a certainty cyberattackers will scan for clusters with opened access to kubelet. At a time when developers are increasingly deploying Kubernetes clusters, it’s likely there are one or more Kubernetes clusters deployed using default settings, especially in application development environments. Developers have a tendency to make assumptions about the default security of IT platforms, which can prove fatal.
It’s not clear to what degree instances of kubelet have been compromised. However, there have been reports of Kubernetes clusters being compromised via attacks launched against kubelet. IT teams will need to ensure that any set of DevSecOps processes that are eventually adopted includes policies and procedures for securing Kubernetes infrastructure.
Hopefully, the number of instances in which kubelet is compromised is low. However, given the level of cyber espionage expertise that many nation-states now have, it should be assumed that there is a whole cadre of hackers out there who already know how to scan for open kubelet ports.