Published: October 28, 2026 · 8 min read

Kubernetes Network Policy Explained Simply

• By default the cluster network is flat — any Pod reaches any Pod.
• A NetworkPolicy is a firewall rule for Pods.
• It is namespaced — one per namespace.
• Ingress is traffic coming in. Egress is traffic going out.
• The moment a policy selects a Pod, that direction becomes deny by default.
• Policies only add allowed traffic. There is no deny rule.
• Blocked traffic times out, it is never refused.
• It needs a CNI plugin that supports it, or nothing happens.

The Problem

A namespace groups your objects. It does not wall them off.

Your frontend, backend, database and metrics Pods can all reach each other. So can Pods in other namespaces.

If one Pod is compromised, your database is one curl away.

Ingress and Egress

Always read the direction from the Pod the policy selects.

Most policies only use Ingress. That alone fixes the biggest problem.

Your First Policy

Only the frontend may reach the backend, and only on port 8080.

# netpol.yaml  -  only the frontend may reach the backend

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-allow-frontend
  namespace: hotel
spec:
  podSelector:                    # WHICH Pods this policy protects
    matchLabels:
      app: backend
  policyTypes:
    - Ingress                     # we are controlling traffic coming IN
  ingress:
    - from:
        - podSelector:            # WHO is allowed in
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080              # and on which port

Four blocks, four questions:

kubectl apply -f netpol.yaml
# networkpolicy.networking.k8s.io/backend-allow-frontend created

kubectl get networkpolicy -n hotel
# NAME                     POD-SELECTOR   AGE
# backend-allow-frontend   app=backend    10s

kubectl describe networkpolicy backend-allow-frontend -n hotel
# Spec:
#   PodSelector: app=backend
#   Allowing ingress traffic:
#     To Port: 8080/TCP
#     From:
#       PodSelector: app=frontend
#   Not affecting egress traffic
#   Policy Types: Ingress

Deny by Default

This is the rule everything else depends on.

One small policy flips a Pod from fully open to fully closed. Then you open it back up, one rule at a time.

Testing It

# from the frontend Pod - allowed
kubectl exec -it frontend-6b9f4d7c21-k8ptm -n hotel -- \
  curl -s -m 3 http://backend-svc:8080/health
# ok

# from any other Pod - blocked
kubectl exec -it metrics-7d4b9c6f85-2kq9x -n hotel -- \
  curl -s -m 3 http://backend-svc:8080/health
# curl: (28) Connection timed out after 3001 milliseconds

# blocked traffic is DROPPED, not refused
# you get a timeout, never "connection refused"

Look at the failure. It is a timeout, not connection refused.

The Three Selectors

# the three things you can put under from:

ingress:
  - from:
      # 1. Pods in the SAME namespace
      - podSelector:
          matchLabels:
            app: frontend

      # 2. every Pod in ANOTHER namespace
      - namespaceSelector:
          matchLabels:
            name: monitoring

      # 3. plain IP ranges, outside the cluster
      - ipBlock:
          cidr: 10.0.0.0/16
          except:
            - 10.0.5.0/24

One Dash Changes Everything

This trips up almost everyone, so look at it closely.

# A LIST of entries  =  OR
ingress:
  - from:
      - podSelector:
          matchLabels:
            app: frontend
      - namespaceSelector:              # a NEW list item
          matchLabels:
            name: monitoring
# allowed: frontend Pods  OR  anything in monitoring


# ONE entry with two selectors  =  AND
ingress:
  - from:
      - namespaceSelector:
          matchLabels:
            name: monitoring
        podSelector:                    # same item, no dash
          matchLabels:
            app: prometheus
# allowed: ONLY prometheus Pods inside monitoring

# the dash is the whole difference

Lock a Whole Namespace

Start by closing everything, then open what you need.

# deny-all.yaml  -  nothing may enter any Pod in this namespace

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: hotel
spec:
  podSelector: {}                 # {} means EVERY Pod in the namespace
  policyTypes:
    - Ingress
  # no ingress: block at all, so nothing is allowed in

