The eighth installment in our nine-part blog series – where we examine each of the nine MITRE ATT&CK tactics and techniques for Kubernetes – examines lateral movement. Following a breach, an attacker might try to move throughout the environment to gain access to other resources, including other containers, nodes, or cloud resources. This blog post covers the set of techniques an attacker can employ to achieve lateral movement and offers guidance to mitigate them.

You can find the first seven articles in the series below:

Technique 8.1: 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. Note this overlaps with Technique 4.4 “Access cloud resources” for reference.

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.

root-file-system-screenshot_jkn7oh

Technique 8.2: Container service account

Issue

By default, a service account is mounted to every pod in a Kubernetes cluster, which allows containers to send requests to the Kubernetes API server. An attacker who gains access to a pod can obtain the service account token. If Kubernetes RBAC is not enabled, the service account token will grant the attacker full access to the cluster. If RBAC is enabled, service account privileges are determined by role bindings. If these grant elevated privileges, an attacker can make requests to the Kubernetes API server to compromise cluster resources. Also see Technique 6.3 “Access container service account” for reference.

Best Practice for Mitigation

Primary area to configure security controls: Kubernetes

Organizations can mitigate this threat vector by configuring Kubernetes RBAC and adopting a least privilege model for service accounts and their role bindings. For example, the use of the cluster-admin role should be highly restricted (see Technique 4.2 “Cluster-admin role binding”).

How StackRox Helps

StackRox helps guard against this technique by monitoring Kubernetes RBAC configurations and enforcing security policies on pod access to the Kubernetes API server.

Technique 8.3: Cluster internal networking

Issue

This threat vector arises since, by default, Kubernetes does not restrict network traffic between pods. An attacker who gains access to a single pod can communicate with and gain subsequent access to other running pods/applications.

Best Practice for Mitigation

Primary area to configure security controls: Kubernetes

Organizations can mitigate this threat by enabling and configuring Kubernetes Network Policies to restrict and segment traffic between pods, preventing an attacker from being able to reach every pod running in a cluster.

How StackRox Helps

StackRox helps protect against this technique by monitoring active network traffic and visualizing, simulating and automatically generating Kubernetes Network Policies to restrict communications to only what is necessary for application components to operate.

stackrox-network-graph-simulation_x75ljq (1)

Technique 8.4: Application credentials in configuration files

Issue

Secrets are often stored as environment variables in pod configurations and Kubernetes configuration files. Access to these configurations would allow a malicious actor to steal these secrets and access cluster resources. Also see Technique 6.4 “Application credentials in configuration files” for reference.

Best Practice for Mitigation

Primary areas to configure security controls: Kubernetes and Other - Open source tooling

Kubernetes

Organizations should avoid the risks of this threat vector by implementing checks and processes to ensure secrets are not passed in Kubernetes manifests, which are used to create, modify and delete Kubernetes resources.

Other - Open source tooling

Organizations can consider using open source tools to identify secrets that have been added to source control.

How StackRox Helps

StackRox helps mitigate this technique by providing a built-in policy that identifies potential secrets being stored in environment variables.

env-variable-as-secrets-screenshot_ystegg

Technique 8.5: Writable mounts on the host

Issue

With this technique, the hostPath volume mounts a file or directory to the container, which would allow an attacker to persist on the container host. This overlaps with Technique 3.2 “Writable hostPath mount” for reference.

Best Practice for Mitigation

Primary areas to configure security controls: Kubernetes and Cloud Provider

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 mou

Technique 8.6: Access Kubernetes Dashboard

Issue

The Kubernetes Dashboard is a web-based user interface that can be used for managing cluster resources. It exposes an internal endpoint and if accessible publicly, it can allow unauthenticated cluster management. Certain versions of Kubernetes platforms may deploy the Dashboard by default. See Technique 1.5 “Exposed Dashboard” and Technique 7.4 “Access Kubernetes Dashboard” for reference.

Real-world example: The car company Tesla experienced a breach of its Amazon Web Services (AWS) infrastructure due to a Kubernetes Dashboard that was exposed to the Internet and did not require authentication. The Dashboard further had elevated privileges on the cluster and allowed attackers to obtain AWS credentials that were then utilized to repurpose the environment to mine cryptocurrency.

Best Practice for Mitigation

Primary area to configure security controls: Kubernetes

If the Dashboard is not needed, administrators should ensure that it is deleted from the environment entirely or disabled (which is now generally the case for many Kubernetes platforms). If the Dashboard needed and is deployed, then do not grant it elevated service account privileges, remove any bindings to its service account, and block ingress traffic using Kubernetes Network Policies.

How StackRox Helps

StackRox provides a built-in policy to alert when the Kubernetes Dashboard is deployed. It also monitors RBAC privileges on service accounts and can identify whether elevated privileges have been granted to the Dashboard. It can also ensure incoming traffic to the Dashboard is blocked by configuring Kubernetes Network Policies.

kube-dashboard-policy_coy5p8 (1)
Technique 8.7: Access tiller endpoint

Issue

This technique is based on Tiller, which is the server-side component of earlier versions of Helm, a package manager for Kubernetes, and exposes an internal API endpoint that does not require authentication. It typically has high privileges and an attacker can use its service account to gain access to other containers.

Best Practice for Mitigation

Primary area to configure security controls: Other - Helm

Organizations can mitigate this threat by ensuring that they upgrade to the latest version of Helm for deploying their Kubernetes applications.


About the author

Wei Lien Dang is Senior Director of Product and Marketing for Red Hat Advanced Cluster Security for Kubernetes. He was a co-founder at StackRox, which was acquired by Red Hat. Before his time at StackRox, Dang was Head of Product at CoreOS and held senior product management roles for security and cloud infrastructure at Amazon Web Services, Splunk, and Bracket Computing. He was also part of the investment team at the venture capital firm Andreessen Horowitz.

Read full bio