04/22/2025 | Press release | Distributed by Public on 04/22/2025 16:35
Kubernetes misconfigurations often result in vulnerabilities that threat actors can exploit to exfiltrate data and damage systems. Learn more about the threat landscape and how to bolster Kubernetes configurations to mitigate against a devastating attack.
In Part 1 of our Kubernetes security essentials series, we examined the critical components of Kubernetes and the common security misconfigurations that make each one vulnerable. Now, let's explore how these vulnerabilities translate into real-world attack paths and what you can do to protect your clusters.
The incredible flexibility of Kubernetes creates an equally expansive attack surface. Quite often attackers don't need to exploit complex zero-day vulnerabilities-they simply walk through doors left open by misconfigurations. To better understand the potential impact of these misconfigurations, it's helpful to map them to specific attacker tactics and techniques. The Kubernetes Threat Matrix, inspired by the MITRE ATT&CK framework, provides a structured way to analyze and categorize these threats.
The following diagram shows a brief overview of some common security misconfigurations in Kubernetes and how these map to specific attacker tactics and techniques in the K8s Threat Matrix using a common attack strategy.
The Kubernetes threat matrix illustrates how attackers can exploit Kubernetes misconfigurations.Let's walk through a typical attack progression to see how these misconfigurations create a path for attackers. This scenario represents a composite of real incidents reported by security researchers and organizations.
An attacker discovers an exposed Kubernetes API server during a routine scan. The cluster has been configured with the default service account having more permissions than necessary, and authentication relies solely on TLS certificates without additional authorization controls.
After gaining initial access, the attacker lists all ConfigMaps in the cluster and discovers that the application team has stored database credentials and API keys directly in ConfigMaps rather than using Kubernetes secrets.
The attacker identifies containers running with unnecessary root privileges and without proper security contexts defined. Using the exposed credentials, they deploy a malicious pod with host path mounts.
With host access established, the attacker discovers that the cluster has no network policies defined. All pods can communicate with each other across namespaces without restrictions.
In the final stage, the attacker deploys resource-intensive cryptocurrency mining pods across the cluster. Since the cluster has no resource quotas or limits defined, these pods consume excessive CPU resources.
Following the attack path is like watching someone walk through your house, trying each door until they find the unlocked ones. Thus, each misconfiguration represents an opportunity for attackers.
In 2024 alone, several high-profile security incidents have highlighted the critical importance of proper configuration.
Studying these incidents reveals common patterns-exploitation is made easy due to misconfigurations that could have been prevented with proper security practices.
After experiencing security incidents, organizations typically commit to a comprehensive security overhaul of their Kubernetes environments. A successful approach focuses on addressing each category of misconfiguration:
apiVersion: v1 kind: ServiceAccount metadata: name: app-specific-account namespace: application-namespace --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: app-specific-role namespace: application-namespace rules: - apiGroups: [""] resources: ["pods", "services"] verbs: ["get", "list", "watch"]
apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: vault-database-creds spec: provider: vault parameters: vaultAddress: "https://vault.example.com:8200" roleName: "database-role" objects: | - objectName: "dbUsername" secretPath: "database/creds/app-role" secretKey: "username" - objectName: "dbPassword" secretPath: "database/creds/app-role" secretKey: "password"
apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: enforce: "restricted" enforce-version: "latest" audit: "restricted" audit-version: "latest" warn: "restricted" warn-version: "latest" exemptions: usernames: [] runtimeClasses: [] namespaces: ["kube-system"]
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny namespace: application-namespace spec: podSelector: {} policyTypes: - Ingress - Egress --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-specific-traffic namespace: application-namespace spec: podSelector: matchLabels: app: web-frontend ingress: - from: - namespaceSelector: matchLabels: name: ingress-namespace egress: - to: - podSelector: matchLabels: app: api-backend ports: - protocol: TCP port: 8080
macro: spawned_process condition: evt.type = execve and evt.dir = < macro: container condition: container.id != host macro: user_known_container_breakout_processes condition: proc.name in ( nginx, httpd, mysqld) - rule: Container Breakout Detected desc: Detects attempts to escape from a container to the host condition: > spawned_process and container and not user_known_container_breakout_processes and proc.name in (chroot, nsenter, unshare, dmsetup, debugfs) output: > Container breakout attempt detected (user=%user.name command=%proc.cmdline container=%container.id) priority: CRITICAL tags: [container, breakout]
The most important lesson that security-conscious teams learn is that Kubernetes security isn't a one-time setup. It's an ongoing process that requires vigilance, regular audits, and staying informed about new threats and best practices.
As we have explored in this post, Kubernetes security misconfigurations represent a significant risk that many organizations face today. Understanding these common vulnerabilities, their potential impact, and how they map to real-world attack techniques is essential for building a more secure Kubernetes environment.
Our journey into Kubernetes security will continue in the next post, where we'll move from theory to practice. We'll set up a vulnerable cluster environment mimicking real-world applications and explore container security misconfigurations in depth. Rather than just introducing tools, we'll provide hands-on demonstrations of actual security assessments and remediation techniques.
You'll also see firsthand how Dynatrace's Kubernetes Security Posture Management (KSPM) capabilities offer advantages over traditional approaches. Unlike open-source solutions that require significant integration effort, Dynatrace KSPM seamlessly combines deep Kubernetes observability with automated security assessments against industry standards like NIST and CIS.
To learn more about the anatomy of Kubernetes misconfigurations that can lead to these different kinds of exploits, see part 1 of the Kubernetes security essentials series, Understanding Kubernetes security misconfigurations.