Welcome to our third blog post on the Kubernetes threat vectors series.
We are covering different tactics on the Kubernetes attack matrix, published by Microsoft and originally based on the MITRE ATT&CK framework. In this blog post, we will review the third tactic – Persistence, and inspect its techniques.
What is Persistence?
After completing the first two stages of gaining access to the cluster’s resources, the third tactic consists of several methods, aimed for adversaries to maintain their foothold and existing connection in the system even after events such as restarts, changed credentials, etc.
Let’s review the different techniques:
- Backdoor container
Once the attackers gain access to the cluster, they are able to run their malicious code from an already existing container. The attackers can leverage the use of Kubernetes controllers such as DaemonSets and Deployments, thus ensuring a constant number of running containers in one or more nodes in that specific cluster. This method is very similar to the New Container technique, which we covered in the previous blog on the Execution tactic.
How to mitigate?
The best way to prevent and mitigate this technique is to make sure RBAC permissions are properly set, specifically in terms of creating Kubernetes objects like pods or other abstractions like DaemonSets, ReplicaSets, and Deployments. You should always maintain the least privilege principle in those RBAC settings, specifically for end-users and service accounts.
With Alcide, you and your organization are able to leverage the platform’s capabilities to track and monitor all RBAC settings and limitations, while detecting and alerting on any suspicious change or excessive permission for specific users and services.
- Writable hostPath mount
A hostPath volume mounts a file or a directory from the host node’s file system into your Pod, emulating network-attached storage. Kubernetes supports hostPath for development and testing on a single-node cluster. Once attackers gain permission for creating a new container, they are able to create it with a writable hostPath volume, allowing them to maintain their existing connection with the container host.
How to mitigate?
For this specific technique, Kubernetes offers its Pod Security Policy (PSP), which can be applied to whitelist, limit, or deny host mounts. Scanning these policies in runtime is crucial, and will help you build the proper configurations for such permissions.
Alcide also supports the validation of immutable root file systems, thus being able to prevent malicious overwriting.
- Kubernetes CronJob
CronJobs are useful for creating periodic and recurring tasks, like running backups for example. CronJobs can also schedule individual tasks for a specific time, such as scheduling a Job for when your cluster is likely to be idle.
How to mitigate?
Again, RBAC is your friend here. Make sure to have proper policy configurations throughout the entire CI/CD pipeline, especially around users who are authorized to create CronJobs and other Kubernetes abstractions such as DaemonSets, ReplicaSets and Deployments.
In addition to Alcide’s platform monitoring your RBAC settings, we also recently introduced a new open-source tool called rbaK. This is tool is essentially a Swiss army knife for Kubernetes RBAC controls. It significantly simplifies querying and the creation of RBAC policies, along with visualizations for RBAC relations, and a customized policies generator with simple CLI commands.
What We Think Is Missing
As we go and cover the different tactics and techniques in the Kubernetes attack matrix, we’re also providing Alcide’s take on it, and what we think Microsoft has left out, specifically within the Kubernetes domain. In one of our previous blogs – Cloud Native Security for Kubernetes In Practice, we talked about cluster operations threats and risks, and how they are usually associated with either the supply chain (CI/CD pipeline), or the Runtime environment.
With that in mind, we took the liberty to add several noteworthy security elements, that are not found in Microsoft Azure’s original matrix:
A crucial blind spot, especially for DevOps, is the unmanaged territory where adversaries can spin up containers and static pods directly on a specific node. Such a scenario is easy to overlook, as static pods are managed directly by the kubelet daemon and are not observed by the API server. Another missing aspect involves the admission controller, which when compromised, can lead to the injection of malicious sidecar containers to any desired pod.
Finally, there are the container lifecycles hooks such as PostStart and PreStop, which allow containers to be aware of events in their management lifecycle. These hooks are also exploitable, as attackers can plug in their scripts to run at predetermined times.
Stay tuned for our next chapter, where we will review the fourth tactic – Privilege Escalation.
Want to give Alcide a try? Sign up for our 14-day trial to fully experience our platform.