Lab 03 — Secure Amazon EKS Networking

Mission Information

Item	Details
Lab ID	AWS-EKS-SEC-LAB-03
Difficulty	Advanced
Estimated Time	6–8 Hours
AWS Services	Amazon EKS, Amazon VPC, Security Groups, Network ACLs, Route Tables, VPC Flow Logs, Route 53, AWS Load Balancer Controller, CloudWatch
Platform	AWS
Cost	AWS Charges May Apply
Primary Role	Cloud Security Engineer
Supporting Roles	Network Security Engineer, Kubernetes Administrator, Platform Engineer
Module	Amazon EKS Security
Previous Lab	Lab 02 — Secure Amazon EKS Worker Nodes
Next Lab	Lab 04 — Secure IAM Roles for Service Accounts (IRSA)

Mission Scenario

CloudNova Technologies has successfully deployed a secure Amazon EKS cluster with hardened worker nodes.

During a security assessment, the architecture review identified several networking concerns:

Worker nodes communicate more broadly than required.
Kubernetes workloads can communicate freely across namespaces.
No default-deny NetworkPolicies exist.
Internet egress is unrestricted.
Security Groups are overly permissive.
VPC Flow Logs are not centrally monitored.
Cluster endpoint access is broader than organisational standards.
DNS traffic is not governed.
Internal and external workloads share networking boundaries.
No Zero Trust segmentation exists.

The CISO requires the Cloud Security team to redesign the networking architecture following Zero Trust principles.

Your mission is to secure networking across the Amazon EKS environment using AWS and Kubernetes networking controls.

Learning Objectives

By completing this lab, you will learn how to:

Design secure Amazon EKS networking
Review VPC architecture
Secure cluster endpoint access
Harden Security Groups
Review Network ACLs
Configure private worker-node networking
Understand the Amazon VPC CNI
Configure Kubernetes NetworkPolicies
Implement namespace isolation
Restrict ingress traffic
Restrict egress traffic
Secure DNS communication
Configure VPC Flow Logs
Monitor network activity
Implement Zero Trust segmentation
Validate enterprise networking controls

Enterprise Architecture

                    AWS Organization

                           │

                           ▼

                     Production Account

                           │

                           ▼

                      Amazon VPC

 ┌──────────────────────────────────────────────────────────────┐

 │ Public Subnets                                               │

 │                                                              │

 │ Internet Gateway                                             │

 │ NAT Gateway                                                  │

 │ AWS Load Balancer                                            │

 └──────────────────────────────────────────────────────────────┘

 ┌──────────────────────────────────────────────────────────────┐

 │ Private Subnets                                              │

 │                                                              │

 │ Amazon EKS Control Plane                                     │

 │ Managed Node Groups                                          │

 │ Kubernetes Pods                                              │

 │                                                              │

 │ Kubernetes Network Policies                                  │

 │ Security Groups                                               │

 │ Route Tables                                                  │

 │ DNS                                                           │

 └──────────────────────────────────────────────────────────────┘

                 │                     │

                 ▼                     ▼

          VPC Flow Logs          CloudWatch Logs

                 │

                 ▼

          Security Operations Centre

Network Security Objectives

Implement:

Least privilege networking
Zero Trust segmentation
Private networking
Controlled ingress
Controlled egress
Namespace isolation
Workload isolation
Secure DNS
Continuous monitoring
Enterprise governance

Lab Outcomes

After completing this lab you will have:

Reviewed Amazon VPC architecture
Validated subnet design
Hardened Security Groups
Reviewed Network ACLs
Secured cluster endpoint access
Implemented NetworkPolicies
Applied namespace isolation
Restricted pod communication
Configured ingress controls
Implemented egress restrictions
Enabled VPC Flow Logs
Reviewed networking evidence
Produced a network security report

Recommended Folder Structure

lab-03-secure-eks-networking/

├── manifests/
│   ├── default-deny.yaml
│   ├── allow-dns.yaml
│   ├── frontend-policy.yaml
│   ├── backend-policy.yaml
│   ├── ingress-policy.yaml
│   └── egress-policy.yaml
│
├── assessment/
├── evidence/
├── reports/
└── screenshots/

