Lab 04 — Implement Zero Trust Networking

Mission Information

Item	Details
Lab ID	K8S-NET-LAB-04
Difficulty	Advanced
Estimated Time	4–5 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 03 — Secure Ingress

Mission Scenario

CloudNova Technologies has successfully implemented Kubernetes Network Policies and secured its internet-facing applications using an Ingress Controller.

Although these improvements significantly reduced the attack surface, a recent Purple Team exercise demonstrated that a compromised workload could still communicate with several internal services that it did not legitimately require.

The Chief Information Security Officer (CISO) has approved a company-wide initiative to implement a Zero Trust Architecture for Kubernetes.

Under this model:

No workload is trusted automatically.
Every network connection must be explicitly authorised.
Communication is permitted only when there is a valid business requirement.
Every workload is isolated according to its role.
Access is continuously verified and monitored.

As the Kubernetes Security Engineer, your mission is to redesign the cluster so that every application communicates only with approved services, eliminating implicit trust and reducing the risk of lateral movement.

Learning Objectives

By completing this lab, you will learn how to:

Understand Zero Trust networking principles
Design a Zero Trust Kubernetes architecture
Implement namespace isolation
Enforce least-privilege communication
Combine ingress and egress Network Policies
Restrict east-west traffic
Protect north-south traffic
Validate application communication paths
Prevent lateral movement
Conduct an enterprise Zero Trust assessment

Enterprise Architecture

                     Internet Users
                            │
                        HTTPS Only
                            │
                    Ingress Controller
                            │
                Customer Frontend Namespace
                            │
                 Allowed Application Traffic
                            │
                            ▼
                Inventory API Namespace
                            │
                 Allowed Application Traffic
                            │
                            ▼
                 Database Namespace

--------------------------------------------------

Any Unauthorised Communication

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

Backend ────────────────► Logging

Random Pod ─────────────► Database

Development ────────────► Production

Result

❌ Denied

Zero Trust Principles

Throughout this lab, apply the following principles:

Never trust by default.
Verify every connection.
Grant only minimum required access.
Deny all unnecessary communication.
Isolate workloads by function.
Continuously validate network policies.

Lab Outcomes

By the end of this lab, you will have:

Built a Zero Trust network architecture
Applied default deny policies
Implemented namespace isolation
Allowed only business-approved communication
Protected sensitive workloads
Prevented lateral movement
Validated secure application flows
Produced an enterprise Zero Trust assessment report

Prerequisites

Before starting:

Complete Labs 01–03
Kubernetes cluster running
kubectl installed
Network Policies supported by the cluster CNI

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

Traditional network security assumes that systems inside a trusted network can communicate freely.

Zero Trust removes this assumption.

Every workload must prove its identity and every communication path must be explicitly authorised.

In Kubernetes, Zero Trust is achieved through a combination of:

Namespace isolation
Network Policies
Least-privilege communication
Secure Ingress
Strong workload identities
Continuous monitoring

Zero Trust Communication Model

Customer Frontend

        │

        ▼

Inventory API

        │

        ▼

Database

Allowed


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 namespaces representing different business functions.

kubectl create namespace frontend

kubectl create namespace backend

kubectl create namespace database

kubectl create namespace monitoring

kubectl create namespace development

Verify:

kubectl get namespaces

Task 03 — Deploy a Multi-Tier Application

Deploy:

Frontend (NGINX)
Backend API (HTTPD)
PostgreSQL Database
Monitoring Application

Verify:

kubectl get pods -A

Task 04 — Observe Default Communication

Before applying policies, test communication between all workloads.

Examples:

Frontend → Backend
Frontend → Database
Backend → Database
Monitoring → Database
Development → Backend

Record which connections succeed.

Task 05 — Apply Default Deny Policies

Implement:

Default Deny Ingress
Default Deny Egress

Deploy policies to every namespace.

Verify:

kubectl get networkpolicy -A

Confirm all communication is blocked until explicitly allowed.

Task 06 — Allow Business-Required Communication

Create Network Policies that allow only:

Internet

↓

Ingress Controller

↓

Frontend

↓

Backend API

↓

Database

Everything else remains blocked.

Validate:

Source	Destination	Expected
Frontend	Backend	✅ Allowed
Backend	Database	✅ Allowed
Frontend	Database	❌ Denied
Monitoring	Database	❌ Denied
Development	Production	❌ Denied

Task 07 — Implement Namespace Isolation

Restrict communication between:

Development
Testing
Production
Monitoring

Ensure workloads cannot communicate across environments unless explicitly approved.

Validate connectivity.

Task 08 — Secure North-South Traffic

Review the Ingress configuration.

Confirm:

