Protecting Against Kubernetes Threats: Chapter 9 – Impact

The final part of our nine-part blog series – where we examine each of the nine MITRE ATT&CK tactics and techniques for Kubernetes – analyzes a set of techniques that fall under the category known as Impact.

These techniques are aimed at disrupting or destroying resources and activity within the target environment, or in other words, the ultimate goal of an attacker. These include techniques to achieve data destruction, resource hijacking or denial of service.

StackRox helps protect against this tactic and its techniques with a wide range of capabilities that include:

• scanning all container images that deploy into clusters
• enforcing policies for image provenance
• identifying Kubernetes vulnerabilities in clusters
• monitoring Kubernetes configurations, RBAC access privileges, and runtime activity
• and visualizing, simulating, and automatically generating Kubernetes Network Policies

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

• Part 1 – Initial Access
• Part 2 – Execution
• Part 3 – Persistence
• Part 4 – Privilege Escalation
• Part 5 – Defense Evasion
• Part 6 – Credential Access
• Part 7 – Discovery
• Part 8 – Lateral Movement

Technique 9.1: Data Destruction

Issue

This technique reflects the ability of an attacker to delete or remove resources in a Kubernetes cluster, including Deployments, configurations, nodes, pods, or other data.

Sponsorships Available

Sponsorships Available

Sponsorships Available

Best Practice for Mitigation

Primary areas to configure security controls: Kubernetes and Cloud Provider

Kubernetes

Organizations can protect themselves from this threat vector by monitoring Kubernetes audit logs, which provide a chronological record of cluster events and restricting RBAC access according to the principle of least privilege.

Cloud Provider

Organizations should restrict access to Kubernetes cluster nodes and, if applicable, any cloud configuration APIs exposed by cloud provider-managed Kubernetes services.

How StackRox Helps

StackRox helps mitigate this threat by enforcing policies for and identifying weaknesses in Kubernetes configurations, monitoring RBAC access configurations, and analyzing runtime activity, such as process execution, within containers.

Kubernetes-native security – what is it and why it matters

Learn about the benefits of Kubernetes-native security and how it’s different from existing container security approaches to deliver protections that are purpose-built for Kubernetes environments.

Download Now

Technique 9.2: Resource Hijacking

Issue

With this technique, an attacker may hijack a Kubernetes resource for unintended purposes. One example of this is using compromised containers to run malicious tasks such as cryptomining.

Real-world example: Microsoft Azure has disclosed the discovery of multiple campaigns, including a large-scale one, where attackers targeted Kubernetes clusters and were able to impact them by running cryptocurrency miners, otherwise known as “cryptojacking” attacks.

Best Practice for Mitigation

Primary area to configure security controls: Kubernetes and Cloud Provider

Kubernetes

Organizations can mitigate the threat of resource hijacking by configuring RBAC access to restrict the ability to create pods.

Cloud Provider

WIthin a cloud provider, organizations should take steps to restrict and minimize access to Kubernetes cluster nodes.

How StackRox Helps

StackRox helps protects organizations from resource hijacking by scanning all images that are used to deploy containers into the cluster and enforcing policies for image provenance. For example, many reported cryptojacking attacks have arisen from backdoored images stored in public registries containing malicious software. StackRox also monitors runtime activity with a built-in policy to detect cryptomining processes that execute.

Technique 9.3: Denial of service

Issue

With this technique, an attacker may seek to make services unavailable by impacting the availability of components within the Kubernetes control plane including the API server, cluster nodes, or application components in pods, or other resources.

Real-world example: CVE-2019-1002100 is a vulnerability in the Kubernetes API server that allows users with certain write permissions on the Kubernetes API to make write requests that cause the API server to utilize excessive resources, resulting in a denial of service.

Best Practice for Mitigation

Primary areas to configure security controls: Kubernetes and Cloud Provider

Kubernetes

Organizations can mitigate this threat by first ensuring they upgrade to the latest version of Kubernetes. Additionally, they can configure Kubernetes Network Policies to permit only necessary connections within the pod network.

Cloud Provider

Organizations should utilize cloud firewalls and other controls to restrict access to the cluster API endpoint and other sensitive, internally-consumed services to trusted IP addresses only.

How StackRox Helps

StackRox delivers protections to help mitigate this threat by automatically identifying Kubernetes vulnerabilities as well as visualizing, simulating, and automatically generating Kubernetes Network Policies to segment and restrict communication throughout the environment.

Final Thoughts

Kubernetes is enabling organization of every size across every industry in their efforts to modernize applications and infrastructure as part of strategic digital transformation efforts. Using Kubernetes, companies are now able to build and run applications at faster and at greater scale than previously possible. At the same time, Kubernetes creates a new threat environment that is complex and not yet well understood, giving rise to emerging and evolving attack vectors. The Kubernetes attack matrix provides an important, starting foundation for the Kubernetes community and cloud-native ecosystem to effectively protect Kubernetes, and the applications that run on it, from common tactics and techniques that might be used by adversaries.

The rich set of security controls made available by both Kubernetes and cloud provider platforms lend themselves to a set of security best practices that organizations can implement to mitigate the threats described in the Kubernetes attack matrix. This aligns with established frameworks for security such as the shared responsibility model for cloud environments.

To comprehensively mitigate the threats listed in the attack matrix requires a security approach that goes beyond being container-centric. It requires security that is Kubernetes-native: security that is fully architected to integrate with and leverage native security controls within Kubernetes itself.

New Kubernetes attack vectors will continue to be discovered over time alongside the growth of the platform, and organizations should be prepared to expand their Kubernetes security efforts over time to accommodate these developments. StackRox’s Kubernetes-native security is designed to address new threats to Kubernetes applications and infrastructure as they emerge.