Phase 01 — Network Discovery

Task 01 — Verify AWS Identity

aws sts get-caller-identity

Save:

evidence/aws-identity.json

Task 02 — Review EKS Cluster Networking

aws eks describe-cluster \
--name ghc-secure-eks

Review:

VPC ID
Cluster endpoint
Public access
Private access
Subnets
Security Groups

Task 03 — Review VPC

Collect:

aws ec2 describe-vpcs

Validate:

CIDR ranges
DNS Hostnames
DNS Resolution
IPv4
IPv6 (if used)

Task 04 — Review Subnets

aws ec2 describe-subnets

Verify:

Public subnets
Private subnets
Availability Zones
Route Tables
Public IP assignment

Task 05 — Review Route Tables

Confirm:

Private subnets route through NAT Gateway
Public subnets use Internet Gateway
No unintended routes exist

Phase 02 — Security Groups

Task 06 — Export Security Groups

aws ec2 describe-security-groups \
> evidence/security-groups.json

Task 07 — Review Cluster Security Group

Validate:

Kubernetes API access
Control plane communication
Required inbound ports only
Restricted source CIDRs

Task 08 — Review Worker Node Security Groups

Review:

Node-to-node communication
Control plane communication
Load Balancer access
Internet exposure

Confirm:

No unrestricted inbound access
No unnecessary ports
Least privilege rules

Phase 03 — Network ACL Review

Task 09 — Review Network ACLs

aws ec2 describe-network-acls

Validate:

Stateless filtering
Required ports
Deny unnecessary traffic
Separate public/private controls

Phase 04 — Kubernetes Network Policies

Task 10 — Verify NetworkPolicy Support

kubectl api-resources | grep NetworkPolicy

Task 11 — Create Default Deny Policy

manifests/default-deny.yaml

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

Apply:

kubectl apply -f manifests/default-deny.yaml

Task 12 — Validate Isolation

Deploy two Pods.

Verify they cannot communicate after the default deny policy is applied.

Task 13 — Allow DNS

Create:

policyTypes:
- Egress

Allow DNS to CoreDNS.

Validate:

nslookup kubernetes.default

Task 14 — Allow Frontend to Backend

Create a NetworkPolicy allowing only:

Frontend Pods

↓

Backend Pods

Validate connectivity.

Task 15 — Block Unauthorised Namespace Traffic

Create a second namespace.

Attempt Pod-to-Pod communication.

Verify traffic is blocked.

Phase 05 — Ingress Security

Task 16 — Review AWS Load Balancer

Review:

Internet-facing
Internal
TLS
Target Groups
Listener Rules

Task 17 — Deploy Ingress

Use AWS Load Balancer Controller.

Deploy a sample application.

Validate:

HTTPS
TLS certificate
Security Groups

Task 18 — Restrict Ingress

Allow only approved CIDRs.

Validate denied access from unauthorised networks.

Phase 06 — Egress Governance

Task 19 — Review Internet Access

Determine:

Which Pods require Internet
Which Pods do not

Document business justification.

Task 20 — Create Egress Policy

Allow:

DNS
Required APIs

Block:

All other Internet traffic

Task 21 — Validate Egress Controls

Attempt:

curl https://example.com

Confirm blocked behaviour for restricted Pods.

Phase 07 — DNS Security

Task 22 — Review CoreDNS

kubectl get pods -n kube-system

Validate:

Healthy
Replicas
Resource limits

Task 23 — Secure DNS

Review:

DNS Policies
Search Domains
External Names
DNS access restrictions

Phase 08 — Cluster Endpoint Security

Task 24 — Review Endpoint Access

Check:

Public Access

Private Access

Allowed CIDRs

Recommend:

Private endpoint enabled with restricted public access where operationally appropriate.

Phase 09 — VPC Flow Logs

Task 25 — Enable Flow Logs

Create Flow Logs.

Send logs to:

CloudWatch Logs

Validate:

ACCEPT
REJECT
Source
Destination
Port

Task 26 — Investigate Network Events

Review:

Rejected traffic
Unexpected destinations
Internet access
Lateral movement indicators

Phase 10 — Zero Trust Segmentation

