Missing Kubernetes Network Policies

Without NetworkPolicy resources, every pod in the cluster can communicate with every other pod on any port, enabling unrestricted lateral movement after a single pod is compromised.

How It Works

By default, Kubernetes allows all ingress and egress traffic between all pods in the cluster regardless of namespace. This means a compromised frontend pod can directly connect to your database pod, a redis pod in another namespace, or the Kubernetes API server. NetworkPolicy resources act as firewall rules that restrict which pods can talk to each other. Without them, an attacker who gains remote code execution in any single pod can scan the internal network, access databases, steal secrets from other services, and pivot across the entire cluster. Most managed Kubernetes services support NetworkPolicy but do not create any by default.

Vulnerable Code

# BAD: no NetworkPolicy exists -- all pods can talk to all pods
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 2
  selector:
    matchLabels:
      app: frontend
  template:
    spec:
      containers:
        - name: frontend
          image: frontend:latest
          ports:
            - containerPort: 3000
# No NetworkPolicy -> frontend can reach database, redis, etc.

Secure Code

# GOOD: default-deny policy + explicit allow rules
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}  # applies to ALL pods in namespace
  policyTypes: ["Ingress", "Egress"]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-api
spec:
  podSelector:
    matchLabels:
      app: api
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - port: 8080

Real-World Example

In the 2020 SolarWinds breach, lateral movement within internal networks was a key attack vector. While not Kubernetes-specific, the same principle applies: the Sunburst malware moved freely between systems because there was no network segmentation. In Kubernetes environments without NetworkPolicies, a compromised container can similarly reach any service, database, or management API within the cluster.

How to Prevent It

Apply a default-deny NetworkPolicy in every namespace that blocks all ingress and egress traffic by default
Create explicit allow-list NetworkPolicy resources for each legitimate communication path between services
Use a CNI plugin that supports NetworkPolicy enforcement such as Calico, Cilium, or Weave Net
Audit network policies regularly with tools like kubectl-who-can and network policy visualizers

Affected Technologies

TerraformKubernetesDocker

Data Hogo detects this vulnerability automatically.

Scan Your Repo Free

Related Vulnerabilities

Terraform State Exposed

critical

Your terraform.tfstate file is committed to your repository or stored in an unencrypted, publicly accessible location — it contains every secret and resource ID in your infrastructure.

CWE-312OWASP A02:2021

Terraform Provider Credentials Hardcoded

critical

AWS, GCP, or Azure credentials are hardcoded in your .tf files instead of using environment variables or instance roles, committing cloud access keys to version control.

CWE-798OWASP A02:2021

Kubernetes Privileged Container

high

Your Kubernetes pod runs with securityContext.privileged: true, giving the container full access to the host kernel and effectively bypassing container isolation.

CWE-269OWASP A05:2021

Kubernetes Default Service Account

medium

Pods running with the default service account inherit cluster-level RBAC permissions that are often far more powerful than the workload needs, enabling lateral movement if the pod is compromised.

CWE-269OWASP A01:2021