Kubernetes Network Policies: Practical Pod Security

By default, all pods in a Kubernetes cluster can communicate with all other pods. This flat network model works during development but creates security risks in production. Without segmentation, a compromised pod may be able to reach other workloads, including databases or in-cluster secrets services. NetworkPolicies can reduce that reach when the CNI enforces them and the selectors cover the relevant traffic.

Kubernetes Network Policies let you restrict pod-to-pod communication based on labels, namespaces, and ports. This microsegmentation approach implements zero-trust networking inside the cluster.

This post covers how Network Policies work, default deny patterns, and practical policy configurations.

For Kubernetes basics, see the Kubernetes fundamentals post. For services and Ingress, see the Services and Networking post.

Introduction

When Network Policies make sense

Multi-tenant clusters often benefit from them. If you do not control what runs in every namespace, a compromised workload may be able to reach a database or another service unless policy and CNI configuration restrict the path.

Compliance programs may call for network segmentation, and NetworkPolicies can contribute to that control. They do not satisfy a framework requirement on their own; map the policy design to the applicable control and validate it with your compliance team.

Network segmentation can limit a pod’s reach, but it does not create zero trust by itself. Restrict the specific paths to databases, caches, and secrets services, and verify both the selectors and the CNI enforcement.

Here is where policies actually earn their keep:

Scenario	Risk without policies	What a policy does
Shared cluster with multiple teams	Team A’s pod reads Team B’s database	Allow only explicitly permitted pod-to-pod traffic
Sensitive workloads (payments, PII)	Any compromised pod reaches the data layer	Isolate the sensitive namespace from all other workloads
Third-party or contractor-deployed apps	Untrusted code reaches internal services	Lock down ingress and egress at the namespace level
Production vs. development co-location	Development bugs affect production services	Apply production-grade policies to production namespaces only

In a shared cluster, a policy such as allow-api-to-db can restrict which selected pods reach the database. Check the policy’s pod and namespace selectors: a new pod with matching labels may also be allowed, and another applicable policy can widen the allowed traffic.

NetworkPolicies can provide evidence of workload-level segmentation, but they are only one part of a compliance control. Whether they apply to a particular PCI DSS, SOC 2, or HIPAA requirement depends on the system scope and the organization’s control mapping. Pair policy manifests with change records, enforcement evidence from the CNI, and the network controls outside the cluster.

Without a policy that isolates the database, a frontend pod may be able to connect to it directly on port 5432. A database ingress policy can allow the API pods and block that direct path, provided the CNI enforces the rule and the selectors match. This reduces one route for lateral movement; it does not prevent every path to the database.

When to skip them

A single-tenant cluster with tightly controlled deployments may have lower risk, but trust in the deployers does not remove compromised dependencies or accidental exposure. Weigh the isolation benefit against the policy operations and debugging burden.

External segmentation can be enough. Cloud VPC security groups that isolate your Kubernetes nodes from each other and from other services provide some protection. Network policies then add defense in depth.

Early development is not the time. The operational overhead of debugging why your service cannot reach its database when you forgot to allow port 5432 slows down iteration.

Traffic Filtering Flow

flowchart TD
    P1[Pod A<br/>app=web-frontend] -->|Egress| NP1{Network Policy<br/>on Pod A}
    NP1 -->|Allow to<br/>DNS| DNS[CoreDNS<br/>:53]
    NP1 -->|Allow to<br/>:8080| P2[Pod B<br/>app=api-backend]
    NP1 -->|Block all<br/>else| X[Dropped]
    P2 -->|Ingress| NP2{Network Policy<br/>on Pod B}
    NP2 -->|Allow from<br/>web-frontend| P1
    NP2 -->|Block all<br/>else| X2[Dropped]

NetworkPolicies select pods and isolate ingress or egress separately. Where the network plugin enforces the API, traffic in an isolated direction is generally limited to the union of matching allow rules, with exceptions such as traffic from a pod’s node described by the API.

How Network Policies Work

A Network Policy is a namespaced resource that selects pods and defines ingress and egress rules. The network plugin or CNI implementation enforces the rules. The Kubernetes API accepts the resource even when the installed plugin does not enforce NetworkPolicy, so verify support in the cluster.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-backend-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-backend
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: web-frontend
      ports:
        - protocol: TCP
          port: 8080
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: postgres
      ports:
        - protocol: TCP
          port: 5432

