Lab 02 — Block Pod-to-Pod Communication

Mission Information

Item	Details
Lab ID	K8S-NET-LAB-02
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 Lab	Lab 01 — Configure Kubernetes Network Policies

Mission Scenario

CloudNova Technologies has recently completed a Red Team assessment of its Kubernetes platform.

The assessment revealed that once an attacker compromised a vulnerable frontend application, they could freely communicate with nearly every Pod in the cluster.

The attacker successfully:

Connected to backend APIs
Scanned internal services
Reached PostgreSQL databases
Accessed monitoring components
Attempted lateral movement across namespaces

Although Kubernetes RBAC prevented direct access to the Kubernetes API, unrestricted Pod networking allowed attackers to move throughout the environment.

To reduce the attack surface, the Chief Information Security Officer (CISO) has directed the Cloud Security team to implement micro-segmentation by blocking unnecessary Pod-to-Pod communication.

Your objective is to isolate workloads using Kubernetes Network Policies and verify that only explicitly authorised communication is permitted.

Learning Objectives

By completing this lab, you will learn how to:

Understand Pod-to-Pod communication
Identify lateral movement risks
Implement default deny policies
Block east-west traffic
Restrict cross-namespace communication
Restrict same-namespace communication
Apply ingress controls
Apply egress controls
Validate Zero Trust networking
Troubleshoot Network Policies
Perform an enterprise network segmentation assessment

Enterprise Architecture

                Before Security Controls

     Frontend Pod ─────────────► Backend Pod

     Frontend Pod ─────────────► Database

     Frontend Pod ─────────────► Monitoring

     Backend Pod ──────────────► Database

Everything Allowed



                After Network Policies

     Frontend Pod ─────────────► Backend Pod

     Frontend Pod ─────────────X Database

     Frontend Pod ─────────────X Monitoring

     Random Pod ───────────────X Backend

     Backend Pod ──────────────► Database

Only Approved Communication

Lab Outcomes

By the end of this lab, you will have:

Deployed a multi-tier application
Observed unrestricted Pod communication
Implemented default deny ingress
Implemented default deny egress
Blocked Pod-to-Pod communication
Prevented lateral movement
Allowed only business-approved traffic
Validated namespace isolation
Produced an enterprise segmentation report

Prerequisites

Before starting:

Complete Lab 01
Kubernetes cluster running
kubectl installed
Basic understanding of Kubernetes Network Policies

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

Kubernetes follows a flat networking model, meaning every Pod can communicate with every other Pod unless restrictions are applied.

This default behaviour simplifies application deployment but significantly increases security risks.

If a single workload is compromised, attackers can often:

Scan internal applications
Discover databases
Identify exposed services
Pivot into additional namespaces
Perform credential harvesting
Launch lateral movement attacks

Modern Kubernetes environments implement micro-segmentation, allowing communication only between workloads that have a legitimate business requirement.

Task 01 — Verify Cluster Health

Verify cluster access.

kubectl cluster-info

kubectl get nodes

Expected:

Cluster accessible
Nodes in Ready state

Task 02 — Create Enterprise Namespaces

Create three namespaces.

kubectl create namespace frontend

kubectl create namespace backend

kubectl create namespace database

Verify.

kubectl get ns

Task 03 — Deploy Sample Applications

Deploy:

Frontend

nginx

Backend

httpd

Database

postgres

Verify deployment.

kubectl get pods -A

Task 04 — Test Existing Communication

Open a shell inside the frontend Pod.

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

Attempt to reach the backend.

wget http://backend-service

Attempt to reach PostgreSQL.

nc database-service 5432

Observe:

Communication succeeds because no isolation exists.

Record your findings.

Task 05 — Simulate Lateral Movement

Assume the frontend application has been compromised.

Attempt to:

Scan backend services
Reach the database
Reach monitoring workloads
Connect to Pods in other namespaces

Discuss:

Why unrestricted communication is dangerous.

Task 06 — Apply Default Deny Ingress Policy

Create a default deny ingress policy.

Example:

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

Deploy the policy.

kubectl apply -f default-deny-ingress.yaml

Task 07 — Verify Communication is Blocked

Repeat connectivity tests.

Expected:

Connection timed out

OR

Connection refused

Verify:

Frontend → Backend

Blocked

Frontend → Database

Blocked

Task 08 — Apply Default Deny Egress Policy

Create a policy blocking outbound communication.

