Phase 04 · Operations & SecurityChapter 21 of 33

Phase 04Read time ~16 minDifficulty intermediate

Kubernetes Network Policies 🌐🔐

Warrior, you've reached a very important production-security chapter.

In this chapter (78 sections)

We learned in Chapter 11 that Kubernetes networking generally allows Pods to communicate across the cluster.

That's powerful—but it can also be dangerous.

Imagine:

Frontend Pod
Backend Pod
Worker Pod
Redis Pod
PostgreSQL Pod
Monitoring Pod

If networking is completely unrestricted, a compromised Pod may be able to attempt connections to many other workloads.

We want:

Frontend → Backend ✅
Backend → PostgreSQL ✅
Backend → Redis ✅
Worker → PostgreSQL ✅
Frontend → PostgreSQL ❌
Frontend → Redis ❌
Random Pod → PostgreSQL ❌

This is what NetworkPolicy helps us achieve.

1. What Is NetworkPolicy?#

A Kubernetes NetworkPolicy is an API object used to control network traffic to and/or from Pods.

In simple terms:

NetworkPolicy acts like a firewall for Pod network traffic.

Mental model:

              NetworkPolicy
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
       Ingress              Egress
          │                   │
     Incoming             Outgoing
      traffic              traffic

2. Ingress vs Egress#

These two words are extremely important.

Ingress#

Traffic coming into a Pod.

Client
  │
  │ incoming
  ▼
Backend Pod

That's ingress.

Egress#

Traffic leaving a Pod.

Backend Pod
    │
    │ outgoing
    ▼
PostgreSQL

That's egress.

So:

Ingress = IN
Egress  = OUT

3. NetworkPolicy Architecture#

Suppose:

Frontend
   │
   ▼
Backend
   │
   ├──────► PostgreSQL
   │
   └──────► Redis

We can define:

Frontend
   │
   │ allowed
   ▼
Backend
 
Backend
   │
   ├── allowed → PostgreSQL
   └── allowed → Redis
 
Frontend
   │
   └── blocked → PostgreSQL

This creates network segmentation.

4. Important: NetworkPolicy Isn't Implemented by the API Object Alone#

This is a very important Kubernetes concept.

Creating:

kind: NetworkPolicy

doesn't magically create firewall rules unless your cluster's networking implementation supports and enforces NetworkPolicy.

The actual enforcement is provided by the cluster's network plugin/CNI.

Examples include:

Cilium
Calico
other NetworkPolicy-capable implementations

So:

NetworkPolicy object
       ↓
CNI / networking implementation
       ↓
Actual traffic enforcement

5. Basic NetworkPolicy#

Let's start with a simple policy.

Suppose:

app=backend

We want to control incoming traffic to those Pods.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
 
metadata:
  name: backend-policy
  namespace: production
 
spec:
  podSelector:
    matchLabels:
      app: backend
 
  policyTypes:
    - Ingress
 
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend

Let's understand this carefully.

6. `podSelector`#

podSelector:
  matchLabels:
    app: backend

This selects the Pods that the policy protects.

So:

app=backend

means:

Backend Pod A
Backend Pod B
Backend Pod C

are affected.

7. `policyTypes`#

policyTypes:
  - Ingress

This means we're defining ingress behavior.

We're controlling:

Incoming traffic

to the selected Pods.

8. `from`#

from:
  - podSelector:
      matchLabels:
        app: frontend

This says:

Allow traffic from Pods labeled app=frontend.

So:

Frontend
   │
   │ ✅
   ▼
Backend

But:

Random Pod
   │
   │ ❌
   ▼
Backend

assuming the policy is otherwise isolating ingress to the selected backend Pods.

9. Port Restrictions#

We can make the policy more specific.

Suppose Node.js backend listens on:

Then:

ingress:
  - from:
      - podSelector:
          matchLabels:
            app: frontend
 
    ports:
      - protocol: TCP
        port: 3000

Now:

Frontend → Backend:3000 ✅

but a different port isn't allowed by this rule.

10. Complete Backend Ingress Policy#

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

Architecture:

                 production
                     │
          ┌──────────┴──────────┐
          ▼                     ▼
      Frontend               Backend
      app=frontend           app=backend
          │                     ▲
          │ TCP:3000            │
          └─────────────────────┘
                    ✅

11. Important Behavior: Policies Are Additive#

NetworkPolicies are generally additive.

Suppose you have:

Policy A → allow Frontend
Policy B → allow Worker

Then the resulting allowed traffic is effectively:

Frontend ✅
Worker   ✅

not:

Only Worker ❌

Adding another policy doesn't automatically override the previous one.

Think:

Policy A
   +
Policy B
   +
Policy C
   =
Combined allowed rules

12. Default-Deny#

Now we reach one of the most important production patterns:

Default deny

Instead of saying:

Allow everything
except bad traffic

you can use:

Deny by default
and explicitly allow required traffic

This is much closer to a least-privilege networking model.

13. Default-Deny Ingress#

Suppose we want to deny incoming traffic to all Pods in production unless another policy explicitly allows it.

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

Notice:

podSelector: {}

Empty selector means:

Select all Pods in the namespace.

So:

All production Pods
        │
        ▼
Default deny ingress

14. Why `podSelector: {}`?#

This:

podSelector: {}

means:

All Pods in this namespace

Whereas:

podSelector:
  matchLabels:
    app: backend

