Tracing Lateral Movement in Kubernetes: Detecting Cross-Namespace Attacks with Network Policies and Audit Logs

Kubernetes makes it easy to deploy microservices at scale but that same flexibility can create invisible paths for lateral movement. If a single pod is compromised, attackers may move laterally to other namespaces, escalate privileges, or access sensitive workloads.

This deep dive walks through how lateral movement happens inside a Kubernetes cluster, which network policy misconfigurations allow it, and how to detect it using Kubernetes audit logs and other signals.

We'll explore both prevention and detection because in Kubernetes, securing one pod isn't enough if the rest of the cluster is still exposed.

Real-World Example: Pod-to-Pod Compromise Across Namespaces

Scenario:

1. A vulnerable container in the dev namespace is compromised via a web vulnerability.
2. The attacker gains a shell and discovers the pod has open egress to the cluster network.
3. The pod initiates connections to internal services in the staging namespace (e.g., internal APIs, Redis, or message brokers).
4. One of these internal services is running with elevated RBAC permissions.
5. The attacker pivots and uses that pod to access secrets or escalate cluster privileges.

This kind of attack often goes undetected unless:

• Network policies are enforced and scoped correctly
• Audit logs capture unexpected access patterns
• Egress traffic is logged and analysed

Note: In practice, this type of pivot requires the attacker to access service account tokens (via volume mounts or local credentials), exploit vulnerabilities in downstream services, or abuse overly permissive API access.

This example shows how a small misstep in one namespace can become a cluster-wide breach. The next step is understanding what misconfigurations make this movement possible.

Network Policy Misconfigurations That Enable Lateral Movement

Kubernetes network policies control how pods communicate but they're not enforced by default and require a CNI plugin that supports them (e.g., Calico, Cilium). Common misconfigurations include:

1. No Network Policies at All

• Default behaviour allows all pods to communicate freely

2. Policies Only Control Ingress

• Egress is left open, allowing outbound traffic to sensitive services

3. Too Broad Namespace Access

• namespaceSelector: {} or missing selectors allow traffic cluster-wide

4. DNS Traffic Allowed Without Restriction

• Attackers can use internal DNS resolution to enumerate and target other services

What to Do:

• Define deny-by-default egress and ingress policies
• Use podSelector and namespaceSelector together for tight scoping
• Apply policies per environment: dev, staging, production

Understanding and applying network segmentation correctly is the first step but enforcement alone isn’t enough. You need observability to catch what slips through.

Tools for Enforcing and Auditing Network Policies

• Calico: Offers detailed network policy enforcement and flow logs
• Cilium: eBPF-powered networking with visibility and identity-aware rules
• Kubeaudit: Static analysis of Kubernetes configurations, including network policies
• np-validator: Validates policy effectiveness in CI/CD pipelines

Note: Some features such as DNS visibility or flow logging may require enabling enterprise components in tools like Calico or Cilium.

Even with strong enforcement in place, missteps or overlooked configurations can still create risk. That’s why visibility, particularly at the API level, is critical.

Tracing Lateral Movement Using Kubernetes Audit Logs

Kubernetes audit logs record every interaction with the API server. While not equivalent to packet capture, they reveal important signals of lateral movement.

What to Look For:
1. Unexpected Pod Exec Events

Pods in one namespace initiating exec sessions in another may indicate an attacker moving laterally.

2. Service Account Token Use Across Namespaces

If a token issued in dev is used to call the API server and modify resources in prod, flag it

3. Secret Access Attempts

Low-privilege service accounts trying to read secrets outside their scope can reveal compromise.

PUT IN CODE BOX ‍

"verb": "get",

"objectRef": { "resource": "secrets" },

"user": { "username": "system:serviceaccount:staging:api-service" }

‍Implementation Tips

• Enable audit logging at Metadata or RequestResponse for high-risk namespaces.
• Forward logs to a SIEM or aggregator for correlation.
• Tag logs with namespace, user, and service account metadata.

Note: Audit logs only show API server activity, combine them with network flow monitoring for complete coverage.

Additional Detection Signals

• Sudden spikes in pod egress traffic.
• Cross-namespace API calls by unexpected service accounts.
• Use of kubectl exec, port-forward, or attach from unauthorised accounts.
• DNS queries from low-privilege pods to internal services.

Final Checklist: Defending Against Lateral Movement in K8s

Conclusion

Lateral movement in Kubernetes isn’t hypothetical, it’s a common second step after initial compromise. Without strong segmentation and visibility, attackers can pivot across namespaces unnoticed.

By combining strict network policies, detailed audit logging, and alerts on cross-namespace behaviours, you can detect and block lateral movement early, before it turns into a full-cluster breach.

‍