Lesson 03 — Network Policies

Learning Objectives

By the end of this lesson, you will be able to:

Understand what Kubernetes Network Policies are
Learn why Network Policies are essential for Kubernetes security
Understand ingress and egress traffic control
Implement micro-segmentation
Apply Zero Trust networking principles
Understand Network Policy architecture in Amazon EKS
Identify common Network Policy security risks
Apply enterprise best practices

Why This Matters

By default, Kubernetes networking is highly permissive.

This means:

Every Pod can communicate with every other Pod.
Applications can freely communicate across Namespaces.
Malware can move laterally.
Attackers can discover internal services.
Sensitive applications become exposed.

Imagine an attacker compromises a web application.

Without Network Policies, the attacker may be able to:

Access databases
Scan the Kubernetes cluster
Discover APIs
Reach monitoring systems
Attack internal services

Network Policies help prevent this by enforcing least privilege networking.

What are Network Policies?

A Network Policy is a Kubernetes resource that controls how Pods communicate with:

Other Pods
Namespaces
External networks (depending on the CNI)

Rather than allowing unrestricted communication, Network Policies specify exactly who can communicate with whom.

Kubernetes Networking Without Network Policies

Frontend Pod

↓

API Pod

↓

Database Pod

↓

Monitoring

↓

Logging

↓

Every Pod

Every workload can communicate freely.

This increases the attack surface.

Kubernetes Networking With Network Policies

Frontend Pod

↓

API Pod

↓

Database Pod

✗

Monitoring

✗

Logging

Only authorised communication is allowed.

Everything else is denied.

Default Kubernetes Behaviour

Without Network Policies:

Pod A

↓

Pod B

↓

Allowed

Pod A

↓

Database

↓

Allowed

Pod A

↓

Monitoring

↓

Allowed

Everything is allowed by default.

Zero Trust Networking

Network Policies support a Zero Trust model.

Zero Trust assumes:

Never trust network traffic simply because it originates inside the Kubernetes cluster.

Every communication request should be explicitly authorised.

Request

↓

Evaluate Policy

↓

Allow

or

Deny

Micro-Segmentation

Micro-segmentation divides applications into secure network zones.

Example:

Frontend

↓

API

↓

Database

Blocked:

Frontend

↓

Database

✗ Denied

Only required communication paths are permitted.

Network Policy Components

A Network Policy consists of:

Pod Selector
Policy Types
Ingress Rules
Egress Rules

Together they determine which traffic is permitted.

Pod Selector

A Pod Selector identifies which Pods the policy applies to.

Example:

Policy

↓

Frontend Pods

Only matching Pods are affected by the policy.

Policy Types

Kubernetes supports two primary policy types.

Policy Type	Controls
Ingress	Incoming traffic
Egress	Outgoing traffic

Policies may define either or both.

Ingress Policies

Ingress policies control who can connect to a Pod.

Example:

Frontend

↓

API

✓ Allowed

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

Unknown Pod

↓

API

✗ Denied

Only approved sources can access the API.

Egress Policies

Egress policies control where a Pod may connect.

Example:

Application

↓

Amazon RDS

✓ Allowed

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

Application

↓

Unknown Internet Host

✗ Denied

Restricting outbound communication reduces data exfiltration risks.

Namespace Isolation

Network Policies can isolate entire Namespaces.

Finance Namespace

↓

Finance Database

✓ Allowed

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

HR Namespace

↓

Finance Database

✗ Denied

Namespaces become logical security boundaries.

Label-Based Policies

Policies use Kubernetes labels rather than IP addresses.

Example:

role=frontend

↓

Allowed

↓

role=api

Benefits include:

Dynamic
Scalable
Cloud-native
Easy to maintain

Labels continue to work even when Pods are recreated.

Default Deny Policy

Enterprise clusters commonly begin with a Default Deny policy.

Every Pod

↓

All Traffic

↓

Denied

Administrators then create explicit allow rules.

This is considered a security best practice.

Example Network Policy Design

Internet

↓

Ingress Controller

↓

Frontend

↓

API

↓

Database

Allowed:

Ingress → Frontend
Frontend → API
API → Database

Blocked:

Frontend → Database
Database → Internet
Monitoring → Database
Unknown Pods → API

Network Policies in Amazon EKS

Amazon EKS supports Kubernetes Network Policies when using compatible networking capabilities such as the Amazon VPC CNI Network Policy feature or CNIs like Calico or Cilium.

Example architecture:

Amazon VPC

↓

Amazon EKS

↓

Amazon VPC CNI

↓

Network Policies

↓

Pods

Network Policies provide fine-grained control over workload communication within the cluster.

Enterprise Example

A healthcare provider operates an Amazon EKS cluster hosting several applications.

Architecture:

Patient Portal

↓

Patient API

↓

Medical Database

↓

AWS Secrets Manager