means:

Only backend Pods

15. Default-Deny Egress#

You can also deny outgoing traffic by default.

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

Now:

Production Pods
      │
      ▼
Outgoing traffic blocked
unless explicitly allowed

16. Default Deny Both#

For strong segmentation:

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

This gives you:

Ingress → denied by default
Egress  → denied by default

Then you explicitly allow what is needed.

17. The Production Pattern#

A very common conceptual model is:

Step 1
──────
Deny everything
 
        ↓
 
Step 2
──────
Allow frontend → backend
 
        ↓
 
Step 3
──────
Allow backend → database
 
        ↓
 
Step 4
──────
Allow backend → Redis
 
        ↓
 
Step 5
──────
Allow required DNS / external services

This is much safer than:

Everything → Everything

18. Namespace Selectors#

So far we've used:

podSelector:

But what if the source Pod is in another namespace?

You can use:

namespaceSelector:

Example:

from:
  - namespaceSelector:
      matchLabels:
        team: frontend

Meaning:

Allow traffic from Pods in namespaces labeled team=frontend.

19. Namespace + Pod Selector#

You can combine:

from:
  - namespaceSelector:
      matchLabels:
        environment: production
 
    podSelector:
      matchLabels:
        app: frontend

This means:

Allow Pods matching app=frontend from namespaces matching environment=production.

This is useful for larger clusters.

20. Important YAML Structure#

This can be confusing:

from:
  - namespaceSelector:
      matchLabels:
        environment: production
    podSelector:
      matchLabels:
        app: frontend

The two selectors under the same list item are combined.

Think:

Namespace must match
        AND
Pod must match

21. Multiple `from` Entries#

Consider:

from:
  - podSelector:
      matchLabels:
        app: frontend
 
  - podSelector:
      matchLabels:
        app: worker

This means:

Frontend OR Worker

can access the selected destination, subject to the specified ports.

So:

Frontend ──┐
           ├──► Backend
Worker ────┘

22. Backend + PostgreSQL Example#

Let's create a realistic application.

production
│
├── frontend
│
├── backend
│
├── postgres
│
└── redis

Desired network:

Frontend
   │
   ▼
Backend
   │
   ├──► PostgreSQL
   │
   └──► Redis

Blocked:

Frontend ──X──► PostgreSQL
Frontend ──X──► Redis
 
Random Pod ──X──► Backend
Random Pod ──X──► PostgreSQL

23. PostgreSQL Ingress Policy#

Suppose PostgreSQL listens on:

Policy:

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

Result:

Backend
   │
   │ TCP 5432
   ▼
PostgreSQL
   ✅

24. Redis Policy#

Redis normally listens on:

Policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
 
metadata:
  name: redis-policy
  namespace: production
 
spec:
  podSelector:
    matchLabels:
      app: redis
 
  policyTypes:
    - Ingress
 
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: backend
 
      ports:
        - protocol: TCP
          port: 6379

Now:

Backend ──TCP 6379──► Redis
                    ✅

25. Why Protect Databases?#

Imagine an attacker compromises:

Frontend Pod

Without network restrictions:

Frontend
   │
   ├──► Backend
   ├──► Redis
   └──► PostgreSQL

With NetworkPolicy:

Frontend
   │
   └──► Backend
          │
          ├──► Redis
          └──► PostgreSQL

This limits lateral movement.

26. NetworkPolicy Is Not Authentication#

Very important:

NetworkPolicy doesn't replace:

Database passwords
TLS
Authentication
Authorization

For example:

NetworkPolicy
→ Can this Pod establish network traffic?
 
Database authentication
→ Does this client have valid credentials?

You should use both.

27. NetworkPolicy + RBAC#

These solve different problems.

RBAC#

Controls:

Who can interact with Kubernetes API?

NetworkPolicy#

Controls:

Which Pods can communicate over the network?

So:

RBAC
→ Kubernetes API permissions
 
NetworkPolicy
→ Network traffic permissions

28. Egress Policies#

Ingress protects incoming connections.

But you also need to consider outgoing traffic.

Imagine:

Backend Pod
    │
    ├──► PostgreSQL
    ├──► Redis
    ├──► External API
    └──► Internet

Do you really want the backend to talk to everything?

Maybe not.

You could restrict egress.

29. Egress Example#

Suppose backend should access PostgreSQL:

egress:
  - to:
      - podSelector:
          matchLabels:
            app: postgres
 
    ports:
      - protocol: TCP
        port: 5432

And:

policyTypes:
  - Egress

Now:

Backend
   │
   └──► PostgreSQL:5432
           ✅

Other outbound traffic may be denied if the Pod is isolated for egress and no other policy allows it.

30. Egress Can Get Tricky#

Suppose your Node.js backend needs:

PostgreSQL
Redis
OpenAI API
Google API
DNS
Monitoring

If you enable strict default-deny egress:

Backend
  │
  ├── PostgreSQL ❌
  ├── Redis ❌
  ├── OpenAI ❌
  ├── Google ❌
  └── DNS ❌

until you explicitly allow required destinations.

This is why NetworkPolicy rollout should be tested carefully.

31. DNS Is Especially Important#

Kubernetes applications commonly use DNS:

backend-service
postgres-service
redis-service

If you block all egress and forget DNS, your application may stop resolving service names.

Typical cluster DNS traffic uses:

UDP 53
TCP 53

depending on the DNS path and implementation.

A policy may need to allow traffic to the cluster DNS service.

32. DNS Policy Concept#

A common conceptual rule looks like:

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

Exact labels and DNS architecture should be verified for your cluster.

The important idea is:

Application
    │
    ▼
DNS
    │
    ▼
Service name → Service IP

33. Why DNS Matters#

Your backend might use:

postgres-service

instead of:

10.42.1.27

If DNS is blocked:

postgres-service
       ↓
❌ Can't resolve

Application fails.

34. NetworkPolicy and Services#

A Service doesn't bypass NetworkPolicy.

Remember:

Client
  ↓
Service
  ↓
Pod

NetworkPolicy applies to Pod traffic.

For example:

Frontend
  ↓
backend-service
  ↓
Backend Pod

The policy needs to allow the actual traffic reaching the backend Pods.

35. NetworkPolicy and Ingress#

Suppose:

Internet
   ↓
Ingress Controller
   ↓
frontend-service
   ↓
Frontend Pod

Your NetworkPolicy needs to account for the actual source Pods involved in the traffic path.

You cannot simply assume:

"Internet"

is represented as a normal Kubernetes Pod selector.

Ingress controllers often run as Pods themselves, so policies may need to permit traffic from the controller's namespace/labels.

36. Default-Deny + Explicit Allow#

A production design might start with:

All ingress → DENY
All egress → DENY

Then:

Ingress Controller → Frontend
Frontend → Backend
Backend → PostgreSQL
Backend → Redis
Backend → DNS
Backend → required external services
Monitoring → required endpoints

Everything else:

❌

This is a powerful security architecture.

37. Complete Example Architecture#

                         INTERNET
                            │
                            ▼
                     Ingress Controller
                            │
                            ▼
                       Frontend Pods
                            │
                         TCP 3000
                            │
                            ▼
                       Backend Pods
                       /           \
                      /             \
                TCP 5432           TCP 6379
                    │                  │
                    ▼                  ▼
               PostgreSQL            Redis

Network rules:

Ingress Controller → Frontend    ✅
Frontend → Backend                ✅
Backend → PostgreSQL              ✅
Backend → Redis                   ✅
 
Frontend → PostgreSQL             ❌
Frontend → Redis                  ❌
Random Pod → PostgreSQL           ❌
Random Pod → Redis                ❌

38. A More Complete Backend Policy#

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

This protects backend ingress.

Then PostgreSQL has its own policy:

backend → PostgreSQL

Redis has:

backend → Redis

This is much easier to reason about than one gigantic policy.

39. NetworkPolicy Doesn't Mean "Deny Everything Automatically"#

Another common misconception.

Creating:

kind: NetworkPolicy

doesn't mean all traffic in the cluster is suddenly blocked.

Isolation happens for Pods selected by policies and for the relevant direction.

For example:

podSelector:
  matchLabels:
    app: backend

means:

Backend Pods are the selected targets

Other Pods aren't automatically selected by that policy.

40. Namespace Boundary#

Remember Chapter 8:

Namespace

isn't automatically a network security boundary.

Without NetworkPolicy:

Namespace A
   │
   └────► Namespace B

may be able to communicate.

With NetworkPolicy:

Namespace A
   │
   │ policy
   ▼
Namespace B

you can explicitly control communication.

41. Zero-Trust Network Model#

A useful security philosophy is:

Don't trust network location by default.

Instead of:

Inside cluster = trusted

think:

Every communication path
must be explicitly justified.

For example:

Frontend → Backend
allowed
 
Frontend → DB
not allowed

This is network-level least privilege.

42. NetworkPolicy + ServiceAccount#

These can work together for defense in depth.

For example:

Backend Pod
   │
   ├── ServiceAccount
   │       ↓
   │      RBAC
   │
   └── NetworkPolicy
           ↓
      Allowed traffic

Even if one layer is misconfigured, another layer may reduce exposure.

But neither replaces the other.

43. Common Mistakes#

Mistake 1 — Allowing everything#

ingress:
  - {}

This can effectively allow all ingress to selected Pods.

Use carefully.

Mistake 2 — Default-deny egress without DNS#

Result:

Service name
   ↓
DNS fails
   ↓
Application fails

Mistake 3 — Wrong labels#

Policy:

app: frontend

Actual Pod:

app: web

Result:

Policy doesn't select intended Pods.

Labels are critical.

Mistake 4 — Wrong namespace#

You may write:

namespaceSelector:

but the namespace doesn't have the expected label.

Traffic gets blocked.

Mistake 5 — Wrong port#

Backend:

Policy allows:

Result:

Connection blocked

Mistake 6 — Assuming NetworkPolicy is enforced everywhere#

The cluster's networking implementation must support NetworkPolicy enforcement.

44. Debugging NetworkPolicy#

Suppose:

Frontend → Backend

is failing.

Check:

Step 1#

Pods:

kubectl get pods -n production --show-labels

Step 2#

Policies:

kubectl get networkpolicy -n production

Step 3#

Inspect:

kubectl describe networkpolicy backend-policy \
  -n production

Step 4#

Check Services:

kubectl get svc -n production

Step 5#

Check DNS:

nslookup backend-service

Step 6#

Test connectivity from a Pod:

curl http://backend-service:3000

45. Debugging Mental Model#

If:

Frontend → Backend

