MITRE ATT&CK Matrix for Kubernetes: Tactics & Techniques Part 2
Learn about the next three threat vectors in Kubernetes: defense evasion, credential access, and discovery.
Overview
In this second piece of a 3-part series, we will zero into the MITRE ATT&CK Matrix of known tactics and techniques. This post discusses these three threat vectors - Defense Evasion, Credential Access, and Discovery.
Further reading on MITRE ATT&CK Matrix:
• MITRE ATT&CK Matrix Part I: Threat Vectors - Initial Access, Execution, Persistence, and Privilege Escalation
• MITRE ATT&CK Matrix Part III: Threat Vectors - Lateral Movement, Collection, Impact
Defense Evasion
This tactic includes techniques that enable attackers to gain additional or higher privileges in the environment. They can use these privileges to get access to more resources in the cluster or take other actions within the cluster. In containerized environments, they may get access to the node from a container.
1- Privileged Container
A privileged container has all the capabilities of the host machine and none of the limitations of a regular container. If an attacker gains access to a privileged container or has the permissions to start a new privileged container, they can gain access to the host’s resources, or compromise other containers running on the same host.
2- Cluster-admin Binding
Cluster-admin is a built-in high privileged role in Kubernetes. Users with this role have full access to the cluster, and can potentially compromise it. Attackers with RBAC (Role-based access control) permissions to create bindings and cluster-bindings in the cluster can create a binding to the cluster-admin role or other roles with high privileges.
3- HostPath Mount
The hostPath volume mounts a file or directory from the host to the container. This can allow attackers to gain access to the underlying host or resources, break from the container to the host, or compromise other containers running on the same host.
4- Access Cloud Resources
An adversary may use this technique to gain access to a single container in a Kubernetes cloud cluster to access other cloud resources outside the cluster. For instance, if they gain access to the service principal credential file in Azure Kubernetes Service (AKS), they may be able to use these credentials to access or modify the cloud resources.
Credential Access
This tactic refers to the techniques and activities attackers leverage to steal sensitive credentials such as application secrets, passwords, and tokens. These credentials could be used by users or service accounts. In containerized environments, attackers may steal cloud or application credentials, identities, or secrets stored in the cluster. By stealing these credentials, they may get access to applications, cloud resources, or cluster resources like pods, controllers, or other Kubernetes objects.
1- List K8s (Kubernetes) Secrets
Kubernetes Secrets are objects that enable organizations to store and manage sensitive credentials, including passwords, tokens, keys, and connection strings in the cluster. A K8S Secret is by default, stored unencrypted in the API server's underlying data store (etcd), so anyone with access to etcd or API access can retrieve or modify a Secret. An attacker with permission to retrieve the secrets from the API server may access sensitive information, including credentials for key services, such as a database service.
2- Mount Service Principal
An attacker may use this technique to get access to a single container in the cluster. This may allow them to gain access to cloud credentials resources. For example, in Azure Kubernetes Service (AKS), each node contains a “service principal” credential stored in /etc/kubernetes/azure.json. Attackers who get access to this service principal file can use its credentials to access or modify the cloud resources.
3- Access Container Service Account (SA)
In Kubernetes, a service account (SA) is an application identity. By default, an SA is mounted to every pod in a Kubernetes cluster. It allows containers to send requests to the Kubernetes API server. An attacker who gains access to a pod can obtain the SA token and perform unauthorized actions in the cluster. If RBAC is enabled, SA privileges are determined by the role bindings associated with it. But if RBAC is not enabled, the SA token will grant the attacker unlimited permissions and full access to the cluster.
4- Application Credentials in Configuration Files
Secrets are stored in the Kubernetes configuration files, for example, as environment variables in the pod configuration. If an attacker has access to these configurations, either by querying the API server or accessing files on the developer’s endpoint, they would be able to steal these secrets and use them to access cluster resources.
5- Access Managed Identity Credential
“Managed identities” and their secrets are managed by cloud providers, allocated to cloud resources such as virtual machines, and used to authenticate with cloud services. Applications can access the Instance Metadata Service (IMDS) to obtain the identity’s token. Attackers who get access to a Kubernetes pod can take advantage of their access to the IMDS endpoint to get the managed identity’s token, and then access cloud resources.
6- Malicious Admission Controller
Attackers may leverage generic, malicious admission controllers built into Kubernetes, such as ValidatingAdmissionWebhook to access credentials. This controller’s behavior is determined by an admission webhook deployed in the cluster. Attackers can use this webhook to intercept requests to the API server, or to record secrets and other sensitive information.
Discovery
Attackers use numerous Discovery techniques to explore the Kubernetes environment to which they have gained access. Their aim may be to achieve lateral movement across the environment and gain access to additional resources within or beyond the cluster. Some techniques allow them to gain access to the Kubernetes API server or Kubelet API, while others enable them to map the cluster network or compromise resources via the Kubernetes Dashboard or cloud instance metadata.
1- Access the K8s API Server
The Kubernetes API server is a critical component that serves as the front end or gateway of the Kubernetes control plane. It exposes the Kubernetes RESTful API that allows various actions to be performed in the cluster. The API server also retrieves the status of the cluster, including all components deployed on it. An attacker who gains access to this API server can send API requests to probe the cluster and retrieve information and secrets about its resources.
2- Access Kubelet API
The Kubelet is an agent installed on every Kubernetes node that ensures that pods assigned to the node execute properly. It 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 with API requests to retrieve the running pods on the host and information about the host, such as CPU and memory consumption.
3- Network Mapping
By default, Kubernetes does not restrict network traffic (communication) between pods. An attacker can take advantage of this fact. If they gain access to a single container, they may use it to probe the cluster network, map it, and discover information about running pods/applications, including scanning for known vulnerabilities.
4- Access Kubernetes Dashboard
The Kubernetes Dashboard is used to monitor and manage the Kubernetes cluster. Users can perform actions in the cluster with the permissions that are determined by the binding or cluster-binding for its service account. However, an attacker with access to a single container in the cluster can subsequently access the Kubernetes Dashboard, and use its identity to retrieve information about the cluster resources.
5- Instance Metadate API
Cloud providers provide a metadata service to retrieve information about a virtual machine (VM), including its network configuration, underlying hosts, disks, SSH public keys, and sensitive credentials. VMs can access this service via a non-routable IP address from within the VM only. If an attacker is able to access this metadata, they may be able to leverage it to access or compromise container or cloud resources.
MITRE ATT&CK and Weave GitOps
The MITRE ATT&CK Threat matrix can help organizations harden their cluster security with a layered defense approach. Businesses can use the framework to create adversary emulation scenarios to test and verify in-place cybersecurity control against techniques used by attackers. This way, organizations have a better understanding of the Kubernetes-based environments’ attack surface and ensure adequate preventative actions to mitigate the associated risks.
Weave GitOps, the full-stack GitOps platform used for automating deployments, now includes MITRE ATT&CK OPA-based policies as part of the larger Weave Policy Library. Enterprises can instantly implement policy guardrails in their CI/CD pipelines, ship code faster with enforced security, and confidently de-risk deployments. This is what we call Trusted Delivery - using policy as code in CI/CD pipelines.
Request a demo now to learn more about Trusted Delivery and explore our Weave Policy Library.
Request a DemoWhitepaper: Trusted Delivery with GitOps and Policy as Code
Download our latest whitepaper and learn how automated security and compliance checks, in the form of policy as code, make automated continuous deployments safe and secure.
