Protecting Kubernetes Against MITRE ATT&CK: Privilege Escalation

Part four of our nine-part blog series on the various Kubernetes threat vectors and tactics covers Privilege Escalation, which encompasses techniques that enable an attacker to gain additional privileges that can be used to take more actions within the cluster and/or grant access to a wider scope of resources. These techniques include accessing or running a privileged container, taking advantage of roles with broad administrative privileges, and gaining access to cloud resources.

• Part one - Initial Access
• Part two - Execution
• Part three - Persistence
• Part five - Defense Evasion
• Part six - Credential Access
• Part seven - Discovery
• Part eight - Lateral Movement
• Part nine - Impact

Some ways that StackRox provides protections against these privilege escalation techniques are: enforcing policies on whether privileged containers are allowed to run; configuring Kubernetes Network Policies to segment and restrict traffic between, to, and from pods; and monitoring RBAC settings for excess privileges.

Technique 4.1: Privileged container

Issue

In this first technique under Privilege Escalation, an attacker who gains access to a privileged container or has the ability to start a new container that is privileged will have all the capabilities of the host and can therefore gain access to host resources or compromise other containers running on the same host.

Best Practice for Mitigation

Primary area to configure security controls: Kubernetes

Organizations should implement several security practices to address the possibility of privilege escalation. First, they should limit the number of privileged containers that run within clusters, only allowing them when necessary. They should further configure Kubernetes Network Policies to segment network access to privileged containers and restrict RBAC privileges to create new Deployments or pods (in order to prevent a compromised pod’s service account credentials from being used to start a new privileged container).

How StackRox Helps

StackRox helps address the risks associated with privileged containers to enforce policies on whether privileged containers are allowed to run. It helps users visualize, simulate, and automatically generate and configure Kubernetes Network Policies. StackRox also monitors RBAC privileges to ensure that users or service accounts are not unnecessarily able to start privileged containers.

Technique 4.2: Cluster-admin role binding

Issue

The risk created by this threat vector is that users who are granted the cluster-admin role then have full access to the cluster and, consequently, have the ability to accomplish complete cluster compromise. Additionally, users who have RBAC permissions to create role bindings can create a binding to the cluster-admin role or other roles with high privileges.

Best Practice for Mitigation

Primary area to configure security controls: Kubernetes

Administrators should configure Kubernetes RBAC to limit who in their organization has the cluster-admin role and who can create role bindings. They should also replace uses of the cluster-admin role with users, groups, or service accounts that have more targeted, scoped-down permissions.

How StackRox Helps

StackRox helps mitigate this threat by automatically monitoring RBAC configurations and identifying users, groups, or service accounts with elevated privileges, including the cluster-admin role specifically.

Technique 4.3: hostPath mount

Issue

Similar to Technique 3.2 (Writable hostPath mount), the hostPath volume mounts a file or directory to the container, which would allow an attacker to gain access to resources or compromise other containers running on the same host.

Best Practice for Mitigation

Primary area to configure security controls: Kubernetes

Kubernetes

In Kubernetes, users can apply Pod Security Policies to limit the file paths that can be mounted using a host mount or disallow host mounts completely (note that Persistent Volume Claims bypass this policy) Kubernetes: They can also mark any required host paths as read-only whenever possible.

Cloud Provider

When configuring cloud provider environments, teams can limit node lifetimes by ensuring reverse uptime of 24 hours or less and automatically provision new nodes to replace them.

How StackRox Helps

The StackRox platform helps mitigate this threat by delivering dynamic policy-driven admission control as part of its platform that enables organizations to enforce security policies, including limitations on host mounts and their writability, before containers are ever deployed into Kubernetes clusters.

Technique 4.4: Access cloud resources

Issue

Organizations running Kubernetes clusters in cloud environments, including using cloud provider-managed Kubernetes services, must be aware of additional techniques that adversaries may seek to leverage. In this case, this technique involves an adversary gaining access to a single container, which could allow access to other cloud resources.

Real-world example: In Azure Kubernetes Service (AKS), each node contains a “service principal” credential that is stored in /etc/kubernetes/azure.json. AKS uses this service principal to create and manage Azure resources that are needed for the cluster operation. By default, the service principal has contributor permissions in the cluster’s Resource Group. 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. Note that this concept of a service principal is specific to AKS and is not directly applicable elsewhere.

Best Practice for Mitigation

Primary areas to configure security controls: Kubernetes and Cloud Provider

Many of the security practices that organizations can implement to mitigate this threat overlap with other techniques that target access to specific types of cloud resources, e.g., instance metadata.

Kubernetes

In Kubernetes, users can apply Pod Security Policies to limit the file paths that can be mounted using a host mount or disallow host mounts completely (note that Persistent Volume Claims bypass this policy). They can also mark any required host paths as read-only whenever possible.

How StackRox Helps

The StackRox platform helps mitigate attacker access to cloud resources with several capabilities. StackRox scans container images for vulnerabilities as they are built and enables users to quickly discover new vulnerabilities in running Kubernetes Deployments.

StackRox also enables dynamic admission control to prevent containers with specific vulnerabilities from launching and to enforce broader security policies, including limitations on host mounts and their writability, before containers are ever deployed into Kubernetes clusters. It enforces policies to secure pods such as only allowing non-root users and configuring read-only root file systems.

StackRox visualizes, simulates, and automatically configures Kubernetes Network Policies based on observed network traffic to restrict external access to pods. It also monitors Kubernetes RBAC configurations to help users identify risks and security weaknesses related to access settings.