Tools Resources

10 ways to Escalate Privileges in Kubernetes

Or Azarzar

Tuesday, Jul 27th, 2021

There are so many benefits to a Kubernetes environment, which explains why usage has jumped to 83% in production, up from 78% last year. All in all, container usage has risen 300% in the past 5 years! Whether you’re using Kubernetes for its dynamic scaling, it’s rollback and self-healing capabilities, or its native load balancing – Kubernetes has changed the game for cloud-native organizations.

However, there’s no denying that handling these kinds of cloud security controls can be complex. Securely setting up cluster roles for RBAC is no easy task, and as there is no real separation between the control plane and the data plane on K8 – this needs a different approach. Our general recommendation is to use Kubernetes, but to be aware of the security pitfalls that are inherent within its design, which are mostly as a result of its maturity as a product.

To help users gain awareness, we’ve created a list of one of the biggest risks in a Kubernetes environment - privilege escalation. The principle of least privilege dictates that users should only have as much access as they need, and no further. This limits risk in a complex and dynamic on-premises environment. Without the principle of least privilege on-premises, when attackers gain a foothold, they can use privilege escalation to gain an increasing amount of access, finding their way to digital crown jewels or sensitive data. However, on the cloud, relying on the principle of least privilege is less helpful, as attackers regularly only need one or two permissions in order to gain full access. As a result, you need to shore up Kubernetes and cloud security gaps with a much tighter focus.

To help gain more visibility into this challenge, we’ve gathered the top 10 privilege escalation attack scenarios on Kubernetes and how these can be achieved.

1. List all secrets, then steal the admin secret

Listing all secrets in Kubernetes allows you to get any service account token in the cluster, including access to the system components that have the highest privileges in the cluster.

Attack Scenario: The attacker has a token for, or has obtained access to a pod. This pod has a service account that has a cluster role binding to a ‘list all secrets’ cluster role. When listing all secrets stored in the cluster, one of them will be an administrative token allowing the attacker to gain the highest possible privileges in the cluster.

2. Get secrets as a role in kube-system namespace

Listing all secrets in the kube-system namespace allows you to get any service account token in that namespace. Most of them are system components that have the highest privileges in the cluster.

Attack Scenario: The attacker has a token or access to a pod running in the kube-system namespace. This pod has a role binding to a ‘get secrets’ role. When getting all secrets stored in the kube-system namespace, the attacker can leverage an administrative token, gaining the highest privileges in the cluster.

3. Pods/exec cluster role to steal mounted secret in admin pod

Collecting the default mounted token on a pod where one of the pods has a service account with administrative access.

Attack Scenario: The attacker has a token or access to a pod with a service account that has a cluster role binding to a ‘create pods/exec cluster’ role. When executing a cat command on any pod, that allows him to print any mounted token on any pod. One of these will be an administrative token, which means once again the attacker has been able to gain the highest privileges in the cluster.

4. Impersonate to group

Kubernetes has default groups that have high permissions. In this situation, impersonating a privileged group will allow for obtaining higher privileges in the cluster, for example system masters.

Attack Scenario: The attacker has a token or access to a pod with a service account that has a cluster role binding to a ‘impersonate group’ cluster role. When impersonating to the system-masters group, or any other admin group, the attacker gains administrative access in the cluster.

5. Create role binding to a cluster-role

In this example, privileges are escalated by creating a role binding to the cluster-admin cluster role.

Attack Scenario: The attacker has a token, or access to a pod with a service account that has a cluster role binding to ‘create a new binding’ to a cluster role. When creating a new binding to the cluster-admin cluster role, the attacker thereby gains administrative access to the cluster.

6. Create pod with mount to admin secret

Creating a new pod in the same namespace as an administrative pod gives the attacker an opportunity to mount the admin secret to our pod.

Attack Scenario: The attacker has a token or access to a pod with a service account that has a permission to create a pod in the kube-system namespace. The attacker can create the pod with a volume mount to a system pod that contains an administrative token, and therefore which allows the attacker to gain the highest possible privileges in the cluster.

7. Privileged container running on the same node with admin pod

Here, the admin pod secret is stolen by accessing its file system from the host while running as privileged on the same node.

Attack Scenario: The attacker has access to a privileged container running on the same node with a pod that is using an administrative or shadow admin service account with the token mounted. The attacker can access the other pod’s mounted secret via the underlying host as a privileged pod.

8. Container with full hostPath mount, running on same node with admin pod

This is achieved by stealing the admin pod secret by accessing its filesystem from the host path mount on the same node.

Attack Scenario: The attacker has access to a container with hostPath mount to the entire filesystem of the underlying host. They also have access to a pod that is using an administrative or shadow admin service account with the token mounted. The attacker can thereby access the other pod’s mounted secret via the underlying host via the hostPath mount.

9. Container with SYS_ADMIN capability running on same node as admin pod

By accessing its file system from the host, while running with SYS_ADMIN capabilities on the same node, the admin pod’s secret can be stolen.

Attack Scenario: In this event, the attacker has access to a container with SYS_ADMIN capability enabled. It is running on the same node with a pod that is using an administrative or shadow admin service account with the token mounted. The attacker can access the other pod’s mounted secret via the underlying host as a SYS_ADMIN pod.

10. Exploitable Control Plane Component

Exploiting the Kubernetes api server or kubelet to gain access to unauthorized resources, such as the admin secrets.

Attack Scenario: The attacker can exploit a control plane component such as the kubelet or api server. The exploitation leads to easy access to an administrative token, allowing the attacker to gain full access in the cluster.

Set-up and Monitor Your Kubernetes Environment to Avoid Risk

At panoptica, we have real-world experience as white-hat attackers, which led to us creating the tools and technology to find, prioritize and fix actual vulnerabilities in customer’s cloud and Kubernetes infrastructure. Check our list of open source Kubernetes security tools for more advice and support.

From implementing complex rules to manage traffic, to changing dangerous defaults and shoring up authorization controls - watch our Kubernetes security best practices webishop to learn more.

Get Started

Solutions

Tools

Resources