Four Takeaways from the Kubernetes Threat Matrix

After its initial creation by Google in 2014, Kubernetes has become a de facto standard for container orchestration. In the Cloud Native Computing Foundations 2022 Annual report, 65% of end users reported to use Kubernetes in production environments, with another 25% evaluating to do the same. Given the popularity, it is no surprise that threat actors have taken note. The fluidness of orchestrated, containerized environments create a ripe environment for threat actors to find opportunities to gain footholds for their nefarious plans.

Recognizing this, the Azure Security team at Microsoft opted to develop a threat matrix for Kubernetes to identify threat actors’ tactics specifically targeting K8s environments. The Azure Security Team realized tactics used to gain access to an operating system are similar to that of a Kubernetes cluster:

Borrowing from MITRE’s ATT&CK Matrix, the Kubernetes Threat Matrix identifies different tactics and techniques along the different stages of the attack, presenting the multitude of attack paths available to a threat actor. 

Four realizations occur from reviewing the Kubernetes Threat Matrix:

1. While teams can reduce their attack surface by patching known vulnerabilities, container and node activities must be monitored at runtime, even short-lived workloads, in order to identify attack tactics. Examples of attack tactics in the data plane include ‘ssh inside container’, ‘application exploit RCEs’, ‘resource hijacking’, and others.  To see examples of container escape attacks, see our previous blog How eBPF Can Help Identify Container Escapes
2. Beyond container data plane activity, teams must monitor Kubernetes control plane activities. The control plane is sometimes referred to as the "brain" or "master" of the Kubernetes cluster. It is responsible for managing and controlling the overall state and configuration of the cluster. Attack tactics in the control plane captured in the threat matrix include ‘sidecar injection’, ‘deleted K8s events’, ‘new K8s cronjobs’, and others.
3. Since the control plane can be exploited, even infrastructure that is frequently re-deployed or updated is vulnerable to a persistent attack. Frequent deployments (e.g. 8+ deployments/day) can create a false sense of confidence that the K8s environment is immutable. How can someone establish persistence when the infrastructure is constantly resetting? The control plane attack tactics demonstrate how attackers do gain persistence even in constantly changing environments.
4. Context is critical for understanding real attacks versus false positives. Many of the tactics captured in the threat matrix also occur regularly under innocuous circumstances. For example, new containers are created all the time. Kubelet API calls occur all the time. Simply creating detections across the matrix will only generate noise and potentially mask true attack activity. Therefore, teams need to connect potential threat matrix activity together to understand real threats and intercept them quickly.

 This puts Spyderbat in an ideal situation for Kubernetes runtime security. Spyderbat uniquely connects activities together based on their causal relationships. Spyderbat detects security concerns from either data or control planes with its detailed visibility into what actually occurs at runtime. Instead of alerting to each individual detection, Spyderbat flags activities that deviate from validated states or are known attack tactics. Sequences of activities, called Spydertraces, are evaluated based on their number of flags, flag severity, etc. in real-time. Spyderbat accurately identifies real emerging attacks when the Spydertrace hits a high risk score. 

 In subsequent blog posts, we will dissect individual attacks to illustrate how threat actors are infiltrating K8s environments and demonstrate how Spyderbat recognizes their individual tactics and how they are connected together.