A Practical Guide to Kubernetes Network Policies

What are Kubernetes Network Policies?

By default, Kubernetes has a "flat" network where all pods can communicate freely. This is a significant security risk. A single compromised pod could potentially attack any other service in the cluster. Network Policies are the native Kubernetes resource for controlling traffic flow at the IP address or port level (OSI Layer 3/4), acting as a firewall for your pods.

The Building Blocks of Network Policies

Writing Basic Policies: The Default Deny Model

The most effective security posture is to deny all traffic by default and then explicitly allow only what is necessary. This is the foundation of a zero-trust network.

1. Default Deny All Ingress Traffic

This is the foundational policy for any secure namespace. It selects all pods in its namespace and specifies that no ingress traffic is allowed.

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

2. Allowing Ingress from a Specific Namespace

Once you have a default deny, you can layer on policies. This policy allows pods with the label `app: api` to receive traffic from any pod in the namespace that is labeled `name: monitoring`.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-from-monitoring
  namespace: my-app
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: monitoring

3. Allowing Ingress based on Pod Selector

This is the most common pattern. It allows pods with `app: database` to receive traffic on port 5432 from pods with the label `app: api` within the same namespace.

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

Advanced Ingress & Egress Rules

Real-world applications require more complex rules, such as controlling outbound traffic and combining multiple rulesets.

1. Controlling Egress (A Common Pitfall: DNS)

When you apply egress policies, you must explicitly allow all necessary outbound traffic, including DNS. This policy allows `app: api` pods to send DNS queries and connect to external services on port 443.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-egress
  namespace: my-app
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Egress
  egress:
  # Allow DNS traffic to pods labeled k8s-app: kube-dns
  - to:
    - podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - port: 53
      protocol: UDP
    - port: 53
      protocol: TCP
  # Allow other external traffic over HTTPS
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.0.0.0/8 # Exclude internal cluster CIDR
    ports:
    - port: 443
      protocol: TCP

2. Combining Ingress Rules (OR Logic)

You can combine multiple `from` clauses in an ingress rule. Traffic is allowed if it matches *any* of the clauses. This policy allows the `database` pod to receive traffic from the `api` pods OR the `backup-job` pods.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-db-access-combined
  namespace: my-app
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
  - Ingress
  ingress:
  - from:
    # Rule 1: Allow from 'api' pods
    - podSelector:
        matchLabels:
          app: api
    # Rule 2: Allow from 'backup' pods
    - podSelector:
        matchLabels:
          job: backup
    ports:
    - protocol: TCP
      port: 5432

Best Practices for Policy Management

Troubleshooting Common Issues

Getting Started Step-by-Step