This policy allows the api-backend pod to receive traffic from matching web-frontend pods on port 8080 and send traffic to matching postgres pods on port 5432. The egress selector is namespace-local because the policy and both pod selectors are in production.

Policy evaluation order

Network Policies are additive. If multiple policies select the same pod, the union of all allowed traffic is permitted. This means you must carefully design policies to avoid unintended exposure.

Standard Kubernetes NetworkPolicy has no priority or explicit deny rule: allowed traffic is the union of all matching policies. Calico’s native policy API has an order field and explicit actions, but that behavior belongs to Calico resources, not the standard API:

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
spec:
  order: 100

In Calico-native policies, lower order values are evaluated first. Check the Calico documentation for how those resources interact with standard NetworkPolicy in your version.

Default Deny All Ingress and Egress

Start with a default deny policy for each namespace, then explicitly allow required traffic. This follows the principle of least privilege.

Default deny ingress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress

podSelector: {} selects all pods in the namespace. With no ingress rules, all incoming traffic is blocked.

Default deny egress

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Egress

This blocks all outgoing traffic until you add policies allowing specific destinations.

Combined default deny

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Apply this before deploying any application, then add allow policies as you deploy services.

Allowing Specific Traffic with Pod Selectors

After setting default deny, allow specific traffic patterns:

Web frontend to API backend

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: web-frontend
      ports:
        - protocol: TCP
          port: 8080

API backend to database

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api-backend
      ports:
        - protocol: TCP
          port: 5432

Application layer filtering

For more complex rules, use namespaceSelector to allow traffic from specific namespaces:

ingress:
  - from:
      - namespaceSelector:
          matchLabels:
            name: frontend
        podSelector:
          matchLabels:
            app: web-frontend
      - namespaceSelector:
          matchLabels:
            name: monitoring
        podSelector:
          matchLabels:
            app: prometheus

This allows traffic from frontend namespace pods labeled app: web-frontend and from monitoring namespace pods labeled app: prometheus.

Namespace-Level Policies

Apply policies at the namespace level to protect entire namespaces or enforce compliance requirements:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: production-isolation
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: production
        - namespaceSelector:
            matchLabels:
              name: ingress-nginx

This allows traffic only from pods in the production namespace or from the ingress-nginx namespace.

Isolating system namespaces

System components are not deployed uniformly. CoreDNS commonly runs in kube-system, while the API server may run outside the pod network and kube-proxy may be replaced by the CNI. A blanket policy on this namespace can disrupt node-originated, control-plane, or monitoring traffic, and standard NetworkPolicy behavior for hostNetwork pods is undefined. Inventory the actual endpoints and test the rules with your CNI before applying isolation.

This example allows ingress from pods in kube-system; it is only a starting point and may not preserve node or control-plane traffic in your cluster:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-system-namespaces
  namespace: kube-system
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system

This restricts matching pod-network traffic from application namespaces. It does not guarantee protection for host-network components or control-plane endpoints, and it does not restrict egress from system pods. Verify the effective paths in the cluster before relying on it.

Some CNI agents run as privileged pods in kube-system. A compromise or misconfiguration of the enforcement component can undermine policy guarantees. Restrict who can change CNI resources or deploy into the system namespace, and monitor the CNI agent as privileged infrastructure.

For monitoring, logging, or ingress namespaces, inventory dependencies before isolating them. Apply narrowly scoped policies to the selected workloads, then test scrape, control-plane, and node-originated paths rather than assuming a namespace-wide default deny is safe.

DNS Egress Rules

When egress is isolated, pods need an allowed path to their configured resolver. CoreDNS often runs in kube-system on port 53 over UDP and TCP, but NodeLocal DNSCache or other cluster layouts can change the destination. Confirm the resolver path before applying this example:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    # Allow DNS
    - ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
      to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
    # Allow other necessary egress (example)
    - ports:
        - protocol: TCP
          port: 443
      to:
        - namespaceSelector: {}

