Dynatrace Inc.

04/22/2025 | Press release | Distributed by Public on 04/22/2025 16:35

Kubernetes security essentials: Kubernetes misconfiguration attack paths and mitigation strategies

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 threat landscape: Mapping Kubernetes misconfigurations to attack tactics

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.

Kill chain of a Kubernetes attack

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.

Initial access

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.

  • Misconfiguration: Exposed API server + overly permissive RBAC settings
  • Attacker technique: The attacker uses automated tools to authenticate as the default service account and begins reconnaissance of the cluster resources.

Credential harvesting (credential access)

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.

  • Misconfiguration. Sensitive information stored in ConfigMaps + inadequate secret management
  • Attack technique. The attacker extracts credentials from ConfigMaps and gains access to the application's database and third-party services.

Privilege escalation

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.

  • Misconfiguration. Containers running as root + missing security context constraints
  • Attack technique. The attacker escapes the container boundary by exploiting the root privileges and gains access to the underlying host system.

Lateral movement across the cluster

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.

  • Misconfiguration. Missing network policies + inadequate namespace isolation
  • Attack technique. The attacker moves laterally from the compromised application namespace

Establishing persistence and impact

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.

  • Misconfiguration. Missing resource quotas and limits
  • Attack technique. The mining operation consumers enough cluster resources to degrade the performance of legitimate workloads, creating a denial-of-service condition while generating cryptocurrency for the attacker. In other cases, this could result in high bills from cloud providers where the cluster is deployed.

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.

Recent Kubernetes security incidents: Learning from others' mistakes

In 2024 alone, several high-profile security incidents have highlighted the critical importance of proper configuration.

  1. TLS Bootstrap Attack on Microsoft Azure Kubernetes Services (AKS). Researchers uncovered a vulnerability that allowed attackers to escalate privileges and access sensitive credentials within the cluster. The attack leveraged a component called Azure WireServer to retrieve a key used for encrypting protected settings, enabling the attacker to decode provisioning scripts containing critical information. This incident underscores the importance of securing access controls and properly configuring network policies to prevent unauthorized access.
  2. Exploitation of OpenMetadata Flaws. Threat actors exploited critical vulnerabilities in `OpenMetadata` to gain unauthorized access to Kubernetes workloads for cryptocurrency mining. These flaws included several Spring Expression Language (SpEL) injection issues and an authentication bypass, with CVSS scores between 8.8 and 9.8. This highlights the need for regular updates and patches to prevent exploitation of known vulnerabilities.
  3. Critical Kubernetes Vulnerability (CVE-2024-10220). A high-severity vulnerability allowed attackers to execute arbitrary commands beyond container boundaries. This vulnerability affected Kubernetes clusters using the in-tree `gitRepo` volume to clone repositories to subdirectories. This incident emphasizes the importance of deprecating insecure components and implementing proper access controls.
  4. IngressNightmare Vulnerability (CVE-2025-1974). A critical unauthenticated remote code execution (RCE) vulnerability was recently discovered in the Kubernetes Ingress-NGINX Controller. This blog post explains how to detect and mitigate this vulnerability using Dynatrace. The IngressNightmare vulnerability allows attackers to inject arbitrary NGINX configuration remotely by sending a malicious ingress object directly to the admission controller through the network. This incident clearly highlights the necessity of securing admission controllers and implementing robust authentication mechanisms to prevent unauthorized access and potential cluster takeover.

Studying these incidents reveals common patterns-exploitation is made easy due to misconfigurations that could have been prevented with proper security practices.

Best practices for avoiding Kubernetes misconfiguration security incidents

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:

API server security

  • Implement the principle of least privilege through fine-grained RBAC policies.
  • Regularly audit role and role-binding assignments using tools like kubectl auth can-i
  • Place the API server behind a proper gateway with strong authentication
  • Enable audit logging with appropriate verbosity to track API usage
  • Implementation example: Create dedicated service accounts for each application with minimal permissions.
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"]

Implement proper secret management

  • Never store sensitive data in ConfigMaps or as environment variables
  • Use Kubernetes Secretes as a minimum baseline, but recognize they're only base64-encoded
  • For production consider external secret management solutions:
    • AWS Secrets Manager or Azure Key Vault for cloud deployments
    • HashiCorp Vault for multi-cloud or on-premises environments
    • Sealed Secrets for GitOps workflows
  • Enable encryption at rest for etcd to protect secret data

Implementation example: Using external secrets with HashiCorp Vault

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"

Enforce pod security standards

  • Implement Pod Security Admission or third-party admission controllers
  • Prohibit privileged containers by default
  • Require containers to run as non-root users
  • Prevent dangerous capabilities and host path mounts
  • Set up resource requests and limits for all workloads

Implementation example: Creating a pod security standard policy

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"]

Establish network segmentation

  • Define explicit network policies for each namespace
  • Start with a default deny-all policy and add specific allowances
  • Segment production, staging and development workloads
  • Use tools like Network Policy Advisor to generate policies based on traffic

Implementation example: A default deny policy with specific allowances

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

Implement comprehensive monitoring and detection

  • Deploy runtime security tools like Falco to detect suspicious container activities
  • Set up proper logging with centralized collection
  • Implement automated scanning of container images
  • Use Kubernetes-native monitoring solutions that understand the orchestration layer
  • Set up alerts for unusual resource consumption or unexpected API calls

Implementation example: A Falco rule to detect container escapes

macro: spawned_process 
condition: evt.type = execve and evt.dir = <&nbsp;
 
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.

From understanding to action: Your Kubernetes security roadmap

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.

Learn more about how Dynatrace can help you automate Kubernetes security with the Kubernetes security and compliance automation guide.