Interview › Istio & Service Mesh
How would you restrict which external services workloads can reach with Istio?
Istio & Service Mesh · Intermediate level
Answer
I restrict external access by using REGISTRY_ONLY outbound policy, defining approved external destinations with ServiceEntry, routing sensitive traffic through egress gateways, and enforcing Kubernetes or cloud network controls so workloads cannot bypass the mesh.
Technical explanation
ServiceEntry creates an allowlist at the mesh layer.
AuthorizationPolicy can restrict which service accounts are allowed to call specific egress paths.
External access should be reviewed like firewall rules: owner, business justification, destination, port, data classification, and expiry.
Hands-on example
Example controls:
Allowed: payments service account -> api.payment-provider.com:443 through egress gateway.
Denied: any namespace -> random internet host.
Validation:
$ kubectl exec deploy/payments -- curl https://api.payment-provider.com
$ kubectl exec deploy/payments -- curl https://example.org
The second request should fail or be blocked.
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?