The first rule targets pods selected in kube-system; confirm that this matches the cluster DNS path used by your CNI and service implementation. The second rule is intentionally broad: it permits TCP 443 to pods in every namespace, not arbitrary internet destinations. Standard NetworkPolicy has no FQDN selector; use specific ipBlock ranges or a CNI/cloud egress feature for external endpoints, and avoid stale or overly broad IP ranges.

CNI Providers and Policy Enforcement

Network Policy support varies by CNI provider. Not all providers implement all policy features:

Implementation	Standard NetworkPolicy enforcement	Extensions and caveats
Calico	Supports standard ingress and egress policies when configured for policy enforcement	Calico-native policies add ordering, explicit actions, and other features; these are not part of the Kubernetes API.
Cilium	Supports standard ingress and egress policies	Cilium policy resources can add L7 rules; verify proxy and policy configuration for the deployed version.
Amazon VPC CNI for EKS	Supported in eligible configurations with VPC CNI 1.21+	AWS documents platform constraints, including EC2 Linux nodes and kernel requirements; check the current EKS support matrix.
Flannel	Does not enforce NetworkPolicy by itself	Pair it with a policy-enforcing plugin if policies are required.
Weave Net	Historical implementation	The upstream repository was archived in June 2024; do not treat it as a current maintained choice.

Calico NetworkPolicy

Calico extends standard NetworkPolicy with additional features:

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: api-isolation
  namespace: production
spec:
  selector: app == 'api-backend'
  types:
    - Ingress
    - Egress
  ingress:
    - action: Allow
      source:
        selector: app == 'web-frontend'
      destination:
        ports:
          - 8080
    - action: Deny
  egress:
    - action: Allow
      destination:
        selector: app == 'postgres'
        ports:
          - 5432
    - action: Allow
      protocol: TCP
      destination:
        ports:
          - 53

Calico’s explicit action: Deny rules make policy intent clearer.

Cilium NetworkPolicy

Cilium uses eBPF for enforcement and supports L7 policy extensions when their proxy configuration is enabled:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: api-backend
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: web-frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP

Cilium policy extensions can filter supported protocols such as HTTP, Kafka, and DNS at L7 when the required proxy and policy configuration are enabled.

Testing Network Policies

Verify your policies work correctly with connectivity tests:

Using kubectl to test connectivity

Use a test pod or exec into an existing workload to check a specific network path. A failed request does not identify the policy that blocked it; combine the probe with service health, DNS, endpoint, and CNI flow checks.

Test ingress by creating a busybox pod and reaching the target:

kubectl run --rm -i test-pod \
  --image=busybox \
  --restart=Never \
  --command -- wget -q -O- http://api-backend:8080/health

A successful request shows that this path worked from the test pod. Ensure the test pod has the same namespace and labels as the source workload you intend to validate. A timeout alone does not prove a NetworkPolicy drop: the service may be unhealthy, the port may be wrong, or routing/DNS may be failing. Use a client that speaks the target protocol; for HTTPS, use curl with normal certificate validation when possible.

Test egress the other way around — exec into the source pod and reach outward:

kubectl exec -it api-backend-pod -- sh -c "nc -vz postgres 5432"

If nc is installed and the connection fails, check both the source egress and destination ingress policies, then inspect DNS, service endpoints, and CNI flow logs. A TCP probe confirms reachability only; use a PostgreSQL client such as pg_isready to check the database protocol.

Before assuming a policy is at fault when a test fails, check three things: the pod is actually running (kubectl get pods), the service name resolves (kubectl exec test-pod -- nslookup api-backend), and the port in your policy matches the service port. Port mismatches masquerade as policy failures more often than actual policy misconfigurations.

For repeated testing, keep a debug pod around instead of creating a new one every time:

kubectl run debug-pod --image=busybox --restart=Never -- sleep 3600
kubectl exec -it debug-pod -- sh

You get a persistent shell with the same network properties as your application pods, without the overhead of recreating a throwaway container each time.

Using a policy visualizer

Cilium Hubble and Calico’s policy tooling can help visualize flows or assess policy changes, depending on the product and edition. Treat visualizers as aids: verify the effective rules against live flow data and the CNI configuration, since a diagram alone does not prove enforcement.