Two details make this work:

• podSelector: {} — an empty selector matches every Pod in the namespace.
• No ingress: block at all — so nothing is allowed in.

Apply this first, then add one policy per connection you actually want.

Controlling Egress

# allow the backend to reach the database and DNS only

spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: database
      ports:
        - protocol: TCP
          port: 5432

    - to:                         # DNS, or every name lookup fails
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

It Needs the Right CNI

Kubernetes accepts the NetworkPolicy object. It does not enforce it.

Your network plugin does that work, and not all of them can.

kubectl get pods -n kube-system | grep -iE 'calico|cilium|weave'

Network Policy Commands

# look
kubectl get networkpolicy -n <namespace>
kubectl get netpol -A                        # short form, every namespace
kubectl describe netpol <name> -n <namespace>

# which Pods does a policy actually select?
kubectl get pods -n <namespace> -l app=backend

# test from inside a Pod
kubectl exec -it <pod> -n <namespace> -- curl -m 3 http://<service>:<port>

# is your CNI even enforcing policies?
kubectl get pods -n kube-system | grep -iE 'calico|cilium|weave'

# delete
kubectl delete netpol <name> -n <namespace>

What's Next

A NetworkPolicy turns a flat, open cluster into one where every connection is on purpose. Start with a default deny on one namespace, then open the connections you actually need. The official NetworkPolicy page (opens in a new tab) and the recipes collection (opens in a new tab) have ready made examples.

← Back to ConfigMap and Secret

Continue to EKS Storage Setup →

Frequently Asked Questions

What is a Network Policy in Kubernetes?

A NetworkPolicy is a firewall rule for Pods. By default every Pod in a cluster can reach every other Pod, with nothing in the way. A NetworkPolicy lets you say which Pods may talk to which, on which ports. It is a namespaced object, so you write one for each namespace you want to protect.

Can all pods talk to each other in Kubernetes by default?

Yes. A fresh cluster has a flat network. Any Pod can reach any other Pod in any namespace, and nothing stops it. There is no firewall between Pods until you create a NetworkPolicy. That is why one compromised Pod can reach your database straight away.

What is the difference between ingress and egress in a Network Policy?

Read both from the Pod the policy selects. Ingress is traffic coming in to that Pod, and you list who is allowed under from. Egress is traffic leaving that Pod, and you list where it may go under to. Most policies only use ingress. Add egress when you also need to control what the Pod is allowed to call.

What happens when a Network Policy selects a Pod?

That direction becomes deny by default for it. Before any policy selects a Pod, everything is allowed. The moment one policy selects it and lists Ingress in policyTypes, everything incoming is blocked. Only what the policy allows gets through. Nothing changes for egress unless you list Egress too.

What is podSelector in a Kubernetes Network Policy?

podSelector appears in two places and means something different in each. At the top of the spec it chooses which Pods the policy protects. Inside a from or to block it chooses which Pods are allowed. An empty podSelector written as a pair of braces means every Pod in the namespace.

How do you create a default deny Network Policy?

Write a policy whose podSelector is an empty pair of braces. List Ingress under policyTypes, and give it no ingress rules at all. The empty selector matches every Pod in the namespace, and with no rules nothing is allowed in. You then add a separate policy for each connection you want to permit.

Why is my Kubernetes Network Policy not working?

Almost always the CNI plugin. Kubernetes accepts the NetworkPolicy object but does not enforce it itself. Your network plugin has to implement it. Calico, Cilium and Weave do. Plain Flannel does not, so the policy applies cleanly and changes nothing. Check which plugin is running in kube-system before you debug anything else.

Does a Network Policy block traffic or refuse it?

It drops the packets silently. The caller gets a timeout, never a connection refused error. This matters when you are debugging, because a timeout looks exactly like a crashed Pod or a wrong address. If a connection that used to work now hangs, check for a NetworkPolicy first.