Network Policies allow:

Patient Portal → Patient API
Patient API → Medical Database

Blocked:

Patient Portal → Database
Monitoring → Database
Unauthorised Namespaces
Unknown Pods

This design helps protect sensitive patient information.

Common Network Policy Security Risks

Cloud Security Engineers frequently identify:

No Network Policies
Missing default deny rules
Overly broad allow rules
Cross-namespace access
Unrestricted egress traffic
Incorrect Pod labels
Missing Namespace isolation
Policies that are never tested
Overlapping policies
Forgotten legacy policies

These weaknesses increase the risk of lateral movement within the cluster.

Enterprise Monitoring

Security teams should monitor:

Network Policy changes
Policy violations
Blocked connections
Cross-namespace traffic
Unusual east-west communication
Failed DNS requests
Egress traffic
New Namespaces
Label changes
Pod communication patterns

Observability platforms such as Amazon CloudWatch, GuardDuty, Calico Enterprise or Cilium Hubble can help visualise and monitor network traffic.

Network Policy Design Strategy

A recommended enterprise approach:

Step 1

↓

Create Default Deny

↓

Step 2

↓

Allow DNS

↓

Step 3

↓

Allow Required Services

↓

Step 4

↓

Restrict Egress

↓

Step 5

↓

Monitor

↓

Step 6

↓

Review Regularly

Policies should evolve alongside applications.

Network Policies and Zero Trust

Zero Trust networking combines:

Network Policies
RBAC
Service Accounts
IRSA
Pod Security Standards
Service Mesh
Identity-based access

Example:

Identity

↓

Authentication

↓

Authorisation

↓

Network Policy

↓

Service

↓

Pod

Security is enforced at multiple layers.

Best Practices

As a Kubernetes Security Engineer:

Implement a default deny policy in every production Namespace.
Allow only the minimum required ingress and egress traffic.
Use labels rather than IP addresses.
Isolate workloads using Namespaces and Network Policies.
Restrict outbound internet access wherever possible.
Review Network Policies whenever applications change.
Test policies before deploying to production.
Monitor blocked and unexpected traffic.
Use compatible CNI plugins that support Network Policies.
Follow Zero Trust networking principles.

Well-designed Network Policies significantly reduce the attack surface of Kubernetes clusters.

Real-World Scenario

An e-commerce company deploys several microservices on Amazon EKS.

A vulnerable product catalogue service is compromised through a web application vulnerability.

Without Network Policies, the attacker:

Scans the cluster
Discovers internal APIs
Connects directly to the payment database
Attempts credential theft

Following the incident, the organisation implements:

Default deny policies
Namespace isolation
Ingress and egress restrictions
Label-based Network Policies
Continuous traffic monitoring

When a similar attack occurs later, the compromised Pod cannot communicate beyond its authorised services, preventing lateral movement and reducing the impact of the attack.

Key Takeaways

After completing this lesson, you should understand:

What Kubernetes Network Policies are
Why default Kubernetes networking is permissive
How ingress and egress policies work
The importance of micro-segmentation
How Network Policies support Zero Trust
Namespace isolation techniques
Enterprise Network Policy design
Common security risks and best practices

Network Policies are one of the most effective security controls available in Kubernetes. By explicitly defining which workloads may communicate, organisations can prevent lateral movement, enforce Zero Trust networking and significantly strengthen the security of Amazon EKS environments.

Knowledge Check

Question 1

What is the primary purpose of a Kubernetes Network Policy?

A. Schedule Pods
B. Control network communication between Pods and other network endpoints
C. Store Secrets
D. Create Load Balancers

Answer: B

Question 2

By default, how does Kubernetes handle Pod-to-Pod communication?

A. All traffic is denied
B. Only traffic within the same Namespace is allowed
C. All Pods can communicate unless restricted by a Network Policy
D. Only traffic through Services is permitted

Answer: C

Question 3

Which two traffic directions can a Network Policy control?

A. North and South
B. Internal and External
C. Ingress and Egress
D. TCP and UDP

Answer: C

Question 4

What is considered an enterprise best practice when implementing Network Policies?

A. Allow all traffic by default
B. Start with a default deny policy and explicitly allow required communication
C. Disable DNS communication
D. Use Pod IP addresses instead of labels

Answer: B

Question 5

Which security principle is reinforced by Kubernetes Network Policies?

A. High Availability
B. Zero Trust Networking
C. Auto Scaling
D. Immutable Infrastructure

Answer: B

What’s Next?

In the next lesson, you will learn about Ingress Controllers, exploring how Kubernetes securely exposes applications to external users, manages HTTP and HTTPS traffic, performs SSL/TLS termination, integrates with AWS Application Load Balancers (ALBs), and protects applications using enterprise-grade ingress security controls.

➡️ Next Lesson: Lesson 04 — Ingress Controllers