You will notice the value when you have more than five policies across multiple namespaces. Reading YAML files, it is easy to miss an allow rule buried in a large policy. A picture shows you the whole topology at once: which pods reach which services, where default-deny is active, and where DNS exceptions exist. During security audits, this helps confirm no unexpected exposure paths exist between workloads.

If you do not have commercial tooling, kubectl get networkpolicy --all-namespaces lists all policies fast, and kubectl describe on individual policies shows the full rule set. Pair that with a topology diagram of your services and you can trace paths manually. Incident response is where this really pays off — you can quickly confirm whether a policy change caused an outage.

Production Failure Scenarios

Common Policy Failures

Policy Blocking All Traffic

A default-deny accidentally applied to the wrong namespace, or an overly broad rule that blocks your application’s actual dependencies. The result is sudden outage with no obvious cause in application logs.

Test in staging first. Apply to production during low-traffic windows. Have a rollback plan.

DNS Resolution Fails After Default Deny Egress

This is the most common mistake. Default deny goes in, DNS stops working, pods cannot resolve service names or reach each other.

DNS often uses port 53, but the resolver path varies by cluster. Identify and allow that path before applying default-deny egress to production workloads.

CNI Does Not Support Your Policy Features

Flannel alone does not enforce Kubernetes NetworkPolicy. Feature support in other implementations depends on plugin version and configuration, and vendor extensions are not interchangeable with the standard API. Weave Net’s upstream repository is archived, so do not choose it for a new production deployment. Check the current CNI documentation and test enforcement before relying on a feature.

Provider and Compliance Considerations

CNI Provider Trade-off Comparison

Implementation	What to verify before choosing
Calico	Standard policy enforcement is available when configured; Calico-native policy features use a separate API.
Cilium	Standard policies are supported; L7 enforcement requires Cilium policy resources and the relevant proxy configuration.
Amazon VPC CNI for EKS	NetworkPolicy support requires supported plugin/platform versions and applies only to eligible node configurations.
Flannel	Does not enforce NetworkPolicy by itself.
Weave Net	Archived upstream project; unsuitable as a new maintained production dependency.

Choose based on the cluster platform, required policy features, support lifecycle, and the team’s ability to operate the implementation. Validate the exact version and configuration rather than relying on a generic “full” or “partial” label.

Compliance Checklist

NetworkPolicies can contribute to workload segmentation controls. They do not, by themselves, establish compliance with PCI DSS, SOC 2, or another framework; map them to the controls in scope and retain evidence that the cluster enforces the intended rules:

# Default deny for PCI-DSS scoped namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: cardholder-data
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Key checklist items:

• Default deny applied to the in-scope workloads, with documented exceptions
• CNI policy enforcement confirmed for the cluster and node types in scope
• Resolver egress allowed on the ports and destinations used by the cluster
• Payment-data workloads isolated from unrelated workloads and external paths
• Policy, CNI, and cloud network changes recorded and reviewable
• Policy effectiveness reviewed on a defined schedule

Advanced L7 Policies

L7 Policy Examples with Cilium

Cilium supports HTTP-level network policies for fine-grained L7 control:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-access-control
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: api-backend
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: GET
                path: "/api/v1/.*"
              - method: POST
                path: "/api/v1/users"
              - method: GET
                path: "/api/v1/health"

This policy allows the frontend to reach the API on port 8080 for the listed methods and paths. Requests that do not match those HTTP rules are not allowed by this policy.

# Allow GET requests to the API for a microservice
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: deny-admin-paths
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: internal-api
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: web-frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: GET
                path: "/api/v1/.*"
              # Implicitly deny POST, PUT, DELETE, etc.

Common Pitfalls / Anti-Patterns

Blanket podSelector: {}

podSelector: {} selects every pod in the policy’s namespace. If that namespace contains system workloads, applying a restrictive policy to all of them can interrupt required traffic.

Always scope policies to your application pods specifically.

A restrictive policy can interrupt system dependencies such as cluster DNS or monitoring when those endpoints are selected by the policy. Components and resolver paths vary by cluster, so inventory the actual endpoints and check CNI flow data instead of assuming all system traffic follows the same pod-network path.

The dangerous pattern looks like this:

# Applies to system pods too
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    # Intended only for application pods
    - from:
        - podSelector:
            matchLabels:
              app: web-frontend

