Lab 05 — Service Mesh Security

Mission Information

Item	Details
Lab ID	K8S-NET-LAB-05
Difficulty	Advanced
Estimated Time	4–5 Hours
Environment	Kubernetes Cluster (Amazon EKS / Azure AKS / Google GKE / kind)
Platform	Kubernetes
Service Mesh	Istio (Primary) / Linkerd (Alternative)
Cost	Free (kind) / Cloud Charges Apply
Primary Role	Kubernetes Security Engineer
Module	Module 03 — Kubernetes Network Security & Zero Trust
Previous Lab	Lab 04 — Implement Zero Trust Networking

Mission Scenario

CloudNova Technologies has successfully implemented:

Kubernetes Network Policies
Namespace Isolation
Secure Ingress
Zero Trust Networking

Although these controls significantly improved network security, a recent security assessment identified another concern.

Application traffic between internal microservices remains unencrypted.

An attacker with access to the underlying network infrastructure could potentially:

Capture sensitive API requests
Intercept authentication tokens
Perform man-in-the-middle attacks
Observe service communication
Replay requests

The Cloud Security Architecture team has decided to implement a Service Mesh to secure all service-to-service communication using Mutual TLS (mTLS) and workload identities.

As the Kubernetes Security Engineer, your objective is to deploy a Service Mesh, enable automatic mTLS, implement traffic policies, and verify encrypted communication between workloads.

Learning Objectives

By completing this lab, you will learn how to:

Understand Service Mesh architecture
Deploy Istio
Understand Linkerd architecture
Enable automatic sidecar injection
Configure mutual TLS (mTLS)
Secure service-to-service communication
Implement workload identities
Configure traffic security policies
Validate encrypted communication
Perform an enterprise Service Mesh security assessment

Enterprise Architecture

                   Internet
                       │
                  HTTPS (TLS)
                       │
               Ingress Gateway
                       │
        ┌──────────────┼──────────────┐
        │                             │
   Frontend Pod                 Backend Pod
        │                             │
        │<------ mTLS Encrypted ----->│
        │                             │
        └──────────────┬──────────────┘
                       │
                 PostgreSQL Service
                       │
             mTLS Encrypted Traffic

Lab Outcomes

By the end of this lab, you will have:

Installed Istio
Enabled automatic sidecar injection
Deployed applications with Envoy proxies
Enabled strict mutual TLS
Validated encrypted service communication
Configured traffic security policies
Verified workload identities
Produced an enterprise Service Mesh assessment report

Prerequisites

Before starting:

Complete Labs 01–04
Kubernetes cluster running
kubectl installed
Istio CLI (istioctl) installed
Basic understanding of Kubernetes networking

Tools Used

Tool	Purpose
kubectl	Kubernetes administration
istioctl	Install and manage Istio
Docker Desktop	Local runtime
kind	Local Kubernetes
Visual Studio Code	YAML editing
Git Bash / PowerShell	Command execution

Enterprise Background

Network Policies control who may communicate.

Service Mesh controls how communication occurs.

A Service Mesh provides:

Automatic encryption
Mutual authentication
Workload identity
Fine-grained traffic policies
Traffic observability
Retry logic
Circuit breaking
Distributed tracing

Rather than modifying application code, these capabilities are delivered through sidecar proxies.

Service Mesh Components

               Kubernetes Cluster

            Application Container

                    │

                    ▼

              Envoy Sidecar Proxy

                    │

              mTLS Encryption

                    │

              Envoy Sidecar Proxy

                    ▼

            Application Container

Task 01 — Verify Cluster Health

Verify cluster access.

kubectl cluster-info

kubectl get nodes

Confirm:

Cluster accessible
Nodes Ready

Task 02 — Install Istio

Install the default Istio profile.

istioctl install

Verify installation.

kubectl get pods -n istio-system

Expected components:

istiod
ingressgateway
base components

Task 03 — Enable Automatic Sidecar Injection

Label the application namespace.

kubectl label namespace default istio-injection=enabled

Verify:

kubectl get namespace --show-labels

Task 04 — Deploy Sample Applications

Deploy:

Frontend
Backend
PostgreSQL

Verify Pods.

kubectl get pods

Inspect a Pod.

kubectl describe pod <pod-name>

Confirm:

Each Pod now contains:

Application container
Envoy sidecar

Task 05 — Verify Sidecar Injection

List containers.

kubectl get pod <pod-name> \
-o jsonpath="{.spec.containers[*].name}"

Expected:

frontend istio-proxy

Repeat for all workloads.

Task 06 — Enable Strict Mutual TLS

Create a PeerAuthentication policy.

Configure:

mtls:
  mode: STRICT

Apply the policy.

Verify:

kubectl get peerauthentication