Task 27 — Create Security Zones

Design:

Frontend

↓

Backend

↓

Database

↓

Management

↓

Monitoring

Map namespaces.

Task 28 — Apply Namespace Isolation

Create policies ensuring:

Only required communication exists.
No unrestricted east-west traffic.

Task 29 — Validate Zero Trust

Test:

Allowed flows
Blocked flows
Namespace isolation
DNS
Monitoring

Phase 11 — Monitoring

Task 30 — Review CloudWatch Metrics

Monitor:

Network throughput
Dropped packets
Load Balancer metrics
Flow Logs

Task 31 — Review GuardDuty Findings

Review:

Suspicious connections
Port scanning
Cryptocurrency activity
Unexpected DNS

Task 32 — Collect Evidence

Collect:

VPC
Subnets
Route Tables
Security Groups
Network ACLs
NetworkPolicies
Flow Logs
CloudWatch
GuardDuty
Ingress configuration

Task 33 — Produce Network Security Report

Include:

Current architecture
Findings
Risks
Recommendations
Compliance status

Task 34 — Clean Up

Delete:

Test namespaces
Test Pods
Test NetworkPolicies
Temporary Load Balancers

Enterprise Networking Checklist

Control	Status
VPC reviewed	☐
Subnets validated	☐
Route Tables reviewed	☐
Security Groups hardened	☐
Network ACLs reviewed	☐
Default deny policy implemented	☐
DNS policy configured	☐
Namespace isolation validated	☐
Ingress restricted	☐
Egress restricted	☐
Cluster endpoint secured	☐
VPC Flow Logs enabled	☐
GuardDuty reviewed	☐
Zero Trust implemented	☐
Evidence collected	☐
Final report completed	☐

Risk Classification

Critical

Public Kubernetes API with unrestricted access
No NetworkPolicies
Public worker-node exposure
Unrestricted Security Groups

High

No namespace isolation
Unrestricted egress
Missing Flow Logs
Public Load Balancers without TLS

Medium

Weak DNS governance
Missing monitoring
Broad internal communication

Low

Documentation improvements
Tagging inconsistencies

Skills Developed

By completing this lab, you will be able to:

Secure Amazon EKS networking
Design Zero Trust Kubernetes networking
Configure NetworkPolicies
Harden Security Groups
Review Network ACLs
Secure cluster endpoints
Restrict ingress and egress traffic
Enable VPC Flow Logs
Investigate network events
Produce enterprise network security reports

Knowledge Check

Question 1

Why should Kubernetes environments use a default-deny NetworkPolicy?

Answer: It blocks all traffic by default, allowing only explicitly approved communication between workloads.

Question 2

Why should worker nodes be deployed in private subnets?

Answer: Private subnets reduce direct internet exposure and help enforce controlled network access.

Question 3

What is the purpose of Amazon VPC Flow Logs?

Answer: They record network traffic metadata, helping with monitoring, troubleshooting, and security investigations.

Question 4

Why should internet egress be restricted?

Answer: Restricting egress reduces data-exfiltration risk and limits communication with unapproved external destinations.

Question 5

How do Kubernetes NetworkPolicies support Zero Trust?

Answer: They explicitly define allowed traffic between Pods and namespaces, preventing unnecessary lateral movement.

Lab Summary

In this lab, you secured the Amazon EKS networking layer by implementing enterprise-grade controls across AWS networking and Kubernetes networking.

You reviewed and configured:

Amazon VPC architecture
Public and private subnet design
Security Groups
Network ACLs
Kubernetes NetworkPolicies
Namespace isolation
Ingress security
Egress governance
DNS security
Cluster endpoint access
Amazon VPC Flow Logs
Zero Trust network segmentation

These controls help reduce attack surface, limit lateral movement, improve visibility into network activity, and establish a strong networking foundation for secure Kubernetes workloads.

What’s Next?

Next Lab: Lab 04 — Secure IAM Roles for Service Accounts (IRSA)

In the next lab, you will implement IAM Roles for Service Accounts (IRSA), configure OIDC identity federation, assign least-privilege AWS permissions to Kubernetes workloads, remove long-lived credentials, validate workload identity, and enforce enterprise identity governance.