Skip to main content
SecurityTraining · Part 7/20

Agentic AI security curriculum · Security overview

RBAC, mTLS, and Istio Service Mesh: Network-Level Zero Trust

Module 7 of 20 · Agentic AI Security Curriculum · May 2026

How to use this module

Use it as self-paced study or as instructor-led training. YAML, commands, and policy excerpts are illustrative; map them to your cloud, mesh, identity provider, and agent runtime—substitute your own names, namespaces, and tools while preserving the control intent.

Estimated time: ~35 minutes reading; add time for linked standards and team discussion.

Learning objectives

By the end of this module, you should be able to:

  1. Explain mutual TLS and service identity for east-west traffic in Kubernetes.
  2. Describe egress control patterns (mesh gateways, firewall rules, DNS allowlists).
  3. Connect network segmentation to lateral movement containment.

Prerequisites

Suggested discussion / lab: Pick one diagram in your environment (build, deploy, runtime) and mark where this module’s controls apply; note gaps versus the checklist in the body.


With identity-level least privilege and advanced cryptographic controls established (Modules 4–6), this module extends Zero Trust to the network layer. It covers how RBAC, mutual TLS, and Istio Service Mesh work together to enforce micro-segmentation and default-deny networking across the cluster.

Istio mTLS and AuthorizationPolicy

Istio provides automatic mutual TLS between all pods in the mesh. Every pod-to-pod connection is encrypted and authenticated using short-lived certificates.

AuthorizationPolicy examples in a reference stack:

The API gateway can only call specific backend services (documents, memory, vertical plugins). MCP sandbox pods can only reach the Kata runtime and isolated NATS JetStream topics. Vertical plugins are blocked from direct communication with each other — all cross-vertical traffic must route through the intelligent gateway.

This eliminates east-west lateral movement even if a pod is compromised.

ServiceEntries as FQDN Lockdown

Istio ServiceEntries explicitly whitelist allowed external destinations:

  • Only approved external APIs (GitHub, document stores, oracles, etc.).
  • No arbitrary outbound traffic to the internet.
  • EgressGateway routes all external calls through inspected paths.

This replaces the need for a separate WAF for FQDN control and is reviewed quarterly alongside STRIDE modeling.

Default-Deny NetworkPolicy

A cluster-wide default-deny NetworkPolicy ensures no pod can talk to any other pod or external endpoint unless an explicit allow rule exists.

Combined with Istio, this creates layered defense: NetworkPolicy at the Kubernetes level and AuthorizationPolicy + mTLS at the service mesh level.

Traffic Baselining and Anomaly Detection with Kiali

Kiali visualizes the service mesh topology while Prometheus alerts on unexpected connection patterns. The security team maintains a baseline of normal east-west traffic. Any new or anomalous flow triggers investigation.

Helm Chart Integration

These controls are enabled by default when deploying with:

security:
  fullBundle: true
  istio:
    enabled: true
    mTLS: strict
    egressAllowlist: true

Key Takeaways

Network-level Zero Trust requires encryption (mTLS), authentication, and explicit authorization for every connection. Default-deny policies combined with ServiceEntries provide strong egress and east-west control. Micro-segmentation limits blast radius: a compromised component can only reach what it is explicitly allowed to reach. Continuous baselining with Kiali turns the mesh into an active security sensor.

This network foundation enables safe sandboxing and runtime protection in the following modules.

Next module: Sandboxing Options and Trade-offs – Kata, gVisor, Seatbelt, Docker, and Cloudflare Workers.

Further reading (vendor-neutral)

These resources are independent of any single product; use them to deepen the topic for audits, architecture reviews, or procurement discussions.

Commercial training use

You may reuse this curriculum internally or in paid consulting / training engagements. Keep examples aligned to the customer’s actual stack; substitute your own runbooks, tool names, and compliance frameworks (SOC 2, ISO 27001, sector regulators) where cited examples use a reference architecture only.