Introduction
In December 2025, researchers uncovered a cybercrime campaign known as TeamPCP that systematically targeted exposed Docker and Kubernetes APIs across AWS and Azure environments. Once inside a cluster, the malware harvested credentials, enumerated pods and namespaces, and deployed privileged DaemonSets capable of mounting the host filesystem. More than 185 compromised servers were linked to the campaign, which was used to support cryptomining, proxy services, and data theft.
What makes the incident notable is that it didn’t rely on a zero-day exploit. The attackers gained access through exposed orchestration APIs and moved laterally using trusted internal traffic and legitimate credentials-activity that traditional perimeter-focused defenses were never designed to inspect. Subsequent research found the group continuing to target Kubernetes and CI/CD infrastructure as entry points into enterprise cloud environments.
This is why Kubernetes application security can no longer rely on traditional WAFs alone. Built for static applications and north-south traffic inspection, conventional WAFs struggle to protect dynamic containerized environments where APIs, services, and workloads constantly change. Kubernetes WAAP (Web Application and API Protection) addresses this challenge by extending protection across web applications, APIs, and runtime activity within cloud-native environments.
What Is a Kubernetes WAAP Security Solution?
Kubernetes WAAP is a security architecture that embeds web application, API, bot, and DDoS protection directly inside containerized environments, enforcing policy at the pod, service, and namespace level rather than only at the network edge. Unlike a traditional Kubernetes WAF, which inspects traffic only at the ingress controller, a full WAAP platform extends visibility into east-west service-to-service traffic, continuously discovers APIs as they’re created and retired, and applies behavioral detection instead of static signatures.
Why Legacy WAFs Can’t Protect Your Kubernetes Applications
Pods don’t have permanent addresses, a workload that lives ninety seconds during an autoscaling event can still process live customer data, yet IP-based allowlists and manually tuned rules degrade the moment infrastructure stops being stable. Worse, ingress-level WAFs only see north-south traffic. Service-to-service and namespace-to-namespace calls almost never pass through that ingress point, so once an attacker lands inside one compromised container, lateral movement happens entirely within the cluster, unseen.
Kubernetes is also API-first by default: CI/CD pipelines push new endpoints daily, and shadow APIs quietly persist in production. Modern attackers don’t need noisy exploits, they use valid tokens and authenticated, schema-correct requests that signature-based controls have no reason to flag. That’s a behavioral problem, not a pattern-matching one.
The Four Blind Spots Attackers Exploit Inside Kubernetes
Across enterprise environments, the same four gaps show up regardless of cloud provider or industry:
- East-west blind spot, most internal traffic bypasses the ingress WAF entirely, uninspected at Layer 7.
- API sprawl and shadow endpoints, new APIs ship faster than policy can track them, and deprecated test routes often keep accepting traffic long after a service is supposedly retired.
- Logic abuse via valid requests, BOLA, token replay, and mass assignment look perfectly legitimate to static rules, since nothing about the request itself is malformed.
- Gradual exfiltration, data leaves slowly through legitimate internal APIs, staying under volumetric thresholds until behavioral analysis catches the pattern.
What Happens After A Threat Actor Gets Inside The Cluster
- Ingress bypass, stolen credentials or a misconfiguration get initial access (the one stage a perimeter WAF may catch).
- API enumeration, undocumented endpoints get probed for logic weaknesses.
- Token pivot, service account tokens are intercepted and replayed.
- Privilege escalation, RBAC misconfiguration extends access.
- Data exfiltration, data leaves slowly over days or weeks through legitimate-looking calls.
Stages two through five happen entirely inside the cluster, invisible without east-west runtime inspection, regardless of how well-tuned the perimeter WAF is.
What a Advanced Kubernetes WAAP Security Must Deliver
A capable WAAP for Kubernetes needs four things working together: runtime protection enforced at the pod and service level with per-service behavioral baselines; continuous API discovery across REST, gRPC, and GraphQL that surfaces shadow endpoints automatically; bot mitigation built on session-level behavioral scoring rather than IP reputation alone, since credential-stuffing bots now target APIs directly; and DDoS protection that’s logic-aware enough to stop a Layer 7 flood before it triggers runaway autoscaling and cloud-cost spikes, a pattern increasingly called “denial of wallet.”
Deployment flexibility matters too. Enterprise clusters typically combine ingress controller integration (for north-south payloads), sidecar or DaemonSet placement (for east-west visibility with no application code changes), and centralized multi-cluster policy management across EKS, AKS, GKE, and on-prem environments.
Why Runtime Visibility Remains Kubernetes Biggest Security Challenge
Workloads are short-lived, logs are distributed across nodes, and traditional monitoring wasn’t built for clusters that reshape themselves dozens of times a day. Closing this gap means correlating three layers, discovery (what exists), posture (how it’s configured), and runtime enforcement (what’s happening on the wire), so an anomaly in one microservice is visible immediately, not found in a post-incident review weeks after the data already left the building.
Where Perimeter Security Stops, and Kubernetes Risk Begins
The difference between a perimeter WAF and a Kubernetes-native WAAP isn’t just deployment location. It’s visibility. One sees traffic entering the cluster; the other follows activity after workloads start communicating with each other. That distinction determines whether lateral movement, API abuse, and slow exfiltration are detected or remain invisible.
For cloud-native environments, the question is no longer whether a perimeter WAF is useful. It is. The real question is whether it’s the only thing watching your applications. In Kubernetes, most meaningful attacker activity happens after the perimeter has already been crossed.
Six Questions Every Security Team Should Ask Before Choosing a Kubernetes WAAP Solution
- Does it inspect internal traffic at Layer 7, not just ingress?
- Are shadow and deprecated APIs discovered automatically?
- Does each microservice get its own behavioral baseline?
- Can it detect cross-namespace lateral movement?
- Does it catch token replay even when credentials look valid?
- Is there one dashboard correlating WAF, API, and east-west signals?
Security and platform engineering should answer these together, decisions made in isolation tend to either under-protect the cluster or break deployment velocity.
- Close the East-West Blind Spot. Start Now.
Can your security team see every service-to-service call happening inside your cluster right now? If you hesitate, your east-west traffic is already an unmonitored attack surface , and a perimeter-only WAF will never show it to you. Begin evaluating runtime, Kubernetes-native WAAP protection today, before a quietly compromised pod becomes tomorrow’s breach disclosure.
Frequently Asked Questions (FAQ)
1. Is a Kubernetes WAAP the same as a Kubernetes WAF?
No. A Kubernetes WAF typically protects only north-south traffic at the ingress layer using signature-based rules. A Kubernetes WAAP is broader, it adds continuous API discovery, behavioral detection, bot mitigation, and DDoS protection, extending coverage to east-west traffic between microservices.
2. Why do attacks inside a Kubernetes cluster bypass traditional WAFs?
Traditional WAFs sit at the network perimeter and only inspect traffic entering the cluster. Once an attacker compromises a single container, lateral movement, API enumeration, token replay, privilege escalation, slow exfiltration, happens over internal east-west traffic, which a perimeter-only WAF was never positioned to monitor.
3. Can BOLA and token replay attacks be detected if the requests look completely valid?
Yes, but only through behavioral detection. These attacks use authenticated, schema-compliant requests, so signature-based tools see nothing to flag. Per-service behavioral baselines that learn normal access patterns can catch the deviation even when each individual request looks technically valid.
4. If I already have Kubernetes network policies and a service mesh, do I still need a WAAP?
Yes, they solve different problems. Network policies and a service mesh like Istio or Linkerd control which services are allowed to talk to each other and encrypt that traffic with mTLS, but neither inspects the content of a request at Layer 7. Neither can tell the difference between a normal API call and a BOLA exploit, a token replay, or a scraping bot using a valid session, that’s the layer a WAAP adds on top.