Scope the selector to your application workloads only. Use label prefixes like app:, component:, or tier: to separate system pods from application pods. If you need a default-deny in a namespace that also runs system components, apply the default-deny to application pods only and handle system namespace isolation separately with explicit allow rules for the system components. Run kubectl get pods --show-labels against the target namespace before applying any broad selector.

Ingress Only

Focusing only on ingress leaves egress wide open. A compromised pod can still exfiltrate data or call out to malicious servers.

Define both ingress and egress rules. Include DNS.

Ingress-only thinking is tempting because the attack surface feels obvious: someone calling your API, someone reaching your web server. But a pod with only ingress restrictions behaves like a server with an open outbound firewall. If an attacker compromises your API pod, they can use it as a launchpad — reach command-and-control servers, mine cryptocurrency on external infrastructure, scan internal services for further exploitation.

Egress filtering is where the real value of defense-in-depth lives. A compromised web-frontend pod should not reach your database directly. It reaches the API on the API’s ingress port. The database then has its own ingress rules. Even if one pod is compromised, lateral movement is cut off.

To implement proper egress control, start with default-deny egress on every namespace with untrusted or multi-tenant workloads. Then add explicit egress rules for DNS (port 53 to kube-system), external APIs your application calls, and the specific backend services each tier needs. Avoid allowing all egress to internal networks — scope it to the exact pods and ports each source requires.

Forgetting DNS Egress

Default deny plus no DNS rule means no service discovery works. Your pods cannot resolve .cluster.local addresses.

If the workload uses DNS, include its configured resolver path in the egress design and test name resolution before rollout.

When a pod resolves api-backend.production.svc.cluster.local, its query goes to the resolver configured for that pod. In many clusters this is CoreDNS in kube-system; in others, a node-local cache forwards the query. If egress policy blocks that path, service discovery and any health checks that resolve service names can fail.

When the resolver is a pod, a namespace selector is usually more stable than hardcoded CoreDNS pod IPs. Adapt the selector and ports to the actual resolver path; DNS uses both UDP and TCP port 53:

egress:
  - ports:
      - protocol: UDP
        port: 53
      - protocol: TCP
        port: 53
    to:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: kube-system

Include the resolver allowance in each policy that isolates egress; NetworkPolicies are namespaced, so a policy in one namespace does not automatically apply to workloads in another.

Observability Checklist

NetworkPolicy drops can look like application timeouts, so monitor the enforcement layer as well as the service:

• Confirm the installed CNI reports NetworkPolicy enforcement as healthy.
• Track denied and allowed flow counts by namespace, source, destination, and port where the CNI exposes them.
• Alert on sudden increases in denied traffic after policy changes, while avoiding alerts on expected probes.
• Check DNS success and application dependency health after enabling or changing egress rules.
• Keep policy changes and connectivity-test results tied to the same deployment or change record.
• Verify that monitoring and CNI control-plane traffic remains allowed after namespace isolation.

Quick Recap Checklist

• Confirm the cluster’s CNI plugin enforces Kubernetes Network Policies.
• Apply default-deny ingress and egress to the workloads that need isolation.
• Allow DNS over both UDP and TCP on port 53 before restricting egress.
• Check that pod and namespace selectors match the intended labels.
• Test both allowed and blocked connections in staging before rollout.

Interview Questions

Further Reading

• Kubernetes Network Policies documentation - Official docs covering policy syntax and examples
• Calico Network Policy - Extended policy features for Calico deployments
• Cilium Network Policy - L7 HTTP-aware policies and eBPF-based enforcement
• Kubernetes Pod Security Standards - Admission controls that complement network segmentation
• Amazon EKS Network Policies - Current AWS VPC CNI policy support and platform constraints

Conclusion

• Default deny policies applied to untrusted namespaces first
• Only required traffic explicitly allowed per application
• DNS egress allowed (port 53 to cluster DNS service)
• Policies tested in staging before production
• CNI plugin capabilities verified for required features
• Policy visualization used to check for unintended exposure
• Network Policies combined with RBAC and Secrets encryption
• Policy rationale documented and reviewed during security audits

For more on Kubernetes networking, see the Services and Networking post.