Lesson 08 — East-West Traffic Protection
Learning Objectives
Section titled “Learning Objectives”By the end of this lesson, you will be able to:
- Understand East-West traffic in Kubernetes
- Differentiate East-West and North-South traffic
- Understand why East-West traffic is a major attack vector
- Learn how attackers perform lateral movement
- Secure East-West traffic using Network Policies
- Protect service-to-service communication using Service Mesh and Mutual TLS (mTLS)
- Design enterprise East-West security architectures
- Apply enterprise best practices
Why This Matters
Section titled “Why This Matters”Modern applications are built using hundreds or even thousands of microservices.
While organizations spend significant effort protecting Internet-facing applications, most cyber attacks occur after an attacker gains an initial foothold.
Once inside a Kubernetes cluster, attackers attempt to move laterally by accessing:
- APIs
- Databases
- Authentication services
- Secrets
- Internal applications
- Monitoring systems
This internal communication is called East-West traffic.
Without proper controls, attackers can move from one compromised workload to another until they gain access to critical business systems.
Protecting East-West traffic is a fundamental component of Zero Trust security.
What is East-West Traffic?
Section titled “What is East-West Traffic?”East-West traffic refers to communication between workloads inside the same environment.
Examples include:
- Pod to Pod
- Service to Service
- Namespace to Namespace
- Node to Node
- Cluster to Cluster
Example:
Frontend Pod
↓
API Pod
↓
Payment Service
↓
DatabaseAll of this communication occurs internally.
What is North-South Traffic?
Section titled “What is North-South Traffic?”North-South traffic refers to communication entering or leaving the Kubernetes cluster.
Example:
Internet
↓
Application Load Balancer
↓
Ingress Controller
↓
Frontend ApplicationNorth-South traffic connects users with applications.
East-West vs North-South
Section titled “East-West vs North-South”| East-West | North-South |
|---|---|
| Internal communication | External communication |
| Pod-to-Pod | Internet-to-Cluster |
| Service-to-Service | Client-to-Application |
| Higher attack frequency | Easier to monitor |
| Lateral movement | Initial access |
Both traffic flows require strong security controls.
Why Attackers Target East-West Traffic
Section titled “Why Attackers Target East-West Traffic”After compromising a single Pod, attackers rarely stop there.
Instead they attempt to:
- Discover additional services
- Locate databases
- Find Secrets
- Access internal APIs
- Escalate privileges
- Reach Kubernetes control components
Example:
Compromised Pod
↓
API
↓
Database
↓
Secrets
↓
Critical ApplicationsWithout segmentation, one compromised workload can lead to complete cluster compromise.
Lateral Movement
Section titled “Lateral Movement”Lateral movement occurs when an attacker moves from one system to another after initial compromise.
Example:
Web Application
↓
API
↓
Order Service
↓
Payment Service
↓
DatabaseEvery successful step increases the impact of the attack.
Zero Trust East-West Networking
Section titled “Zero Trust East-West Networking”Zero Trust assumes:
Internal traffic should never be trusted automatically.
Instead of:
Internal Traffic
↓
TrustedUse:
Request
↓
Authenticate
↓
Authorise
↓
Encrypt
↓
AllowEvery request is verified regardless of its source.
East-West Security Layers
Section titled “East-West Security Layers”Enterprise Kubernetes environments secure East-West traffic using multiple layers.
Network Policies
↓
Service Mesh
↓
Mutual TLS
↓
Authorization Policies
↓
RBAC
↓
IAM
↓
Continuous MonitoringEach layer strengthens security and reduces the attack surface.
Network Policies
Section titled “Network Policies”Network Policies provide the first layer of East-West protection.
Example:
Frontend
↓
API
✓ Allowed
-------------------
Frontend
↓
Database
✗ DeniedOnly approved communication paths are permitted.
Mutual TLS (mTLS)
Section titled “Mutual TLS (mTLS)”Mutual TLS ensures every service verifies the identity of the service it communicates with.
Example:
Service A
↓
Certificate Verification
↓
Encrypted Connection
↓
Certificate Verification
↓
Service BIf identity verification fails, communication is denied.
Service Mesh
Section titled “Service Mesh”A Service Mesh such as Istio or Linkerd secures East-West communication.
Capabilities include:
- Automatic mTLS
- Identity verification
- Authorization Policies
- Traffic encryption
- Service authentication
- Traffic observability
- Policy enforcement
The Service Mesh protects internal application communication without requiring application code changes.
Identity-Based Networking
Section titled “Identity-Based Networking”Traditional networks trust IP addresses.
Cloud-native environments trust identities.
Instead of:
10.0.5.18Service Mesh verifies:
payment-service
↓
Verified Identity
↓
order-serviceBecause Pods are frequently recreated, identities are far more reliable than IP addresses.
Namespace Isolation
Section titled “Namespace Isolation”Namespaces provide logical security boundaries.
Example:
Finance Namespace
↓
Finance Database
✓ Allowed
--------------------
HR Namespace
↓
Finance Database
✗ DenallowedNamespaces reduce the blast radius of security incidents.
Micro-Segmentation
Section titled “Micro-Segmentation”Micro-segmentation divides applications into secure communication zones.
Example:
Frontend
↓
API
↓
Payment
↓
DatabaseBlocked communication:
Frontend
↓
Database
✗ DeniedOnly required communication paths are allowed.
East-West Security Architecture
Section titled “East-West Security Architecture”Frontend
↓
Network Policy
↓
Envoy Sidecar
↓
Mutual TLS
↓
API
↓
Envoy Sidecar
↓
DatabaseEvery internal request is:
- Authenticated
- Encrypted
- Authorised
- Logged
Amazon EKS East-West Architecture
Section titled “Amazon EKS East-West Architecture”Amazon EKS
↓
Namespaces
↓
Network Policies
↓
Istio
↓
Envoy Sidecars
↓
Mutual TLS
↓
Application PodsAmazon EKS combines Kubernetes networking with Service Mesh technologies to secure internal communications.
Enterprise Example
Section titled “Enterprise Example”A multinational bank operates over 600 microservices within Amazon EKS.
Security architecture includes:
- Network Policies
- Istio
- Automatic Mutual TLS
- Namespace isolation
- Authorization Policies
- Continuous monitoring
- CloudWatch integration
Communication flow:
Customer Portal
↓
API Gateway
↓
Payment Service
↓
Fraud Detection
↓
Customer DatabaseEvery service verifies the identity of the next service before communication is allowed.
This architecture supports Zero Trust principles and regulatory compliance.
Common East-West Security Risks
Section titled “Common East-West Security Risks”Cloud Security Engineers frequently identify:
- Missing Network Policies
- Disabled Mutual TLS
- Overly permissive communication
- Flat network architecture
- Missing Namespace isolation
- Unencrypted service communication
- Excessive service permissions
- Poor Service Mesh configuration
- Lack of traffic monitoring
- Identity spoofing
These weaknesses allow attackers to move laterally through the environment.
Enterprise Monitoring
Section titled “Enterprise Monitoring”Security teams should monitor:
- East-West traffic volume
- Failed Mutual TLS authentication
- Authorization Policy violations
- Unexpected service communication
- Cross-Namespace traffic
- Lateral movement indicators
- Certificate failures
- Sidecar health
- Network Policy violations
- Service identity changes
Telemetry from Istio, Linkerd, Envoy, Amazon CloudWatch, Prometheus and Grafana provides deep visibility into internal communications.
East-West Security Design Strategy
Section titled “East-West Security Design Strategy”A recommended enterprise approach:
Step 1
↓
Segment Applications
↓
Step 2
↓
Deploy Network Policies
↓
Step 3
↓
Implement Service Mesh
↓
Step 4
↓
Enable Mutual TLS
↓
Step 5
↓
Apply Authorization Policies
↓
Step 6
↓
Monitor Internal Traffic
↓
Step 7
↓
Review Communication Paths RegularlyThis layered approach significantly reduces the risk of lateral movement.
Best Practices
Section titled “Best Practices”As a Kubernetes Security Engineer:
- Implement a Zero Trust networking model.
- Enable Mutual TLS for all service-to-service communication.
- Use Network Policies to enforce least-privilege networking.
- Isolate workloads using Namespaces.
- Implement micro-segmentation between applications.
- Authenticate workloads using Service Mesh identities.
- Continuously monitor East-West traffic.
- Audit communication paths regularly.
- Investigate unexpected service communication immediately.
- Keep Service Mesh components updated.
Strong East-West protection limits the impact of compromised workloads and improves the overall security posture of Kubernetes clusters.
Real-World Scenario
Section titled “Real-World Scenario”A vulnerable inventory application in an Amazon EKS cluster is compromised through a remote code execution vulnerability.
The attacker attempts to:
- Access the payment service
- Reach customer databases
- Connect to the Kubernetes API
- Discover additional workloads
However, the organisation has implemented:
- Network Policies
- Namespace isolation
- Istio Service Mesh
- Automatic Mutual TLS
- Authorization Policies
- Continuous traffic monitoring
Every unauthorised request is blocked because:
- The compromised workload lacks permission.
- Service identities cannot be spoofed.
- Communication is encrypted and authenticated.
- Security teams receive immediate alerts through monitoring dashboards.
The attacker is unable to move laterally, and the incident is contained to a single compromised Pod.
Key Takeaways
Section titled “Key Takeaways”After completing this lesson, you should understand:
- What East-West traffic is
- How it differs from North-South traffic
- Why attackers target internal communication
- The importance of preventing lateral movement
- How Network Policies protect East-West traffic
- How Service Mesh and Mutual TLS strengthen internal security
- The role of micro-segmentation and Namespace isolation
- Enterprise monitoring and best practices
East-West traffic protection is a cornerstone of Kubernetes security. By combining Network Policies, Service Mesh, Mutual TLS, identity-based networking and continuous monitoring, organisations can implement Zero Trust networking and dramatically reduce the risk of lateral movement within Amazon EKS environments.
Knowledge Check
Section titled “Knowledge Check”Question 1
Section titled “Question 1”What is East-West traffic in Kubernetes?
- A. Traffic entering the cluster from the Internet
- B. Traffic between workloads inside the Kubernetes environment
- C. Traffic between AWS Regions
- D. Traffic between Availability Zones only
Answer: B
Question 2
Section titled “Question 2”Which attack technique is most closely associated with East-West traffic?
- A. SQL Injection
- B. Lateral Movement
- C. DNS Amplification
- D. Cross-Site Scripting (XSS)
Answer: B
Question 3
Section titled “Question 3”Which Kubernetes feature is commonly used to restrict Pod-to-Pod communication?
- A. ReplicaSets
- B. Network Policies
- C. Persistent Volumes
- D. Storage Classes
Answer: B
Question 4
Section titled “Question 4”Which technology automatically encrypts and authenticates service-to-service communication?
- A. kube-proxy
- B. Mutual TLS (mTLS)
- C. CoreDNS
- D. Amazon Route 53
Answer: B
Question 5
Section titled “Question 5”Which of the following is considered an enterprise best practice for protecting East-West traffic?
- A. Allow unrestricted communication between all workloads.
- B. Trust all internal traffic by default.
- C. Implement Network Policies, Service Mesh, Mutual TLS and continuous monitoring.
- D. Disable Namespace isolation to simplify networking.
Answer: C
What’s Next?
Section titled “What’s Next?”In the next lesson, you will learn about Zero Trust Networking, exploring how enterprise organisations apply Zero Trust principles across Amazon EKS by combining workload identity, continuous verification, least-privilege access, Service Mesh, Network Policies, IAM, RBAC and policy enforcement to build resilient cloud-native environments.
➡️ Next Lesson: Lesson 09 — Zero Trust Networking