Interview › Istio & Service Mesh
What RBAC is needed to manage Istio resources safely?
Istio & Service Mesh · Advanced level
Answer
RBAC should separate platform-level mesh administration from application-level route and policy ownership. App teams may manage their namespace's VirtualServices, AuthorizationPolicies, and routes, but shared gateways, mesh-wide policies, IstioOperator, EnvoyFilters, and root trust configuration should be tightly restricted.
Technical explanation
Least privilege prevents one team from accidentally breaking another team's traffic.
Cluster-scoped or shared resources require platform review and CI validation.
Use Kubernetes RBAC plus admission policies and GitOps ownership rules.
Hands-on example
Role model:
Platform Admin: install/upgrade Istio, manage root config, shared gateways.
Service Owner: manage namespace routes and policies for owned hosts.
Security Reviewer: approve DENY policies, external auth, and egress rules.
CI Bot: apply only validated manifests from approved repositories.
Check how well your resume matches the role with our free resume checker— match score, ATS check, and the skills you're missing.
More Istio & Service Mesh interview questions
- What is Istio, and what are the core capabilities it provides?
- What is the difference between the Istio control plane and data plane?
- What is istiod, and what does it do?
- What is Envoy, and what role does it play in Istio?
- What is the sidecar pattern, and how does Istio inject the proxy?
- How does automatic sidecar injection work (namespace label, webhook)?
- What is the Istio ambient (sidecarless) mode, and how does it differ from sidecar mode?
- What is the difference between ztunnel and a waypoint proxy in ambient mode?