Lab 01 — Configure Kubernetes Network Policies

Mission Information

Item	Details
Lab ID	K8S-NET-LAB-01
Difficulty	Intermediate
Estimated Time	2–3 Hours
Environment	Kubernetes Cluster (Amazon EKS / Azure AKS / Google GKE / kind)
Platform	Kubernetes
Cost	Free (kind) / Cloud Charges Apply
Primary Role	Kubernetes Security Engineer
Module	Module 03 — Kubernetes Network Security & Zero Trust
Previous Module	Module 02 — Kubernetes Identity & Access Management

Mission Scenario

CloudNova Technologies operates a production Kubernetes platform hosting multiple business-critical applications, including:

Customer Portal
Inventory API
Payment Service
PostgreSQL Database
Monitoring Platform

A recent penetration test discovered that every Pod could communicate with every other Pod, regardless of application, namespace, or business function. This unrestricted communication creates opportunities for attackers to move laterally through the environment if a single workload is compromised.

The Chief Information Security Officer (CISO) has mandated the implementation of Zero Trust networking using Kubernetes Network Policies.

As the Kubernetes Security Engineer, your mission is to redesign network communication so that workloads can communicate only when explicitly authorised.

Learning Objectives

By completing this lab, you will learn how to:

Understand Kubernetes Network Policies
Implement Zero Trust networking
Configure default deny policies
Allow authorised Pod-to-Pod communication
Restrict east-west traffic
Secure namespaces
Configure ingress rules
Configure egress rules
Test network segmentation
Validate policy enforcement
Perform an enterprise network security assessment

Enterprise Architecture

                 CloudNova Kubernetes Cluster

                    Kubernetes Network

        ┌────────────────────────────────────┐
        │                                    │
        │        Customer Namespace          │
        │                                    │
        │  Frontend Pod ───► API Pod         │
        │                     │              │
        └─────────────────────│──────────────┘
                              │
                    Allowed Communication
                              │
                              ▼
        ┌────────────────────────────────────┐
        │                                    │
        │       Database Namespace           │
        │                                    │
        │        PostgreSQL Pod              │
        │                                    │
        └────────────────────────────────────┘

Any other communication:

❌ Denied

Lab Outcomes

By the end of this lab, you will have:

Created multiple namespaces
Deployed sample applications
Implemented default deny policies
Allowed authorised application traffic
Restricted unauthorised communication
Validated east-west segmentation
Tested ingress and egress controls
Produced an enterprise network security assessment

Prerequisites

Before starting:

Complete Module 01
Complete Module 02
kubectl installed
Kubernetes cluster running
Basic understanding of Pods and Services

Tools Used

Tool	Purpose
kubectl	Kubernetes administration
Docker Desktop	Local runtime
kind	Local Kubernetes
Visual Studio Code	YAML editing
Git Bash / PowerShell	Command execution

Enterprise Background

By default, Kubernetes allows all Pods to communicate with one another.

This model provides excellent flexibility but introduces significant security risks.

Without Network Policies:

Malware can spread laterally.
Internal APIs become accessible to every workload.
Databases are exposed unnecessarily.
Compromised containers can attack other applications.
Zero Trust principles cannot be enforced.

Network Policies provide firewall-like controls at the Pod level by defining which traffic is permitted.

Zero Trust Networking Principle

Traditional Networking

Everything is trusted

Application A ─────────► Application B

Application B ─────────► Database

Everything allowed


Zero Trust Networking

Application A ─────► API

API ───────────────► Database

Everything else

DENIED

Task 01 — Verify Cluster Health

Confirm cluster connectivity.

kubectl cluster-info

kubectl get nodes

Verify:

Cluster accessible
Nodes Ready

Task 02 — Create Enterprise Namespaces

Create three namespaces.

kubectl create namespace frontend

kubectl create namespace backend

kubectl create namespace database

Verify:

kubectl get namespaces

Task 03 — Deploy Sample Applications

Deploy:

Frontend

nginx

Backend

httpd

Database

postgres

Deploy one Pod into each namespace.

Verify:

kubectl get pods -A

Task 04 — Test Default Communication

From the frontend Pod:

kubectl exec -it <frontend-pod> -n frontend -- /bin/sh

Attempt to communicate with backend.

wget http://backend-service

Attempt to reach the database.

Observe:

Communication succeeds because no Network Policies exist.

Document findings.

Task 05 — Create a Default Deny Policy

Create a Network Policy that blocks all ingress traffic.

Example:

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

Apply:

kubectl apply -f default-deny.yaml

Task 06 — Validate Policy Enforcement

