Legacy Haven University

A Kubernetes cluster with an open east-west path lets any compromised pod impersonate a peer, sniff plaintext, and walk the call graph. A service mesh closes that path by forcing every workload-to-workload hop through mutual TLS (mTLS): each sidecar presents a short-lived X.509 identity, both sides authenticate, and the wire stays encrypted. Istio makes that handshake automatic so application code never touches a private key.

The Problem the Mesh Exists to Solve

Traditional perimeter controls sit at the north-south edge. Firewalls, VPN concentrators, and even a well-tuned ingress gateway inspect traffic that enters or leaves the cluster. They do almost nothing once a request is already inside.

Microservices explode that gap. A single user click can fan out across dozens of pods: API gateway → auth service → inventory → payments → notification. That traffic is east-west. By default Kubernetes sends it as plaintext HTTP or TCP. A pod that an attacker already owns can:

• Sniff credentials and tokens on the node network
• Spoof a service by answering on the same ClusterIP
• Call any other Service object the network policy still allows

CAS-005 Security Architecture treats this as a deperimeterization problem. The exam asks you to replace implicit network trust with explicit subject-object relationships. In a mesh those subjects are workloads, not subnets. The object is another workload. The relationship is a cryptographic handshake, not an allow-list of CIDRs.

NIST SP 800-204A makes the same demand for microservice systems: service proxies must speak only mTLS to one another. Istio is the most common way enterprises implement that recommendation at scale.

If you are mapping this topic onto the rest of the CAS-005 blueprint, start from the cloud-native architecture path in the CompTIA SecurityX (CAS-005) ultimate guide and treat the mesh as the enforcement plane for zero trust inside the cluster.

Control Plane and Data Plane

Istio splits into two planes. Keep them separate in your head; the exam and the architecture both depend on the split.

Control plane (Istiod). One logical service that:

• Acts as the mesh certificate authority
• Pushes configuration to proxies through the xDS APIs
• Watches Kubernetes for Services, Pods, and ServiceAccounts
• Signs certificate signing requests (CSRs) from workload agents

Data plane. An Envoy proxy next to every pod (sidecar mode) or a node-level ztunnel (Ambient mode). Envoy terminates TLS, originates TLS, applies authorization, emits telemetry, and load-balances. The application process talks only to localhost. iptables (or the Istio CNI) steal every inbound and outbound packet and hand it to Envoy.

That local hop is the Policy Enforcement Point (PEP) from NIST SP 800-207 Zero Trust Architecture. Istiod is closer to the Policy Administration / Policy Decision function: it decides which identities exist and which policies bind to them, then ships the result to the PEP.

Ambient mode does not change the security contract. ztunnel still presents a unique X.509 identity per workload, not a shared node identity. The CA must refuse a ztunnel that asks for a SPIFFE ID that is not running on that node. Compromise of one node still does not mint identities for the whole mesh.

How Identity Gets Onto the Wire

Istio does not invent a new identity system. It issues SPIFFE IDs inside X.509 certificates.

A typical identity looks like this:

text

spiffe://cluster.local/ns/payments/sa/billing

Read it left to right:

• Trust domain: cluster.local (or a custom domain you set at install)
• Namespace: payments
• Service account: billing

The URI lives in the Subject Alternative Name (SAN) of a short-lived certificate. Default lifetime is 24 hours. The private key never lands on a persistent volume. The Istio agent generates it in tmpfs, wraps it in a CSR, and authenticates that CSR to Istiod with the Kubernetes ServiceAccount JWT that the kubelet already mounted into the pod.

The flow:

1. Envoy starts and asks the local Istio agent for secrets through the Secret Discovery Service (SDS).
2. The agent creates a key pair and a CSR bound to the pod’s ServiceAccount.
3. Istiod validates the JWT, confirms the ServiceAccount is allowed to hold that SPIFFE ID, and signs the certificate.
4. The agent serves the cert and key to Envoy over a Unix domain socket.
5. When the cert approaches expiry, SDS repeats the cycle. The application never restarts.

