DevOps Bootcamp · Lesson

Network Policies for Isolation

Control network traffic flow between Pods and namespaces using Kubernetes Network Policies.

Network Policies for Isolation is a free DevOps Bootcamp lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the DevOps Bootcamp learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Network Policies: Traffic Cops

In Kubernetes, Pods can talk to each other freely by default. This is great for flexibility, but not always ideal for security.

Network Policies act like firewalls for your Pods, controlling which network traffic is allowed in (ingress) and out (egress).

Default: All Pods Can Talk

By default, once a Pod is deployed, it can communicate with any other Pod in the cluster, regardless of namespace. This "flat network" model simplifies setup but lacks isolation.

For production environments, you often need to restrict communication to enhance security and prevent unauthorized access between application components.

Ingress & Egress Rules

Network Policies define rules for how Pods are allowed to communicate. They primarily focus on two types of traffic:

Ingress: Incoming traffic to a Pod.
Egress: Outgoing traffic from a Pod.

These rules are applied to specific Pods using labels and can target other Pods, namespaces, or IP blocks.

CNI Plugin Requirement

Network Policies aren't magic! For them to work, your Kubernetes cluster must have a Container Network Interface (CNI) plugin that supports them.

Popular CNI plugins like Calico, Cilium, and Weave Net provide this functionality. Without a supporting CNI, Network Policies will have no effect.

Anatomy of a Policy

Network Policies are defined using YAML. Key fields include:

metadata.name: A unique name for your policy.
spec.podSelector: Selects the Pods to which this policy applies.
spec.policyTypes: Specifies if the policy applies to Ingress, Egress, or both.
spec.ingress/spec.egress: Lists the rules for allowed traffic.

Block All Incoming Traffic

Let's create a policy to deny all incoming traffic to Pods with the label app: backend in the current namespace. This is a common starting point for a "deny-by-default" security posture.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-backend-ingress
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress: [] # An empty ingress list denies all incoming traffic

Allow Ingress from Frontend

Now, let's modify our policy to allow incoming traffic only from Pods labeled app: frontend in the same namespace to our app: backend Pods.

Notice the from section specifying the source Pods.

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

Controlling Outgoing Traffic

Just like ingress, you can control egress (outgoing) traffic. Here, we'll create a policy that allows app: backend Pods to make outgoing requests only to Pods labeled app: database.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-egress-to-db
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database

Targeting Other Namespaces

What if your frontend is in a different namespace, say web-apps? You can use namespaceSelector to target Pods across namespaces.

This policy allows ingress to app: backend Pods from any Pod in the web-apps namespace.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-apps-ingress
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: web-apps
      podSelector: {} # All pods in the selected namespace

Policy Challenge

Consider a Pod with labels app: web and env: prod. Which Network Policy would allow only incoming traffic from Pods in the monitoring namespace?

Recap: Secure Your Network

Great job! You've learned how Kubernetes Network Policies provide crucial network isolation for your applications.

They act as firewalls for Pods.
Control both ingress (in) and egress (out) traffic.
Require a CNI plugin that supports them.
Are defined using YAML with podSelector, policyTypes, and rule definitions.
Can target Pods by labels and even entire namespaces.

Use them to enforce a "least privilege" network model!

Frequently asked questions

Is the “Network Policies for Isolation” lesson free?

Yes — the full text of “Network Policies for Isolation” is free to read here on the web, and the DevOps Bootcamp course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the DevOps Bootcamp course, upgrade to CoddyKit PRO.

What will I learn in “Network Policies for Isolation”?

Control network traffic flow between Pods and namespaces using Kubernetes Network Policies. You practise DevOps Bootcamp with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start DevOps Bootcamp?

No prior experience is required. DevOps Bootcamp on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Network Policies for Isolation” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this DevOps Bootcamp lesson?

Yes. Every DevOps Bootcamp lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

← Back to DevOps Bootcamp