doesn't work:

Frontend Pod
     │
     ▼
DNS resolution?
     │
     ▼
Service exists?
     │
     ▼
Service has endpoints?
     │
     ▼
Backend Pod ready?
     │
     ▼
NetworkPolicy allows?
     │
     ▼
Correct port?

Don't immediately blame NetworkPolicy.

46. Interview Questions#

Q1. What is NetworkPolicy?#

A Kubernetes API object used to define allowed network traffic to and/or from selected Pods, enforced by a compatible networking implementation.

Q2. Ingress vs Egress?#

Ingress = incoming traffic
Egress = outgoing traffic

Q3. What does `podSelector` do?#

Selects Pods to which the policy applies.

Q4. What does an empty `podSelector: {}` mean?#

Select all Pods in the policy's namespace.

Q5. Can NetworkPolicy control traffic across namespaces?#

Yes, using namespace selectors and appropriate policy rules.

Q6. Does NetworkPolicy replace RBAC?#

No.

RBAC → Kubernetes API permissions
NetworkPolicy → Network traffic

Q7. Does NetworkPolicy provide database authentication?#

No.

Database authentication is separate.

Q8. What is default-deny?#

Deny traffic by default for selected Pods/directions, then explicitly allow required communication.

Q9. Why can default-deny egress break applications?#

Because applications may need DNS and external/internal services that have not yet been explicitly allowed.

Q10. Who actually enforces NetworkPolicy?#

A compatible cluster networking implementation/CNI.

🧠 Chapter 20 Cheat Sheet#

NetworkPolicy
     │
     ├── Ingress
     │      ↓
     │    Incoming
     │
     └── Egress
            ↓
          Outgoing

Select Pods:#

podSelector:

Select namespace:#

namespaceSelector:

Select ports:#

ports:
  - protocol: TCP
    port: 3000

Default deny:#

podSelector: {}
 
policyTypes:
  - Ingress

or:

podSelector: {}
 
policyTypes:
  - Egress

or both.

🎯 The Production Pattern to Remember#

For your Node.js/Next.js architecture:

                     INTERNET
                         │
                         ▼
                Ingress Controller
                         │
                         ▼
                     Frontend
                         │
                         │ allowed
                         ▼
                     Backend
                    /        \
                   /          \
              allowed        allowed
                 ▼              ▼
            PostgreSQL        Redis

NetworkPolicy:

Internet → Frontend          controlled
Frontend → Backend            ✅
Backend → PostgreSQL           ✅
Backend → Redis                ✅
 
Frontend → PostgreSQL          ❌
Frontend → Redis               ❌
Random Pod → Backend           ❌
Random Pod → PostgreSQL        ❌

And security overall:

                    Kubernetes Security
                           │
          ┌────────────────┼─────────────────┐
          ▼                ▼                 ▼
        RBAC         NetworkPolicy     Container Security
          │                │                 │
          ▼                ▼                 ▼
     API access       Network access    Runtime access
          │                │                 │
          └────────────────┼─────────────────┘
                           ▼
                    Least Privilege

One-line memory trick:#

RBAC controls "who can use the Kubernetes API"; NetworkPolicy controls "who can talk to whom over the network."

Next → Chapter 21: Logging 📋#

We'll move into Observability and learn how to answer:

"My Pod is running, but something is wrong. How do I find out what happened?"

We'll cover:

kubectl logs
Container logs
Multi-container logs
Previous/crashed container logs
Logging architecture
Centralized logging
ELK / EFK
Fluent Bit
Loki
Structured JSON logs
Correlation IDs
Log levels
Production Node.js logging

And we'll build a practical logging architecture for a Node.js + Next.js + Kubernetes application.

Finished this chapter?

Mark it as complete to track your mastery.

Previous ChapterChapter 19 — Kubernetes Security 🔐Next ChapterChapter 21 — Kubernetes Logging 📋

Prev Next

In this chapter (78 sections)

We learned in Chapter 11 that Kubernetes networking generally allows Pods to communicate across the cluster.

That's powerful—but it can also be dangerous.

Imagine:

Frontend Pod
Backend Pod
Worker Pod
Redis Pod
PostgreSQL Pod
Monitoring Pod

If networking is completely unrestricted, a compromised Pod may be able to attempt connections to many other workloads.

We want:

Frontend → Backend ✅
Backend → PostgreSQL ✅
Backend → Redis ✅
Worker → PostgreSQL ✅
Frontend → PostgreSQL ❌
Frontend → Redis ❌
Random Pod → PostgreSQL ❌

This is what NetworkPolicy helps us achieve.

1. What Is NetworkPolicy?#

A Kubernetes NetworkPolicy is an API object used to control network traffic to and/or from Pods.

In simple terms:

NetworkPolicy acts like a firewall for Pod network traffic.

Mental model:

              NetworkPolicy
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
       Ingress              Egress
          │                   │
     Incoming             Outgoing
      traffic              traffic

2. Ingress vs Egress#

These two words are extremely important.

Ingress#

Traffic coming into a Pod.

Client
  │
  │ incoming
  ▼
Backend Pod

That's ingress.

Egress#

Traffic leaving a Pod.

Backend Pod
    │
    │ outgoing
    ▼
PostgreSQL

That's egress.

So:

Ingress = IN
Egress  = OUT

3. NetworkPolicy Architecture#

Suppose:

Frontend
   │
   ▼
Backend
   │
   ├──────► PostgreSQL
   │
   └──────► Redis

We can define:

Frontend
   │
   │ allowed
   ▼
Backend
 
Backend
   │
   ├── allowed → PostgreSQL
   └── allowed → Redis
 
Frontend
   │
   └── blocked → PostgreSQL

This creates network segmentation.

4. Important: NetworkPolicy Isn't Implemented by the API Object Alone#

This is a very important Kubernetes concept.

Creating:

kind: NetworkPolicy

doesn't magically create firewall rules unless your cluster's networking implementation supports and enforces NetworkPolicy.

The actual enforcement is provided by the cluster's network plugin/CNI.

Examples include:

Cilium
Calico
other NetworkPolicy-capable implementations

So:

NetworkPolicy object
       ↓
CNI / networking implementation
       ↓
Actual traffic enforcement

5. Basic NetworkPolicy#

Let's start with a simple policy.

Suppose:

app=backend

We want to control incoming traffic to those Pods.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
 
metadata:
  name: backend-policy
  namespace: production
 
spec:
  podSelector:
    matchLabels:
      app: backend
 
  policyTypes:
    - Ingress
 
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend

Let's understand this carefully.

6. `podSelector`#

podSelector:
  matchLabels:
    app: backend

This selects the Pods that the policy protects.

So:

app=backend

means:

Backend Pod A
Backend Pod B
Backend Pod C

are affected.

7. `policyTypes`#

policyTypes:
  - Ingress

This means we're defining ingress behavior.

We're controlling:

Incoming traffic

to the selected Pods.

8. `from`#

from:
  - podSelector:
      matchLabels:
        app: frontend

This says:

Allow traffic from Pods labeled app=frontend.

So:

Frontend
   │
   │ ✅
   ▼
Backend

But:

Random Pod
   │
   │ ❌
   ▼
Backend

assuming the policy is otherwise isolating ingress to the selected backend Pods.

9. Port Restrictions#

We can make the policy more specific.

Suppose Node.js backend listens on:

Then:

ingress:
  - from:
      - podSelector:
          matchLabels:
            app: frontend
 
    ports:
      - protocol: TCP
        port: 3000

Now:

Frontend → Backend:3000 ✅

but a different port isn't allowed by this rule.

10. Complete Backend Ingress Policy#

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

Architecture:

                 production
                     │
          ┌──────────┴──────────┐
          ▼                     ▼
      Frontend               Backend
      app=frontend           app=backend
          │                     ▲
          │ TCP:3000            │
          └─────────────────────┘
                    ✅

11. Important Behavior: Policies Are Additive#

NetworkPolicies are generally additive.

Suppose you have:

Policy A → allow Frontend
Policy B → allow Worker

Then the resulting allowed traffic is effectively:

Frontend ✅
Worker   ✅

not:

Only Worker ❌

Adding another policy doesn't automatically override the previous one.

Think:

Policy A
   +
Policy B
   +
Policy C
   =
Combined allowed rules

12. Default-Deny#

Now we reach one of the most important production patterns:

Default deny

Instead of saying:

Allow everything
except bad traffic

you can use:

Deny by default
and explicitly allow required traffic

This is much closer to a least-privilege networking model.

13. Default-Deny Ingress#

Suppose we want to deny incoming traffic to all Pods in production unless another policy explicitly allows it.

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

Notice:

podSelector: {}

Empty selector means:

Select all Pods in the namespace.

So:

All production Pods
        │
        ▼
Default deny ingress

14. Why `podSelector: {}`?#

This:

podSelector: {}

means:

All Pods in this namespace

Whereas:

podSelector:
  matchLabels:
    app: backend

means:

Only backend Pods

15. Default-Deny Egress#

You can also deny outgoing traffic by default.

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

Now:

Production Pods
      │
      ▼
Outgoing traffic blocked
unless explicitly allowed

16. Default Deny Both#

For strong segmentation:

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

This gives you:

Ingress → denied by default
Egress  → denied by default

Then you explicitly allow what is needed.

17. The Production Pattern#

A very common conceptual model is:

Step 1
──────
Deny everything
 
        ↓
 
Step 2
──────
Allow frontend → backend
 
        ↓
 
Step 3
──────
Allow backend → database
 
        ↓
 
Step 4
──────
Allow backend → Redis
 
        ↓
 
Step 5
──────
Allow required DNS / external services

This is much safer than:

Everything → Everything

18. Namespace Selectors#

So far we've used:

podSelector:

But what if the source Pod is in another namespace?

You can use:

namespaceSelector:

Example:

from:
  - namespaceSelector:
      matchLabels:
        team: frontend

Meaning:

Allow traffic from Pods in namespaces labeled team=frontend.

19. Namespace + Pod Selector#

You can combine:

from:
  - namespaceSelector:
      matchLabels:
        environment: production
 
    podSelector:
      matchLabels:
        app: frontend

This means:

Allow Pods matching app=frontend from namespaces matching environment=production.

This is useful for larger clusters.

20. Important YAML Structure#

This can be confusing:

from:
  - namespaceSelector:
      matchLabels:
        environment: production
    podSelector:
      matchLabels:
        app: frontend

The two selectors under the same list item are combined.

Think:

Namespace must match
        AND
Pod must match

21. Multiple `from` Entries#

Consider:

from:
  - podSelector:
      matchLabels:
        app: frontend
 
  - podSelector:
      matchLabels:
        app: worker

This means:

Frontend OR Worker

can access the selected destination, subject to the specified ports.

So:

Frontend ──┐
           ├──► Backend
Worker ────┘

22. Backend + PostgreSQL Example#

Let's create a realistic application.

production
│
├── frontend
│
├── backend
│
├── postgres
│
└── redis

Desired network:

Frontend
   │
   ▼
Backend
   │
   ├──► PostgreSQL
   │
   └──► Redis

Blocked:

Frontend ──X──► PostgreSQL
Frontend ──X──► Redis
 
Random Pod ──X──► Backend
Random Pod ──X──► PostgreSQL

23. PostgreSQL Ingress Policy#

Suppose PostgreSQL listens on:

Policy:

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

Result:

Backend
   │
   │ TCP 5432
   ▼
PostgreSQL
   ✅

24. Redis Policy#

Redis normally listens on:

Policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
 
metadata:
  name: redis-policy
  namespace: production
 
spec:
  podSelector:
    matchLabels:
      app: redis
 
  policyTypes:
    - Ingress
 
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: backend
 
      ports:
        - protocol: TCP
          port: 6379

Now:

Backend ──TCP 6379──► Redis
                    ✅

25. Why Protect Databases?#

Imagine an attacker compromises:

Frontend Pod

Without network restrictions:

Frontend
   │
   ├──► Backend
   ├──► Redis
   └──► PostgreSQL

With NetworkPolicy:

Frontend
   │
   └──► Backend
          │
          ├──► Redis
          └──► PostgreSQL

This limits lateral movement.

26. NetworkPolicy Is Not Authentication#

Very important:

NetworkPolicy doesn't replace:

Database passwords
TLS
Authentication
Authorization

For example:

NetworkPolicy
→ Can this Pod establish network traffic?
 
Database authentication
→ Does this client have valid credentials?

You should use both.

27. NetworkPolicy + RBAC#

These solve different problems.

RBAC#

Controls:

Who can interact with Kubernetes API?

NetworkPolicy#

Controls:

Which Pods can communicate over the network?

So:

RBAC
→ Kubernetes API permissions
 
NetworkPolicy
→ Network traffic permissions

28. Egress Policies#

Ingress protects incoming connections.

But you also need to consider outgoing traffic.

Imagine:

Backend Pod
    │
    ├──► PostgreSQL
    ├──► Redis
    ├──► External API
    └──► Internet

Do you really want the backend to talk to everything?

Maybe not.

You could restrict egress.

29. Egress Example#

Suppose backend should access PostgreSQL:

egress:
  - to:
      - podSelector:
          matchLabels:
            app: postgres
 
    ports:
      - protocol: TCP
        port: 5432

And:

policyTypes:
  - Egress

Now:

Backend
   │
   └──► PostgreSQL:5432
           ✅

Other outbound traffic may be denied if the Pod is isolated for egress and no other policy allows it.

30. Egress Can Get Tricky#

Suppose your Node.js backend needs:

PostgreSQL
Redis
OpenAI API
Google API
DNS
Monitoring

If you enable strict default-deny egress:

Backend
  │
  ├── PostgreSQL ❌
  ├── Redis ❌
  ├── OpenAI ❌
  ├── Google ❌
  └── DNS ❌

until you explicitly allow required destinations.

This is why NetworkPolicy rollout should be tested carefully.

31. DNS Is Especially Important#

Kubernetes applications commonly use DNS:

backend-service
postgres-service
redis-service

If you block all egress and forget DNS, your application may stop resolving service names.

Typical cluster DNS traffic uses:

UDP 53
TCP 53

depending on the DNS path and implementation.

A policy may need to allow traffic to the cluster DNS service.

32. DNS Policy Concept#

A common conceptual rule looks like:

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

Exact labels and DNS architecture should be verified for your cluster.

The important idea is:

Application
    │
    ▼
DNS
    │
    ▼
Service name → Service IP

33. Why DNS Matters#

Your backend might use:

postgres-service

instead of:

10.42.1.27

If DNS is blocked:

postgres-service
       ↓
❌ Can't resolve

Application fails.

34. NetworkPolicy and Services#

A Service doesn't bypass NetworkPolicy.

Remember:

Client
  ↓
Service
  ↓
Pod

NetworkPolicy applies to Pod traffic.

For example:

Frontend
  ↓
backend-service
  ↓
Backend Pod

The policy needs to allow the actual traffic reaching the backend Pods.

35. NetworkPolicy and Ingress#

Suppose:

Internet
   ↓
Ingress Controller
   ↓
frontend-service
   ↓
Frontend Pod

Your NetworkPolicy needs to account for the actual source Pods involved in the traffic path.

You cannot simply assume:

"Internet"

is represented as a normal Kubernetes Pod selector.

Ingress controllers often run as Pods themselves, so policies may need to permit traffic from the controller's namespace/labels.

36. Default-Deny + Explicit Allow#

A production design might start with:

All ingress → DENY
All egress → DENY

Then:

Ingress Controller → Frontend
Frontend → Backend
Backend → PostgreSQL
Backend → Redis
Backend → DNS
Backend → required external services
Monitoring → required endpoints

Everything else:

❌

This is a powerful security architecture.