This is automated PKI. CAS-005 Security Engineering covers mutual authentication and certificate-based identity; the mesh is the production form of that objective. You are no longer issuing one server certificate per VIP. You are issuing a workload identity per ServiceAccount and rotating it on a clock measured in hours, not years.

The mTLS Handshake Between Two Sidecars

Assume frontend in namespace web calls billing in namespace payments.

1. The frontend container opens a TCP connection to billing.payments.svc.cluster.local.
2. The local iptables rules redirect that socket to the frontend sidecar.
3. Frontend Envoy starts a TLS 1.3 handshake with billing’s Envoy. It sends ClientHello and, because this is mTLS, later presents its own certificate.
4. Billing Envoy sends its certificate and a CertificateRequest.
5. Frontend Envoy sends its certificate plus CertificateVerify (proof it holds the matching private key).
6. Each Envoy checks three things:
   • The peer certificate chains to the mesh CA (Istiod).
   • The SAN SPIFFE ID is well-formed.
   • Secure naming: the SPIFFE ID on the server certificate is allowed to run the Service the client asked for. This stops a stolen billing cert from answering as inventory.
7. Both sides derive session keys. Application bytes now travel as encrypted HTTP inside that tunnel.

The containers themselves still speak plain HTTP on loopback. That is the point. You retrofit encryption and identity onto a codebase that never learned TLS.

Watch the X-Forwarded-Client-Cert header on the server sidecar if you need to prove mTLS actually fired. Absence of that header during a test is a configuration failure, not a “maybe.”

PeerAuthentication: STRICT, PERMISSIVE, DISABLE

mTLS policy is not a cluster-wide on/off switch you flip once. Istio exposes a resource called PeerAuthentication. You attach it at mesh, namespace, or workload scope.

Three modes matter:

• STRICT. The sidecar rejects plaintext. Only mTLS peers connect. This is the target state for production namespaces that hold regulated data.
• PERMISSIVE. The sidecar accepts both mTLS and plaintext. Use this during migration when some clients still lack a sidecar.
• DISABLE. The sidecar speaks plaintext only. Reserve this for break-glass debugging, not for standing policy.

UNSET inherits from the parent scope. A workload with no local policy follows its namespace. A namespace with no policy follows the mesh default.

A safe rollout looks like this:

1. Leave the mesh default at PERMISSIVE so you do not partition traffic the day you inject sidecars.
2. Inject sidecars namespace by namespace.
3. Confirm every client of a given Service now presents a certificate.
4. Flip that namespace to STRICT.
5. Repeat until the mesh default itself can move to STRICT.

Do not jump to STRICT on day one in a brownfield cluster. You will black-hole every job, cron, or ingress path that is not yet in the mesh. CAS-005 performance items reward the engineer who sequences the change, not the one who pastes a “secure” YAML and pages the on-call.

Example namespace policy:

YAML

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: payments
spec:
  mtls:
    mode: STRICT

That single object is microsegmentation at L4 with cryptographic identity instead of IP sets. Kubernetes NetworkPolicy still has a role (it drops unexpected ports before Envoy sees them), but NetworkPolicy alone cannot prove who opened the socket.

What mTLS Does Not Give You

mTLS authenticates the workload identity. It does not authorize the API call.

A valid spiffe://cluster.local/ns/web/sa/frontend certificate only proves the caller is that ServiceAccount. It does not prove the caller may POST /refunds. That second decision is an AuthorizationPolicy.

AuthorizationPolicy binds principals (SPIFFE IDs), source namespaces, and request attributes (method, path, JWT claims) to ALLOW or DENY. Without it, STRICT mTLS creates an encrypted flat network. Every meshed workload can still call every other meshed workload.

Layer them:

CAS-005 frames this as defense in depth plus zero trust subject-object mapping. One control is never the architecture.

mTLS also does not protect:

• Compromised application code inside an already-authenticated pod. Envoy authenticates the sidecar, not the process that sent the HTTP body.
• Data at rest in etcd, PVCs, or object storage.
• North-south clients that terminate at the ingress gateway unless you also require client certificates or tokens there.
• Sidecar escape. If an attacker breaks out of the app container into the pod network namespace, they sit next to Envoy. Hardening the pod (no extra caps, read-only root, dropped NET_ADMIN) still matters.

Treat the sidecar as a privileged peer of the app, not as a magic shield.

Architect-Level Decisions the Exam Expects

Identity granularity. Bind one ServiceAccount per service, not one ServiceAccount per namespace. A shared default ServiceAccount collapses every policy back to “anyone in this namespace.” That defeats the SAN model.

Trust domain. Change cluster.local when you federate meshes or span multiple clusters. Two meshes that share a trust domain and a CA can authenticate each other. Two meshes that do not must use a gateway and an explicit trust bundle.

Certificate lifetime versus blast radius. Shorter TTLs shrink the window after a key leak. They also increase CSR volume on Istiod. Twenty-four hours is the default because it balances both. Drop it only when you have measured control-plane load.

STRICT versus PERMISSIVE as a risk decision. PERMISSIVE is a migration control, not a steady state. Document the exception. CompTIA GRC language calls that an accepted residual risk with an expiration date.

Ambient versus sidecar. Sidecars give L7 policy at every hop and cost RAM per pod. Ambient pushes L4 mTLS to ztunnel and L7 policy to optional waypoint proxies. Choose Ambient when pod density makes sidecar tax unacceptable. Do not choose it to “skip” identity; ztunnel still carries per-workload certs.

Observability is part of the control. Envoy emits certificates used, handshake failures, and connection_security_policy labels. Feed those into the same SIEM or observability stack you use for CAS-005 Security Operations. A mesh you cannot audit is a mesh you cannot defend.

CI/CD injection. Sidecar injection belongs in the pipeline, not as a manual kubectl label. Unsigned or unexpected injection templates are a supply-chain issue under the same domain that covers CI/CD and container orchestration.

How This Maps Onto CAS-005 Objectives

Walk the official domains with the mesh in mind:

• 2.0 Security Architecture — microsegmentation, zero trust, deperimeterization, container orchestration. The mesh is software-defined microsegmentation. Trust moves from the subnet to the SPIFFE ID.
• 2.0 Security Architecture — subject-object relationships. Subject = SPIFFE ID on the client cert. Object = the Service and path being called. The relationship is the AuthorizationPolicy that names both.
• 3.0 Security Engineering — mutual authentication, data in transit, certificate-based identity, automation. Istiod is an internal CA with automated rotation. TLS 1.3 between Envoys is the in-transit control.
• 3.0 Security Engineering — containerization and orchestration. You secure the platform that runs the containers, not only the image.
• 4.0 Security Operations. Handshake failures, expired SDS secrets, and DENY decisions from AuthorizationPolicy are detections, not just config errors.

When a scenario on the exam describes “workloads in a container platform that must authenticate each other without trusting the cluster network,” the expected design is a service mesh with STRICT mTLS and identity-based authorization—not a bigger NetworkPolicy and a longer VPN.

Operating the Control Once It Is Live

After STRICT is on:

• Break-glass plaintext requires a temporary PeerAuthentication exception scoped to one workload, with an owner and a ticket. Never DISABLE at mesh scope to debug one pod.
• Certificate pressure shows up as SDS errors in the Istio agent log and as 503s with UC (upstream connection failure) flags in Envoy. Check Istiod health before you blame the app.
• Multi-cluster east-west needs either a shared CA or a trust bundle. Crossing clusters with only Kubernetes ServiceAccounts and no mesh identity returns you to IP trust.
• Ingress remains a separate PEP. mTLS inside the mesh does not replace client authentication at the edge.

The architecture succeeds when a stolen ClusterIP is useless, a sniffed packet is ciphertext, and a policy change is a YAML commit—not a firewall change window. That is microservice security at the scale CAS-005 expects you to design.