Alcide Rapid 7 Logo Alcide Rapid 7 Logo
Alcide has been acquired by Rapid7- a leading provider of security analytics and automation. Learn more

Kubernetes Threat Vectors: Part 3 – Persistence

November 12, 2020
Alon Berger
Product Marketing Manager


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.

For the full article on what’s missing in the Microsoft Azure in the Kubernetes threat matrix that was recently published on Dark Reading magazine, click here.

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.




About the author

Alon profile

Alon Berger

Product Marketing Manager

Alon Berger is a Product Marketing Manager at Alcide and an experienced Technical Engineer with a demonstrated history of working in the computer software industry. Skilled in R&D Operations management, Cyber Security, Cloud platforms, and DevSecOps methodologies. Alon served in the 8200 unit and holds a BSc in Computer Science.

Subscribe for updates, fresh insights, stories and tips

The latest posts delivered to your inbox