Service mesh traffic and identity: Istio sidecars, ambient mode and authorization
Understand where Istio enforces transport security and application policy. Compare sidecar and ambient data paths, then diagnose a request that has valid mTLS but fails HTTP authorization.
TL;DR: A service mesh inserts policy and telemetry into communication between workloads. Its usefulness depends on which traffic it actually captures. A request that bypasses the proxy or reaches a workload outside the configured mesh can have different security properties from an apparently identical request through the expected path.
In Istio, the control plane distributes configuration and supports workload identity. The data plane handles traffic. Application pods still run application code, Kubernetes Services still provide discovery, and the application must still decide whether a particular user may change a particular order. Mesh membership does not grant that business permission.
Locate the enforcement point
Istio supports a sidecar model and an ambient model. In the sidecar model, an Envoy proxy runs alongside each enrolled workload. In ambient mode, the node-level ztunnel supplies the secure transport layer; a waypoint supplies optional Layer 7 processing. Istio's ambient architecture distinguishes these responsibilities. A policy requiring an HTTP method needs an enforcement point that can interpret HTTP.
| Requirement | Sidecar path | Ambient path |
|---|---|---|
| Workload identity and mesh mTLS | Workload sidecar | ztunnel secure transport |
| HTTP-aware routing and policy | Envoy sidecar configuration | Applicable waypoint configuration |
| Business ownership of an order | Application authorization | Application authorization |
| Packet-level network isolation | Appropriate network policy enforcement | Appropriate network policy enforcement |
The last row is separate from mesh configuration. Kubernetes NetworkPolicy constrains permitted network communication where the networking implementation enforces it. Use network and mesh policies together when the threat model needs both; test the actual path rather than treating either policy object as proof of enforcement.
This is a responsibility map. An ambient connection without a waypoint does not acquire the HTTP policy shown at that stage. The detailed hop sequence varies with source, destination and waypoint enrollment. Check waypoint configuration and traffic coverage for the installed Istio version before planning a migration.
Encryption succeeds, authorization fails
Consider an illustrative checkout service calling inventory. A release switches checkout from service account checkout to checkout-v2. Certificates are valid and mesh mTLS succeeds, but inventory's authorization policy only permits the old workload principal. The resulting denial is consistent with the configured identity rule. Rotating certificates would not repair it.
Now suppose the identity rule is updated, but only GET is allowed and the release sends POST. That is another policy decision. Finally, a permitted POST could reach inventory and fail because the end user does not own the reservation. These failures belong to different layers, even if a dashboard puts them all under client errors.
An investigation should retain the source workload identity, destination, method and the component producing the response. Verify whether the application received the request. Proxy logs and application logs can distinguish a mesh rejection from application authorization, but response status alone is insufficient evidence.
Istio's security concepts explain peer authentication, request authentication and authorization separately. A workload certificate authenticates a workload principal. A validated JWT can establish request identity. An authorization rule decides which of those identities may perform the configured operation.
Test policy changes as a matrix
Before enforcing a new rule, write down allowed and denied cases. For the checkout example, test the intended service account with GET, the same account with POST, an unrelated account, and a request without the required user credential. Record expected outcomes at both mesh and application layers. A single successful request exercises only one cell.
PeerAuthentication controls accepted transport authentication; STRICT requires mesh mTLS for traffic governed by that policy. It does not express an inventory reservation rule. Ambient mode also has different supported behavior from sidecar mode, including its treatment of disabling mTLS. Read the mode-specific documentation before copying a manifest between them.
During rollout, verify certificate distribution and actual policy attachment before removing a permissive transition. Keep an explicit recovery path for a policy that blocks production callers. Avoid a broad allow rule that survives the incident because nobody knows its owner.
Self-check: checkout has a valid certificate, can call inventory health checks, and receives denials only when creating reservations. Investigate the authenticated workload principal, HTTP policy and application authorization for that operation. Healthy transport narrows the search; it does not establish permission to perform every request.