Skip to content

Istio Ambient Mesh in Big Bang: From Beta to GA

Update: Istio Ambient Mesh reached General Availability in Big Bang 3.32. It remains opt-in throughout Big Bang 3.x and becomes the default Istio configuration in Big Bang 4.0. Users are encouraged to begin migrating and validating their mission environments before the 4.0 upgrade.

Big Bang 3.23 introduced support for Istio Ambient Mesh as an opt-in beta feature. Ambient mode reached General Availability in Big Bang 3.32 while remaining opt-in throughout the 3.x lifecycle. It becomes the default Istio configuration in Big Bang 4.0.

This post provides a high-level overview of the Ambient Mesh capability, how this capability impacts cluster networking traffic, and the changes that were made in the Big Bang product to support it.

Why Ambient?

Ambient Mesh offers major advantages over the sidecar model by reducing resource overhead. Instead of running a dedicated proxy in every Kubernetes pod, Ambient uses a shared Layer 4 proxy, ztunnel, on each Kubernetes cluster node. As workload count grows, this model becomes more efficient because proxy overhead no longer scales with every pod.

Ambient Mode also simplifies operations. Since applications are no longer tied to an injected sidecar, pods do not need to be restarted just to pick up Istio proxy updates. Additionally, the Ambient Mesh architecture significantly reduces the complexity of onboarding and integrating mission applications into the Big Bang service mesh.

The Big Bang 3.23 Opt-In Beta

In Big Bang 3.23, Ambient Mesh was available but not enabled by default. At that time it was a beta feature, and production use required careful evaluation based on each environment’s needs. Ambient reached GA in Big Bang 3.32 and will ship as the default mesh networking configuration with Big Bang 4.0.

Ambient can be enabled by setting the istio.ambient.enabled flag to true in your values configuration file, which enables it globally for all Big Bang applications.

For more information on configuration and what is enabled behind the scenes, refer to the Enabling Ambient Mode documentation.

Changes to the Network Stack

Ambient introduces a fundamental change in how traffic flows:

  • No per-pod sidecar proxies → reduced resource overhead
  • Node-level L4 processing (ztunnel) → handles mTLS and basic policy enforcement
  • Optional L7 processing (waypoints) → used selectively for advanced use cases

One of the most significant changes from a networking perspective is that workloads now communicate over TCP port 15008 (HBONE) when using the tunnel. This requirement is automatically handled by the bb-common integration, which allows this port when Ambient is enabled.

From a security perspective, allowing HBONE tunnel traffic enables connectivity to destination workloads, so NetworkPolicy and AuthorizationPolicy must be configured to preserve intended segmentation. To address this, Big Bang automatically enables Layer 4 Authorization Policies to ensure environments remain properly segmented and secure.

For a deeper dive into the architecture, please check out Istio Ambient Architecture.

Current Implementation

Ambient Mesh is primarily a Layer 4-first architecture. Instead of injecting an Envoy sidecar into every workload, Istio uses ztunnel, a node-level proxy, to create a secure L4 overlay for meshed traffic. When teams need Layer 7 features—such as HTTP routing, header-based policy, or richer request-level telemetry—they can opt specific workloads into waypoint proxies. This split lets Ambient Mesh provide a lower-friction security baseline by default, while making deeper application-aware processing an explicit, targeted choice rather than a universal sidecar tax.

In Big Bang, this is particularly relevant for applications that rely on Authservice for authentication which are expected to continue to function in the same way (using the Authservice label), but should still be validated:

  • Prometheus
  • AlertManager
  • Thanos

For Authservice-protected inbound routes, bb-common can create a shared waypoint for the package namespace and the policies required to route ingress and in-mesh traffic through it. Additional waypoint proxies can be manually deployed using Istio’s configuration documentation.

Troubleshooting Istio Ambient Mesh Workloads

Since the istio-proxy containers no longer exist, troubleshooting shifts to inspecting ztunnel logs.

The following command retrieves the last 500 log entries for all ztunnel pods:

kubectl logs -l app.kubernetes.io/name=ztunnel -n istio-system --tail 500

You can combine this with grep to filter for specific workloads or errors.

Below is an example of an error that indicates a problem with a missing or misconfigured network policy:

error   access  connection complete src.addr=10.42.1.22:36146 src.workload="kiali-5f4f9bd98c-jdb59" src.namespace="kiali" src.identity="spiffe://cluster.local/ns/kiali/sa/kiali-service-account" dst.addr=10.42.1.17:15008 dst.hbone_addr=10.42.1.17:9090 dst.service="monitoring-monitoring-kube-prometheus.monitoring.svc.cluster.local" dst.workload="prometheus-monitoring-monitoring-kube-prometheus-0" dst.namespace="monitoring" dst.identity="spiffe://cluster.local/ns/monitoring/sa/monitoring-monitoring-kube-prometheus" direction="outbound" bytes_sent=0 bytes_recv=0 duration="0ms" error="io error: Connection refused (os error 111)"

Note: As mentioned earlier, TCP port 15008 is the primary port used when in Ambient Mode so close attention should be paid to the dst.addr when troubleshooting network policy related issues.

Another example shows what it may look like if you have a missing or misconfigured authorization policy:

error   access  connection complete src.addr=10.42.1.22:56558 src.workload="kiali-5f4f9bd98c-jdb59" src.namespace="kiali" src.identity="spiffe://cluster.local/ns/kiali/sa/kiali-service-account" dst.addr=10.42.2.10:15008 dst.hbone_addr=10.42.2.10:3200 dst.service="tempo-tempo.tempo.svc.cluster.local" dst.workload="tempo-tempo-0" dst.namespace="tempo" dst.identity="spiffe://cluster.local/ns/tempo/sa/tempo-tempo" direction="inbound" bytes_sent=0 bytes_recv=0 duration="0ms" error="connection closed due to policy rejection: allow policies exist, but none allowed"

You can also use the istioctl utility to analyze the entire environment to look for any issues that stick out by executing the following command:

istioctl analyze -A

For a more in-depth troubleshooting resource please refer to Troubleshooting Istio Ambient.

Summary

Big Bang 3.23 introduced Ambient Mesh as a beta, opt-in feature that:

  • Simplifies the data plane by removing per-pod proxies
  • Shifts enforcement toward L4 Authorization Policies + Network Policies
  • Supports selective L7 processing for authentication for packages that leverage Authservice

Ambient Mesh is GA as of Big Bang 3.32. Users should begin migrating and validating mission-specific behavior before Big Bang 4.0 makes Ambient the default Istio configuration.