Task 07 — Validate Encrypted Communication

Verify communication.

Frontend

↓

Backend

↓

Database

Expected:

Communication succeeds using mTLS.

Review proxy configuration.

istioctl proxy-status

Confirm:

Connected
Synced

Task 08 — Validate Workload Identity

Inspect workload identity.

istioctl proxy-config bootstrap <pod-name>

Review:

SPIFFE identity
Trust domain
Certificates

Discuss:

How workload identity supports Zero Trust.

Task 09 — Configure Authorization Policy

Create an AuthorizationPolicy.

Allow only:

Frontend

↓

Backend

Deny:

Random workloads

↓

Backend

Validate communication.

Task 10 — Simulate a Security Incident

Scenario:

An attacker deploys a malicious Pod.

Attempt:

Call backend APIs
Access PostgreSQL
Connect to monitoring

Expected:

Denied by Service Mesh policies.

Task 11 — Review Service Mesh Configuration

Review:

kubectl get peerauthentication

kubectl get authorizationpolicy

kubectl get destinationrule

kubectl get gateway

kubectl get virtualservice

Review:

Traffic policies
Security policies
Encryption

Task 12 — Validate Zero Trust Controls

Evaluate:

mTLS enabled
Workload identity
Authorization policies
Sidecar injection
Namespace isolation
Network Policies

Classify:

Compliant
Requires Improvement
Non-Compliant

Task 13 — Enterprise Service Mesh Assessment

Review:

Control	Status
Istio Installed
Sidecar Injection Enabled
mTLS Enabled
Workload Identity Verified
Authorization Policies Applied
Traffic Encrypted
Zero Trust Implemented
Policies Validated

Task 14 — Produce an Assessment Report

Document:

Cluster:

Service Mesh:

Namespaces:

Applications:

Sidecar Injection:

mTLS Status:

Authorization Policies:

Traffic Encryption:

Security Findings:

Recommendations:

Overall Service Mesh Security Rating:

Task 15 — Evidence Collection

Capture evidence for:

Istio installation
Pods
Sidecar containers
PeerAuthentication
AuthorizationPolicy
Proxy status
Workload identities
mTLS validation
Assessment report

Task 16 — Clean Up

Remove:

Sample applications
Test policies
Test namespace (optional)

If this is a dedicated lab cluster, uninstall Istio.

istioctl uninstall

Verify:

kubectl get pods -n istio-system

Skills Developed

By completing this lab, you will be able to:

Deploy and manage Istio
Enable automatic sidecar injection
Configure mutual TLS
Secure service-to-service communication
Implement workload identities
Configure Service Mesh authorization
Validate encrypted traffic
Strengthen Zero Trust networking
Assess Service Mesh deployments
Troubleshoot Service Mesh security issues

Knowledge Check

Question 1

What is the primary purpose of a Service Mesh?

A. Schedule Kubernetes Pods
B. Secure and manage service-to-service communication
C. Create Persistent Volumes
D. Replace Kubernetes Services

Answer: B

Question 2

Which Istio component is injected into application Pods?

A. kube-proxy
B. Envoy sidecar proxy
C. CoreDNS
D. etcd

Answer: B

Question 3

What is the purpose of mutual TLS (mTLS)?

A. Encrypt only client traffic.
B. Encrypt traffic and authenticate both communicating workloads.
C. Replace Kubernetes RBAC.
D. Encrypt Persistent Volumes.

Answer: B

Question 4

Which identity standard does Istio commonly use for workloads?

A. OAuth 2.0
B. SPIFFE
C. LDAP
D. Kerberos

Answer: B

Question 5

Why are Service Meshes commonly deployed in enterprise Kubernetes environments?

A. To increase CPU resources.
B. To provide encryption, workload identity, traffic control, observability, and Zero Trust communication without changing application code.
C. To replace Deployments.
D. To eliminate the need for Services.

Answer: B

Lab Summary

In this lab, you deployed a Service Mesh using Istio and secured service-to-service communication with mutual TLS (mTLS), workload identities, and fine-grained authorization policies. You enabled automatic sidecar injection, verified encrypted traffic between workloads, and ensured that only authorised services could communicate.

These capabilities represent a mature Zero Trust networking implementation and are widely adopted in enterprise Kubernetes platforms to protect microservices, improve observability, enforce identity-based security policies, and secure application communication without requiring changes to application code.

What’s Next?

➡️ Runbook 01 — Kubernetes Network Security Health Assessment

In the next runbook, you will perform a comprehensive operational review of Kubernetes networking by validating Network Policies, Ingress Controllers, Service Mesh configuration, TLS enforcement, namespace isolation, and Zero Trust controls to ensure the platform remains secure, resilient, and compliant with enterprise security standards.