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:
- Explain mutual TLS and service identity for east-west traffic in Kubernetes.
- Describe egress control patterns (mesh gateways, firewall rules, DNS allowlists).
- Connect network segmentation to lateral movement containment.
Prerequisites
- Prior module: Advanced Zero Trust: Multi-Sig Vault, HSM, Tamper-Proof Logging, and Cryptographic Provenance
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.
- Istio security (mTLS)
- Kubernetes NetworkPolicies
- NIST SP 800-204B (micro-segmentation with service mesh)
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.
