Protecting Kubernetes Against MITRE ATT&CK: Discovery

Part seven of our nine-part blog series – where we examine each of the nine MITRE ATT&CK tactics and techniques for Kubernetes – examines the technique known as Discovery. The tactics in this category are intended to help an attacker effectively explore a Kubernetes environment to achieve lateral movement and gain access to a wider scope of resources with or beyond the cluster. They include ways to gain access to the Kubernetes API server or the Kubelet API, map the cluster network, or compromise resources via the Kubernetes Dashboard or cloud instance metadata.

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

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

StackRox helps address these threats by visualizing and configuring Kubernetes Network Policies, including blocking access to the kubelet port, and monitoring Kubernetes RBAC privileges.

Technique 7.1: Access the Kubernetes API server

Issue

This technique focuses on the Kubernetes API server, a critical component that serves as the front end of the Kubernetes control plane and exposes the Kubernetes API. An attacker who gains access to the Kubernetes API server can retrieve information about a cluster’s resources.

Best Practice for Mitigation

Primary areas to configure security controls: Kubernetes and Cloud Provider

Kubernetes

Administrators should ensure the Kubernetes API server is configured securely and limit (1) which users and service accounts have access to the Kubernetes, and (2) their permissions.

Enable and configure Kubernetes RBAC to limit which users and service accounts have access to the Kubernetes API server and their permissions.

Cloud Provider

Administrators should restrict external cluster access to trusted source IP addresses only.

How StackRox Helps

StackRox mitigates risks associated with adversaries accessing the Kubernetes API server by analyzing RBAC permissions to limit the users and service accounts that have privileges to retrieve information about cluster resources.

Technique 7.2: Access Kubelet API

Issue

This technique exploits the Kubelet, an agent that is installed on every Kubernetes node and exposes a read-only API service that does not require authentication on TCP port 10255. An attacker with network access to the host can query the Kubelet API to discover running pods on the host as well as information about the host such as CPU and memory consumption.

Best Practice for Mitigation

Primary area to configure security controls: Kubernetes

Organizations can mitigate this threat by configuring Network Policies to block pod access to the Kubelet port or restrict other sensitive network egress.

Technique 7.3: Network Mapping

Issue

This technique takes advantage of the fact that, by default, Kubernetes does not restrict network traffic between pods. An attacker who gains access to a single pod can map the cluster network to discover 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 discovering every pod running in a cluster.

How StackRox Helps

StackRox helps protect against network mapping by monitoring active network traffic between pods and automatically generating and configuring Network Policies to restrict communications to only what is necessary for application components to operate.

Technique 7.4: Access Kubernetes Dashboard

Issue

By default, Kubernetes does not restrict network traffic between pods. An attacker who gains access to a single pod can subsequently access the Kubernetes Dashboard and retrieve information about the cluster.

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 is 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.

Technique 7.5: Instance Metadata API

Issue

Cloud providers expose metadata services to containers, which includes information about the environment, including the underlying hosts, or sensitive credentials. An attacker who is able to access this instance metadata can leverage it to access or compromise a broader set of either container or cloud resources.

Real-world example: A server-side request forgery (SSRF) vulnerability was reported in Shopify infrastructure. This allowed an attacker to retrieve kube-env (which includes Kubelet credentials) from a cloud metadata service and could lead to full cluster compromise.

Best Practice for Mitigation

Primary areas to configure security controls: Kubernetes.

Kubernetes

In Kubernetes, organizations should ensure they configure egress Network Policies to restrict sensitive traffic including communication with cloud metadata services.