37. Complete Example Architecture#

                         INTERNET
                            │
                            ▼
                     Ingress Controller
                            │
                            ▼
                       Frontend Pods
                            │
                         TCP 3000
                            │
                            ▼
                       Backend Pods
                       /           \
                      /             \
                TCP 5432           TCP 6379
                    │                  │
                    ▼                  ▼
               PostgreSQL            Redis

Network rules:

Ingress Controller → Frontend    ✅
Frontend → Backend                ✅
Backend → PostgreSQL              ✅
Backend → Redis                   ✅
 
Frontend → PostgreSQL             ❌
Frontend → Redis                  ❌
Random Pod → PostgreSQL           ❌
Random Pod → Redis                ❌

38. A More Complete Backend Policy#

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

This protects backend ingress.

Then PostgreSQL has its own policy:

backend → PostgreSQL

Redis has:

backend → Redis

This is much easier to reason about than one gigantic policy.

39. NetworkPolicy Doesn't Mean "Deny Everything Automatically"#

Another common misconception.

Creating:

kind: NetworkPolicy

doesn't mean all traffic in the cluster is suddenly blocked.

Isolation happens for Pods selected by policies and for the relevant direction.

For example:

podSelector:
  matchLabels:
    app: backend

means:

Backend Pods are the selected targets

Other Pods aren't automatically selected by that policy.

40. Namespace Boundary#

Remember Chapter 8:

Namespace

isn't automatically a network security boundary.

Without NetworkPolicy:

Namespace A
   │
   └────► Namespace B

may be able to communicate.

With NetworkPolicy:

Namespace A
   │
   │ policy
   ▼
Namespace B

you can explicitly control communication.

41. Zero-Trust Network Model#

A useful security philosophy is:

Don't trust network location by default.

Instead of:

Inside cluster = trusted

think:

Every communication path
must be explicitly justified.

For example:

Frontend → Backend
allowed
 
Frontend → DB
not allowed

This is network-level least privilege.

42. NetworkPolicy + ServiceAccount#

These can work together for defense in depth.

For example:

Backend Pod
   │
   ├── ServiceAccount
   │       ↓
   │      RBAC
   │
   └── NetworkPolicy
           ↓
      Allowed traffic

Even if one layer is misconfigured, another layer may reduce exposure.

But neither replaces the other.

43. Common Mistakes#

Mistake 1 — Allowing everything#

ingress:
  - {}

This can effectively allow all ingress to selected Pods.

Use carefully.

Mistake 2 — Default-deny egress without DNS#

Result:

Service name
   ↓
DNS fails
   ↓
Application fails

Mistake 3 — Wrong labels#

Policy:

app: frontend

Actual Pod:

app: web

Result:

Policy doesn't select intended Pods.

Labels are critical.

Mistake 4 — Wrong namespace#

You may write:

namespaceSelector:

but the namespace doesn't have the expected label.

Traffic gets blocked.

Mistake 5 — Wrong port#

Backend:

Policy allows:

Result:

Connection blocked

Mistake 6 — Assuming NetworkPolicy is enforced everywhere#

The cluster's networking implementation must support NetworkPolicy enforcement.

44. Debugging NetworkPolicy#

Suppose:

Frontend → Backend

is failing.

Check:

Step 1#

Pods:

kubectl get pods -n production --show-labels

Step 2#

Policies:

kubectl get networkpolicy -n production

Step 3#

Inspect:

kubectl describe networkpolicy backend-policy \
  -n production

Step 4#

Check Services:

kubectl get svc -n production

Step 5#

Check DNS:

nslookup backend-service

Step 6#

Test connectivity from a Pod:

curl http://backend-service:3000

45. Debugging Mental Model#

If:

Frontend → Backend

doesn't work:

Frontend Pod
     │
     ▼
DNS resolution?
     │
     ▼
Service exists?
     │
     ▼
Service has endpoints?
     │
     ▼
Backend Pod ready?
     │
     ▼
NetworkPolicy allows?
     │
     ▼
Correct port?

Don't immediately blame NetworkPolicy.

46. Interview Questions#

Q1. What is NetworkPolicy?#

A Kubernetes API object used to define allowed network traffic to and/or from selected Pods, enforced by a compatible networking implementation.

Q2. Ingress vs Egress?#

Ingress = incoming traffic
Egress = outgoing traffic

Q3. What does `podSelector` do?#

Selects Pods to which the policy applies.

Q4. What does an empty `podSelector: {}` mean?#

Select all Pods in the policy's namespace.

Q5. Can NetworkPolicy control traffic across namespaces?#

Yes, using namespace selectors and appropriate policy rules.

Q6. Does NetworkPolicy replace RBAC?#

No.

RBAC → Kubernetes API permissions
NetworkPolicy → Network traffic

Q7. Does NetworkPolicy provide database authentication?#

No.

Database authentication is separate.

Q8. What is default-deny?#

Deny traffic by default for selected Pods/directions, then explicitly allow required communication.

Q9. Why can default-deny egress break applications?#

Because applications may need DNS and external/internal services that have not yet been explicitly allowed.

Q10. Who actually enforces NetworkPolicy?#

A compatible cluster networking implementation/CNI.

🧠 Chapter 20 Cheat Sheet#

NetworkPolicy
     │
     ├── Ingress
     │      ↓
     │    Incoming
     │
     └── Egress
            ↓
          Outgoing

Select Pods:#

podSelector:

Select namespace:#

namespaceSelector:

Select ports:#

ports:
  - protocol: TCP
    port: 3000

Default deny:#

podSelector: {}
 
policyTypes:
  - Ingress

or:

podSelector: {}
 
policyTypes:
  - Egress

or both.

🎯 The Production Pattern to Remember#

For your Node.js/Next.js architecture:

                     INTERNET
                         │
                         ▼
                Ingress Controller
                         │
                         ▼
                     Frontend
                         │
                         │ allowed
                         ▼
                     Backend
                    /        \
                   /          \
              allowed        allowed
                 ▼              ▼
            PostgreSQL        Redis

NetworkPolicy:

Internet → Frontend          controlled
Frontend → Backend            ✅
Backend → PostgreSQL           ✅
Backend → Redis                ✅
 
Frontend → PostgreSQL          ❌
Frontend → Redis               ❌
Random Pod → Backend           ❌
Random Pod → PostgreSQL        ❌

And security overall:

                    Kubernetes Security
                           │
          ┌────────────────┼─────────────────┐
          ▼                ▼                 ▼
        RBAC         NetworkPolicy     Container Security
          │                │                 │
          ▼                ▼                 ▼
     API access       Network access    Runtime access
          │                │                 │
          └────────────────┼─────────────────┘
                           ▼
                    Least Privilege

One-line memory trick:#

RBAC controls "who can use the Kubernetes API"; NetworkPolicy controls "who can talk to whom over the network."

Next → Chapter 21: Logging 📋#

We'll move into Observability and learn how to answer:

"My Pod is running, but something is wrong. How do I find out what happened?"

We'll cover:

kubectl logs
Container logs
Multi-container logs
Previous/crashed container logs
Logging architecture
Centralized logging
ELK / EFK
Fluent Bit
Loki
Structured JSON logs
Correlation IDs
Log levels
Production Node.js logging

And we'll build a practical logging architecture for a Node.js + Next.js + Kubernetes application.

Finished this chapter?

Mark it as complete to track your mastery.

Previous ChapterChapter 19 — Kubernetes Security 🔐Next ChapterChapter 21 — Kubernetes Logging 📋

1. What Is NetworkPolicy?#

2. Ingress vs Egress#

Ingress#

Egress#

3. NetworkPolicy Architecture#

4. Important: NetworkPolicy Isn't Implemented by the API Object Alone#

5. Basic NetworkPolicy#

6. podSelector#

7. policyTypes#

8. from#

9. Port Restrictions#

10. Complete Backend Ingress Policy#

11. Important Behavior: Policies Are Additive#

12. Default-Deny#

13. Default-Deny Ingress#

14. Why podSelector: {}?#

15. Default-Deny Egress#

16. Default Deny Both#

17. The Production Pattern#

18. Namespace Selectors#

19. Namespace + Pod Selector#

20. Important YAML Structure#

21. Multiple from Entries#

22. Backend + PostgreSQL Example#

23. PostgreSQL Ingress Policy#

24. Redis Policy#

25. Why Protect Databases?#

26. NetworkPolicy Is Not Authentication#

27. NetworkPolicy + RBAC#

RBAC#

NetworkPolicy#

28. Egress Policies#

29. Egress Example#

30. Egress Can Get Tricky#

31. DNS Is Especially Important#

32. DNS Policy Concept#

33. Why DNS Matters#

34. NetworkPolicy and Services#

35. NetworkPolicy and Ingress#

36. Default-Deny + Explicit Allow#

37. Complete Example Architecture#

38. A More Complete Backend Policy#

39. NetworkPolicy Doesn't Mean "Deny Everything Automatically"#

40. Namespace Boundary#

41. Zero-Trust Network Model#

42. NetworkPolicy + ServiceAccount#

43. Common Mistakes#

Mistake 1 — Allowing everything#

Mistake 2 — Default-deny egress without DNS#

Mistake 3 — Wrong labels#

Mistake 4 — Wrong namespace#

Mistake 5 — Wrong port#

Mistake 6 — Assuming NetworkPolicy is enforced everywhere#

44. Debugging NetworkPolicy#

Step 1#

Step 2#

Step 3#

Step 4#

Step 5#

Step 6#

45. Debugging Mental Model#

46. Interview Questions#

Q1. What is NetworkPolicy?#

Q2. Ingress vs Egress?#

Q3. What does podSelector do?#

Q4. What does an empty podSelector: {} mean?#

Q5. Can NetworkPolicy control traffic across namespaces?#

Q6. Does NetworkPolicy replace RBAC?#

Q7. Does NetworkPolicy provide database authentication?#

Q8. What is default-deny?#

Q9. Why can default-deny egress break applications?#

Q10. Who actually enforces NetworkPolicy?#

🧠 Chapter 20 Cheat Sheet#

Select Pods:#

Select namespace:#

Select ports:#

Default deny:#

🎯 The Production Pattern to Remember#

One-line memory trick:#

Next → Chapter 21: Logging 📋#

6. `podSelector`#

7. `policyTypes`#

8. `from`#

14. Why `podSelector: {}`?#

21. Multiple `from` Entries#

Q3. What does `podSelector` do?#

Q4. What does an empty `podSelector: {}` mean?#

6. `podSelector`#

7. `policyTypes`#

8. `from`#

14. Why `podSelector: {}`?#

21. Multiple `from` Entries#