Repeat connectivity tests.

Expected:

Connection timed out

OR

Connection refused

Document results.

Task 07 — Allow Frontend to Access Backend

Create a policy allowing:

Frontend

↓

Backend

Example concepts:

Namespace Selector
Pod Selector
Ingress Rule

Apply policy.

Verify communication.

Expected:

Frontend

✅ Backend

Database

❌ Blocked

Task 08 — Allow Backend to Access Database

Create another Network Policy allowing:

Backend

↓

Database

Validate:

Backend

✅ Database

Frontend

❌ Database

Task 09 — Configure Egress Restrictions

Create an egress policy limiting outbound traffic.

Allow only:

Kubernetes DNS
Backend API
Database

Everything else:

Denied.

Validate connectivity.

Task 10 — Review Network Policies

List policies.

kubectl get networkpolicies -A

Describe policies.

kubectl describe networkpolicy

Review:

Pod selectors
Namespace selectors
Allowed ports
Allowed protocols

Task 11 — Simulate a Security Incident

Scenario:

An attacker compromises the frontend application.

Attempt:

Frontend

↓

Database

↓

Monitoring

↓

Other namespaces

Expected:

Blocked by Network Policies.

Discuss:

How Network Policies reduce lateral movement.

Task 12 — Review Traffic Flow

Complete the matrix.

Source	Destination	Result
Frontend	Backend	Allowed
Frontend	Database	Denied
Backend	Database	Allowed
Database	Frontend	Denied
Backend	Frontend	Denied
Random Namespace	Backend	Denied

Task 13 — Enterprise Security Assessment

Review:

Default deny implemented
Namespace isolation
East-west segmentation
Egress restrictions
Policy documentation
Least privilege networking

Classify findings:

Compliant
Requires Improvement
Non-Compliant

Task 14 — Produce an Assessment Report

Document:

Cluster:

Namespaces Reviewed:

Applications:

Policies Created:

Traffic Allowed:

Traffic Denied:

Security Findings:

Recommendations:

Overall Network Security Rating:

Task 15 — Evidence Collection

Capture evidence for:

Namespaces
Pods
Network Policies
Connectivity tests
Traffic matrix
Security assessment
Final report

Task 16 — Clean Up

Delete test resources.

kubectl delete namespace frontend

kubectl delete namespace backend

kubectl delete namespace database

Verify cleanup.

Skills Developed

By completing this lab, you will be able to:

Implement Kubernetes Network Policies
Apply Zero Trust networking
Restrict Pod-to-Pod communication
Configure ingress rules
Configure egress rules
Secure namespaces
Prevent lateral movement
Validate network segmentation
Review enterprise network security
Troubleshoot policy enforcement

Knowledge Check

Question 1

What is the primary purpose of a Kubernetes Network Policy?

A. Schedule Pods
B. Control network traffic between Pods and namespaces
C. Encrypt Kubernetes Secrets
D. Create Services

Answer: B

Question 2

What happens if a default deny Network Policy is applied without any allow rules?

A. All traffic is permitted.
B. All selected ingress traffic is blocked until explicitly allowed.
C. Pods are deleted automatically.
D. DNS is permanently disabled.

Answer: B

Question 3

Which security principle is implemented using Kubernetes Network Policies?

A. High Availability
B. Zero Trust Networking
C. Autoscaling
D. Infrastructure as Code

Answer: B

Question 4

Which type of attack do Network Policies primarily help mitigate?

A. SQL Injection
B. Lateral movement between workloads
C. Cross-Site Scripting (XSS)
D. DNS spoofing

Answer: B

Question 5

Which traffic should generally be allowed only when required?

A. All Pod-to-Pod communication
B. Only explicitly authorised application communication based on business requirements
C. All outbound internet traffic
D. All namespace-to-namespace traffic

Answer: B

Lab Summary

In this lab, you implemented Kubernetes Network Policies to enforce Zero Trust networking within a Kubernetes cluster. You created namespace segmentation, applied default deny policies, configured explicit ingress and egress rules, and validated that only authorised application communication was permitted.

These controls significantly reduced the attack surface by preventing unauthorised east-west traffic and limiting lateral movement between workloads. The techniques practiced in this lab mirror the network segmentation strategies used by enterprise Platform Engineering and Cloud Security teams to secure production Kubernetes environments.

What’s Next?

➡️ **Lab 02 — Block Pod-to-Pod Communication

Learn how to prevent lateral movement inside Kubernetes by implementing default deny ingress and egress Network Policies, isolating workloads, and enforcing Zero Trust communication between Pods.