policyTypes:
- Egress

Apply.

Verify that outbound traffic is now restricted.

Task 09 — Allow Required Application Traffic

Create Network Policies permitting only:

Frontend

↓

Backend

↓

Database

Validate.

Expected:

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

Task 10 — Validate Namespace Isolation

Create a temporary namespace.

kubectl create namespace attacker

Deploy a test Pod.

Attempt to connect to:

Frontend
Backend
Database

Expected:

All communication blocked.

Task 11 — Review Network Policies

List policies.

kubectl get networkpolicy -A

Describe a policy.

kubectl describe networkpolicy

Review:

Pod selectors
Namespace selectors
Allowed ports
Policy types

Task 12 — Perform Connectivity Validation

Test all application flows.

Document:

Communication	Status
Frontend → Backend
Backend → Database
Frontend → Database
Backend → Frontend
Attacker → Backend
Attacker → Database

Task 13 — Simulate an Enterprise Security Incident

Scenario:

A malicious container has been deployed.

Attempt to:

Scan the cluster
Connect to databases
Access monitoring tools
Reach internal APIs

Expected:

Network Policies prevent lateral movement.

Discuss how segmentation limits attacker capabilities.

Task 14 — Enterprise Security Assessment

Evaluate:

Default deny enabled
Ingress restricted
Egress restricted
Namespace isolation
Micro-segmentation implemented
Zero Trust enforced

Classify:

Compliant
Requires Improvement
Non-Compliant

Task 15 — Produce a Network Segmentation Report

Document:

Cluster:

Namespaces:

Applications:

Policies Applied:

Allowed Communication:

Blocked Communication:

Security Findings:

Recommendations:

Overall Segmentation Rating:

Task 16 — Evidence Collection

Capture evidence for:

Namespaces
Pods
Network Policies
Connectivity tests
Blocked connections
Allowed connections
Assessment report

Task 17 — Clean Up

Delete resources.

kubectl delete namespace frontend

kubectl delete namespace backend

kubectl delete namespace database

kubectl delete namespace attacker

Verify cleanup.

Skills Developed

By completing this lab, you will be able to:

Block Pod-to-Pod communication
Prevent lateral movement
Configure ingress restrictions
Configure egress restrictions
Implement namespace isolation
Apply Zero Trust networking
Validate Network Policies
Secure east-west traffic
Perform enterprise network segmentation assessments
Troubleshoot Kubernetes networking issues

Knowledge Check

Question 1

Why is unrestricted Pod-to-Pod communication considered a security risk?

A. It increases Kubernetes performance.
B. It enables attackers to move laterally between workloads after compromising a Pod.
C. It prevents applications from communicating.
D. It disables Kubernetes DNS.

Answer: B

Question 2

Which Kubernetes resource is used to restrict Pod-to-Pod communication?

A. Service
B. Deployment
C. NetworkPolicy
D. ConfigMap

Answer: C

Question 3

What is the purpose of a default deny Network Policy?

A. Allow all communication.
B. Block selected traffic until explicit allow rules are created.
C. Encrypt Pod traffic.
D. Delete inactive Pods.

Answer: B

Question 4

Which communication should normally be allowed in a secure three-tier application?

A. Every Pod communicating with every other Pod.
B. Only business-required communication, such as Frontend → Backend and Backend → Database.
C. Direct Frontend → Database communication.
D. Public internet access to all Pods.

Answer: B

Question 5

What security concept is achieved by blocking unnecessary Pod-to-Pod communication?

A. High Availability
B. Micro-segmentation and Zero Trust networking
C. Horizontal Pod Autoscaling
D. Cluster federation

Answer: B

Lab Summary

In this lab, you implemented Kubernetes Network Policies to block unnecessary Pod-to-Pod communication and enforce micro-segmentation within a Kubernetes cluster. By applying default deny ingress and egress policies, allowing only approved application flows, and validating namespace isolation, you significantly reduced the risk of lateral movement following a workload compromise.

These controls are widely used in enterprise Kubernetes environments to support Zero Trust networking, protect sensitive workloads, and ensure that application communication is limited strictly to legitimate business requirements.

What’s Next?

➡️ Lab 03 — Secure Ingress

In the next lab, you will secure north-south traffic by deploying an Ingress Controller, configuring HTTPS with TLS certificates, restricting external exposure, and publishing Kubernetes applications securely to users while protecting them from common web-based threats.