Zero Trust for APIs: From Edge to Mesh with Istio

Securing APIs at the edge gateway is standard practice, but what happens once that traffic enters your cluster? Too often, internal networks are treated as trusted zones, leaving service-to-service communication vulnerable. This session tackles that security gap head-on, demonstrating how to build a true Zero Trust network for your APIs using Istio.

We will move beyond perimeter security and implement a defense-in-depth strategy directly within the service mesh. Starting with an API call secured by a JWT at the Ingress Gateway, we will follow its journey through the mesh and apply layered security controls.

1. ZERO TRUST FOR APIS: FROM EDGE TO MESH WITH ISTIO Mofesola Babalola Staff SRE Hannah Olukoye Engineering Manager
2. SESSION ROADMAP 01 02 03 04 THE SRE'S PROBLEM THE SOLUTION: "NEVER TRUST, ALWAYS VERIFY" THE PLATFORM ENGINE: ISTIO CASE STUDY: ZERO TRUST IN ACTION Moving from perimeter gates to persistent cryptographic validation. Analyzing how Ambient architecture simplifies trust implementation. Simulating active attacks and their impact in production Exposing security weaknesses in the traditional setups
3. THE SRE'S SECURITY PROBLEM
4. THE "CASTLE-AND-MOAT" PROBLEM THE SECURITY ILLUSION Inside standard corporate networks, "East-West" data traffic travels completely unencrypted and unverified by default.
5. UNSECURED "EAST-WEST" TRAFFIC LATERAL MOVEMENT THREAT Exposing Common Mesh Vulnerabilities ▪ No Encryption: Packet payloads travel in unencrypted cleartext across adjacent SRE nodes. ▪ Spoofable IPs: Intruders spoof basic network identities to trick traditional access controllers. ▪ No Audits: SRE operators have zero visibility into unauthorized internal network calls.
6. THE PLATFORM: ISTIO AMBIENT MESH
7. INTRODUCING AMBIENT MESH OLD WAY: SIDECAR – Every application pod is injected with a complex Envoy proxy container. NEW WAY: ISOLATED LAYER 4 & LAYER 7 – ztunnel: Handles mTLS transport identity cleanly at the node level. – Waypoint: Scales L7 policy routing independently of app containers.
8. NEVER TRUST, ALWAYS VERIFY
9. ZERO TRUST: 3 PILLARS 01 02 03 VERIFIABLE IDENTITY AUTHENTICATION EXPLICIT AUTH Who are you? (S2S) Who is the end user? (U2S) What are you allowed to do?
10. PILLAR 1: VERIFIABLE IDENTITY (MTLS) ▪ SPIFFE Identity: Workloads are assigned secure cryptographical identities cleanly. ▪ Transparent: Cryptographic handshakes run automatically inside kernel space. ▪ Prevention: Instantly blocks unencrypted connection attacks and IP spoofing. peer-auth.yaml apiVersion: security.istio.io/v1 kind: PeerAuthentication metadata: name: default-strict-mtls namespace: istio-system spec: mtls: mode: STRICT
11. PILLAR 2: VERIFIABLE AUTHENTICATION request-auth.yaml apiVersion: security.istio.io/v1 kind: RequestAuthentication metadata: name: jwt-on-waypoint spec: selector: matchLabels: app: customer-api jwtRules: - issuer: "https://issuer.example" jwksUri: "https://issuer/jwks" ▪ Enforcement Point: Executed cleanly at the Waypoint L7 routing boundary. ▪ Safe Verification: Validates user signatures, token expiration, and trusted issuers automatically. ▪ Developers Win: Avoid repeating complex verify_jwt() functions in app code bases.
12. PILLAR 3: EXPLICIT AUTHORIZATION ▪ Enforcement: Intercepted and parsed by the Layer-7 Waypoint Envoy proxy engine. ▪ Granularity: Restrict queries down to namespaced scopes, verified service-accounts, and HTTP verbs. ▪ Defaults: Enforce STRICT lockdown patterns: if it is not explicitly whitelisted, it is instantly blocked. auth-policy.yaml apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: name: customer-api-lockdown spec: action: ALLOW rules: - from: - source: principals: - "cluster.local/ns/prod/sa/web"
13. CASE STUDY: ZERO TRUST PILLARS IN ACTION
14. CASE STUDY SCENARIO: LATERAL MOVEMENT ▪ Workload Compromised: Attacker exploits a zero-day vulnerability (e.g., Log4Shell) inside the insecure Reviews-service container. ▪ Reconnaissance mapping: The attacker runs internal scans, discovering the internal IP of the sensitive customer ledger database API. ▪ The Threat Vector: Attempts to bypass default container boundaries using basic terminal utilities like curl. reviews-pod:/$ bash # Execute malicious payload $ curl -v \ http://customer-api.production .svc.cluster.local/v1/export
15. PILLAR 1: IDENTIFICATION (MTLS) SECURITY OUTCOME 1. Immediate Blocking at the Edge 2. Strict Security Enforcement ZTUNNEL · LAYER 4 TRANSPORT IDENTITY
16. PILLAR 2: VERIFICATION (TOKEN THEFT) BYPASSING L4 VIA IDENTITY THEFT MTLS HANDSHAKE PASSED
17. PILLAR 3: AUTHENTICATION INTERCEPT STEP ARCHITECTURAL VALIDATION PROCESS OUTCOME Step 1 Waypoint Proxy intercepts the secure, decrypted mTLS request. Intercepting Step 2 Extracts the verified SPIFFE principal identity from the connection. Identifying Step 3 Evaluates query against policy target: customer-api-lockdown. Evaluating Policy Step 4 Rejection: Principal identity is not in explicit allowed ServiceAccount whitelist. HTTP 403 Forbidden
18. WHAT IF WE GET UNLUCKY?
19. THE PLATFORM PAYOFF VELOCITY Less time writing boilerplate security authorization code RELIABILITY Preventing cascading failures that wake you up at 3 AM SECURITY Moving from "breach prevention" to "breach containment" OBSERVABILITY Logs capture and export every connection attempt.
20. KEY TAKEAWAYS
21. THANK YOU! Questions & Discussion HELPFUL RESOURCES SCAN QR CODE TO GIVE US FEEDBACK 1. https://mofesola.me/securing-the-path-from-edge-to-mesh-with-i stio-fa7f4b2b258e 2. https://www.linkedin.com/learning/kubernetes-service-mesh-withistio-25332503/making-microservices-simple-with-istio