HTTPS enforced
TLS enabled
Backend Services use ClusterIP
No unnecessary NodePort Services

Validate that only the Ingress Controller is externally accessible.

Task 09 — Simulate a Compromised Workload

Assume the frontend Pod has been compromised.

Attempt to:

Reach the PostgreSQL database directly
Access monitoring systems
Scan other namespaces
Connect to unrelated Services

Expected:

All unauthorised communication is denied.

Discuss how Zero Trust limits attacker movement.

Task 10 — Validate Least-Privilege Communication

Review every application flow.

Ensure each workload communicates only with required dependencies.

Questions:

Does any workload have unnecessary access?
Are there unused allow rules?
Can policies be further restricted?

Task 11 — Review Network Policies

List policies.

kubectl get networkpolicy -A

Inspect one policy.

kubectl describe networkpolicy <policy-name> -n <namespace>

Review:

Pod selectors
Namespace selectors
Ingress rules
Egress rules
Policy types

Task 12 — Review Zero Trust Controls

Evaluate:

Default deny implemented
Namespace isolation
East-west segmentation
North-south protection
Least privilege networking
Secure Ingress
Policy documentation

Classify:

Compliant
Requires Improvement
Non-Compliant

Task 13 — Enterprise Zero Trust Assessment

Assess the environment against Zero Trust principles.

Control	Status
Verify Explicitly
Least Privilege
Default Deny
Namespace Isolation
Secure Ingress
East-West Segmentation
Continuous Validation
Reduced Attack Surface

Task 14 — Produce a Zero Trust Assessment Report

Document:

Cluster:

Namespaces:

Applications:

Policies Implemented:

Allowed Communication:

Blocked Communication:

Lateral Movement Assessment:

Security Findings:

Recommendations:

Overall Zero Trust Maturity:

Task 15 — Evidence Collection

Capture evidence for:

Namespaces
Pods
Services
Network Policies
Ingress configuration
Connectivity tests
Blocked traffic
Allowed traffic
Zero Trust assessment
Final report

Task 16 — Clean Up

Delete:

Test Deployments
Services
Network Policies
Temporary namespaces

Verify:

kubectl get namespaces

kubectl get networkpolicy -A

Ensure all temporary resources have been removed.

Skills Developed

By completing this lab, you will be able to:

Design Zero Trust network architectures
Implement namespace isolation
Configure ingress and egress controls
Restrict east-west traffic
Secure north-south traffic
Apply least-privilege networking
Prevent lateral movement
Validate application communication paths
Assess enterprise Kubernetes security
Troubleshoot Zero Trust implementations

Knowledge Check

Question 1

What is the core principle of Zero Trust networking?

A. Trust all internal workloads by default.
B. Allow communication only after explicit verification and authorisation.
C. Expose all Services through LoadBalancers.
D. Disable Network Policies.

Answer: B

Question 2

Which Kubernetes feature is most commonly used to enforce Zero Trust communication between Pods?

A. ReplicaSets
B. ConfigMaps
C. Network Policies
D. Persistent Volumes

Answer: C

Question 3

Which communication path should typically be allowed in a three-tier application?

A. Frontend → Database
B. Frontend → Backend → Database
C. Monitoring → Database
D. Development → Production

Answer: B

Question 4

Why should development and production namespaces be isolated?

A. To increase application performance.
B. To reduce the risk of accidental or malicious access across environments.
C. To reduce Pod memory usage.
D. To improve DNS resolution.

Answer: B

Question 5

Which outcome best demonstrates a successful Zero Trust implementation?

A. Every Pod can communicate with every Service.
B. All workloads share the same namespace.
C. Only explicitly authorised communication paths are permitted, and all other traffic is denied.
D. Every Service is exposed externally using NodePort.

Answer: C

Lab Summary

In this lab, you implemented a comprehensive Zero Trust networking architecture for Kubernetes by combining Network Policies, namespace isolation, secure Ingress, and least-privilege communication. You applied default deny policies, explicitly authorised only business-required traffic, and validated that unauthorised east-west and north-south communication was blocked.

These techniques reflect the security architecture used by enterprise Kubernetes platforms to minimise the attack surface, prevent lateral movement, and enforce continuous verification of application communication. Zero Trust networking is a foundational capability for securing modern cloud-native environments and aligns with industry frameworks such as NIST Zero Trust Architecture and the CIS Kubernetes Benchmark.

What’s Next?

➡️ Lab 05 — Service Mesh Security

In the next lab, you will implement a Service Mesh using technologies such as Istio or Linkerd to secure service-to-service communication with mutual TLS (mTLS), fine-grained traffic policies, and identity-based access controls, further strengthening the Zero Trust architecture established in this module.