alcide

Alcide Blog

Cloud-native Security Provider

Kubernetes Threat Vectors: Part 4 - Privilege Escalation

Dec 3, 2020 9:30:31 AM / by Alon Berger

 

Welcome to our fourth 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 Privilege Escalation tactic, and cover its techniques.

 

What is Privilege Escalation?

The privilege escalation tactic consists of techniques that are used by attackers to get higher privileges in the environment than those they currently have. In containerized environments, this can include getting access to the node from a container, gaining higher privileges in the cluster, and even getting access to the cloud resources.

Let’s review the different techniques:

  • Privileged container

    Without proper security measures and defenses, adversaries are most likely to escalate privileges by spinning a new container, while having the full-blown capabilities of the host machine. This means that the attacker can perform various actions from within the new container and retrieve cloud resource data.

    How to mitigate?

    There are a couple of must-have security practices when trying to prevent any possibility of privileged containers. First and foremost, role-based access control (RBAC) privileges should be restricted. By making sure that the Kubernetes’ network policies are properly configured, admins can control and monitor network access to the relevant privileged containers, thus allowing or denying the creation of new pods or deployments.

    Protecting the Kubernetes workloads in runtime is essential, and with Alcide’s kArt solution, it is possible to examine those workloads’ conformance while automatically detecting anomalous behavior. kArt highlights unexpected usage patterns and unusual data transfers by gathering information about network usage and trends over time. kArt’s embedded policies also help with proactively identifying externally-facing resources and assigning relevant firewall policies to promote segregated communications.

 

kArt’s Application view on Alcide’s platform

 

  • Cluster-admin binding

    This technique basically describes how attackers would gain relevant permissions for creating bindings and cluster-bindings, enabling them to create a binding to the cluster-admin ClusterRole or to other high privileges roles.

    How to mitigate

    Again, the main focus here is RBAC configurations. Permissions should be strictly limited to administrators and cluster-admin roles, stripping down unnecessary privileges for any user, group or service account.

    As part of Alcide’s platform capabilities, the kAdvisor, a multi-cluster vulnerability scanner, helps to scan and monitor RBAC settings and misconfigurations while integrating into the deployment phase of the CI/CD pipeline.

 

  • hostPath mount

    Very similar to the “Writable hostPath Mount” technique associated with the Persistence tactic, hostPath mount can be used by attackers to get access to the underlying host and thus break from the container to the host.

    How to mitigate?

    The best way to tackle attackers using this technique is to use Pod Security Policies (PSP), applying strict and specific limitations on file paths that can be mounted.
    With the help of an admission controller, operation teams are also able to define and customize the API resource configurations that can be admitted to a cluster. In other words, the admission controller helps with enforcing relevant security policies, including the likes of host mounts limitations.

    Alcide’s platform and its capabilities include the support of admission control, that is often referred to as the “gatekeeper”. It is often used for validating and/or mutating requested configurations, based on predefined and customized rules and policies. Leveraging the admission controller's benefits enables constant monitoring on the Kubernetes deployments, and helps in finding deviations from desired baseline.

 

  • Access cloud resources

    When managing and deploying Kubernetes clusters in the cloud, there is the risk of attackers leveraging their access to containers and getting access to other cloud resources outside the cluster. Cloud providers often use a service principal credential in each node, mostly needed for cluster operation. Attackers who get access to this service principal file (by hostPath mount, for example) can use its credentials to access or modify the cloud resources.

    How to mitigate?

    Mitigating this in Kubernetes’ territory, an organization should apply the same precautions as with previous techniques, mainly focusing on applying Pod Security Policies (PSPs) in order to limit the file paths that can be mounted using a host mount, or deny it completely. Leveraging the admission controller’s capabilities is also recommended here, as it enables better control in preventing compromised containers being deployed into clusters in production.

    Another area to keep in mind is the cloud provider’s platform and resources.
    The managed services these providers offer should include tools that help manage cloud metadata and detect compromised pods.

    In terms of image scanning, Alcide’s platform is capable of running automatic scans in runtime, with the unique ability to scan for security issues in container images and translate them to valuable insights in the Kubernetes context.

 

What We Think Is Missing

As we go and cover the different tactics and techniques in the Kubernetes attack matrix, we’re also providing our 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 were not found in Microsoft Azure’s original matrix:

 

 

 

 

One major gap that could be associated with the Privilege Escalation tactic can be highlighted by several recent CVEs like CVE-2020-8559, emphasising the fact that privileges can be escalated from a node to the entire cluster, or from the cluster to the hosting cloud environment.

Furthermore, admission controllers and Kubernetes operators can also be compromised and should be definitely taken under consideration when implementing security guardrails.

Read the full article on Dark Reading magazine - Microsoft's Kubernetes Threat Matrix: Here's What's Missing.

Stay tuned for our next chapter, where we will review the fifth tactic - Defense evasion.

 

Want to give Alcide a try? Sign up for our 14-day trial to fully experience our platform.

 

 

Subscribe to Email Updates