TSB Ambient Mode

This guide provides a clear overview of Ambient mode in TSB for users already familiar with Istio and TSB. It highlights the key concepts, communication flows and feature differences compared to the traditional sidecar model.

Beta Functionality

This feature is currently at a Beta stage.

Tetrate will provide technical support for customers who wish to use this functionality.

Introduction

Ambient is an emerging service mesh architecture that removes the need for per-pod sidecars, reducing operational overhead while still delivering strong security and traffic control. TSB provides full support for Ambient mode in the Istio data plane and allows seamless coexistence of Ambient (ztunnels and waypoints) alongside traditional sidecars, enabling teams to balance performance efficiency with advanced Layer-7 capabilities where needed.

TSB enhances open-source Ambient by simplifying configuration in mixed environments by automatically applying the correct Ambient or sidecar policies based on deployment context.

With TSB, organizations can adopt Ambient incrementally, avoiding lock-in and disruptive architecture changes, while choosing the most appropriate mesh model for each workload and team.

What is Ambient Mode?

Ambient mode represents a fundamental shift in how Istio service mesh operates. Unlike the traditional sidecar proxy pattern where each application pod runs alongside an Envoy proxy, ambient mode splits the data plane into two distinct layers:

• ztunnel (L4 dataplane): A lightweight node-level proxy that handles mutual TLS (mTLS), authentication, authorization, and basic L4 policies. It ensures secure connectivity across pods and nodes.

• waypoint proxy (optional, L7 dataplane): An optional shared Envoy proxy deployed at the namespace or service level for advanced traffic management. It provides L7 features such as HTTP/gRPC routing, retries, observability, and traffic shaping.

This architectural change brings several key benefits:

• Zero-code change adoption: Applications don't need modification or restarts
• Reduced resource overhead: Shared infrastructure instead of per-pod proxies
• Simplified operations: Mesh upgrades without touching application pods
• Incremental feature adoption: Start with L4 security, add L7 when needed

Why Should I Consider Ambient?

To understand ambient mode's value, consider the traditional sidecar model's challenges:

Resource Overhead

• Every pod runs its own dedicated Envoy proxy attached to it as a sidecar, consuming significant memory and CPU purely for mesh functionality
• This per-pod overhead multiplies linearly with scale, as each replica, each service, each environment adds more proxy containers competing for cluster resources

Operational Complexity

• Mesh upgrades force restarts of all application pods, causing service disruptions
• Sidecar injection modifies deployments; if the sidecar crashes, the entire pod fails
• Troubleshooting requires navigating complex proxy configurations across thousands of containers

Developer Friction

• Enabling mesh features demands disruptive pod restarts, breaking continuous deployment flows and slowing release velocity
• Applications now depend on multi-container lifecycle coordination for managing sidecar readiness, startup sequencing, and graceful shutdown alongside application logic
• Local development environments struggle under sidecar resource demands, while troubleshooting requires understanding proxy configurations layered on top of application code

Ambient Architecture & Working

How Ambient mode addresses these challenges through architecture separation compared to the traditional Sidecar model and what are the core components involved in Ambient is described in detail in this section.

The key principle of Ambient is to separate concerns by layer:

• L4 security: Always-on, transparent, minimal overhead (ztunnel)
• L7 features: Opt-in, explicit, feature-rich (waypoint)

Zero Trust Tunnel: L4 Security & Connectivity

Zero Trust Tunnel (ztunnel) is a purpose-built, lightweight proxy that provides Layer 4 security and connectivity. It's deployed as a DaemonSet, meaning one ztunnel pod runs on each node in your cluster.

How It Works:

Each node runs one ztunnel DaemonSet that spawns worker threads into each application pod's network namespace. When applications send traffic, these in-namespace workers transparently intercept and encrypt it using mTLS before forwarding to destination nodes. The ztunnel main process coordinates all workers and receives security policies and certificates from the Istio control plane, distributing them to the appropriate pod-level workers for enforcement.

Key Responsibilities:

• Traffic Interception: Transparently captures all TCP traffic using iptables rules without application change
• Identity Management: Manages SPIFFE identities for each workload with automatic certificate rotation
• mTLS: Encrypts traffic between workloads and verifies identities using SPIFFE X.509 certificates
• L4 Authorization: Enforces identity-based policies (e.g., "Allow team-A namespace to access team-B namespace")
• HBONE Protocol: Tunnels TCP connections over HTTP/2 for compatibility with standard network infrastructure

Waypoint Proxy: L7 Processing Layer

Waypoint is an optional L7 proxy deployed when you need advanced traffic management features. Unlike ztunnel (which is per-node), waypoints are typically deployed per namespace or per service account.

How It Works:

Waypoint runs as a standard Kubernetes deployment with its own network namespace, operating as a regular mesh workload. When traffic requires L7 processing, the source ztunnel redirects it to the waypoint pod (based on service annotations or Gateway configuration). The waypoint receives the encrypted traffic, performs L7 operations (authorization, routing, retries), then forwards it to the destination ztunnel, which delivers it to the target application. Multiple services can share a single waypoint, amortizing the L7 processing overhead across workloads.

Key Responsibilities:

Deploy waypoint proxies when you need advanced Layer 7 capabilities:

• L7 Authorization: Enforced HTTP based policies including JWT validation, header/path/method checks and request property authorization
• Advanced Traffic Management: Handles intelligent routing, retries, timeouts, circuit breaking, fault injection and traffic mirroring
• Request/Response Transformation: Manipulates HTTP headers, rewrites URLs, and modifies request/response content
• Protocol-Aware Processing: Parses and routes HTTP/gRPC traffic with full protocol awareness for fine-grined control
• Telemetry: Collects detailed HTTP metrics, distributed traces and API-level observability data

Waypoint is NOT needed for basic mTLS encryption, identity-based access control (L4), or simple namespace-level policies—ztunnel handles these efficiently

Advantages of Ambient over Sidecar

Advantages of Ambient over sidecars in resource utilization, scaling, performance & maintenance are outlined in this section

Resource Efficiency at Scale

Ambient mode significantly cuts infrastructure overhead by replacing per-pod sidecars with shared, node-level components. Traditional sidecar meshes allocate a full proxy to every pod, consuming memory and CPU that scale linearly with each replica. In contrast, Ambient uses a single ztunnel per node for L4 security and optional shared waypoint proxies for L7 features, delivering the same mesh capabilities with far fewer resources.

Operational Simplicity

Upgrading a sidecar-based mesh requires restarting every application pod, since the proxy is injected into the workload itself. This causes service disruption, rollout delays, and cross-team coordination challenges. In Ambient, upgrades are applied only to the node-level ztunnels and optional waypoints, allowing the mesh to evolve without disrupting running applications.

The same issue appears during large-scale application deployments. When hundreds or thousands of pods must be updated to pick up new sidecar versions or configs, the rollout can exceed the allowable buffer window, often causing intermittent 503s and traffic spikes during production releases. Ambient eliminates this problem by removing the proxy from the application pod, allowing apps to deploy at their own cadence while the mesh is updated independently.

Incremental Feature Adoption

Ambient enables a true pay-as-you-go approach to service mesh capabilities:

• Phase 1: Turn on Ambient to get immediate L4 security i.e mTLS, workload identity, and basic policies without introducing sidecar overhead.
• Phase 2: Add waypoints only for services that require L7 features such as advanced routing, JWT validation, or traffic controls.
• Phase 3: Expand L7 coverage gradually based on real needs rather than committing upfront.

This removes the traditional "all-or-nothing" constraint of sidecars, where teams incur full L7 proxy cost and complexity even when they only need foundational security.

TSB Integration Benefits

TSB provides enterprise-grade management and operational capabilities that make ambient production-ready at scale.

Unified Management Across Deployment Modes

TSB delivers a single control plane for managing sidecar-based services, ambient workloads, and waypoint proxies through one consistent interface. Security policies and traffic rules apply uniformly across deployment modes, eliminating separate management workflows. For multi-cluster deployments, TSB orchestrates ambient mesh connectivity across regions with consistent policy enforcement.

Intelligent Policy Translation and Targeting

TSB automatically translates high-level SecuritySettings and TrafficSettings into appropriate Istio resources, intelligently determining whether to target ztunnels (L4), waypoint proxies (L7), or both based on deployment topology. This eliminates configuration errors and lets operators focus on business intent rather than implementation details.

Enterprise-Grade Features for Production

TSB extends ambient with multi-tenancy enforcement, declarative GitOps workflows, unified observability across deployment modes, and comprehensive audit logs for compliance. FIPS-compliant builds and tenant isolation ensure ambient deployments meet enterprise security and regulatory requirements.

Safe Migration with Validation

TSB enables incremental ambient adoption at both namespace and workload levels, offering fine-grained control over how and when services migrate. You can enable ambient for entire namespaces or selectively onboard individual workloads based on readiness. TSB also exposes configuration-status APIs that allow users to monitor and verify whether the ambient migration and config translation is complete according to the deployment mode.

Feature Parity

Sidecar vs Ambient Comparison

Feature Category	Sidecar	Ambient (ztunnel)	Ambient (+ waypoint)
Security
mTLS encryption	✅	✅	✅
L4 authorization	✅	✅	✅
L7 authorization	✅	❌	✅
JWT validation	✅	❌	✅
Traffic Management
Load balancing	✅	✅ (L4)	✅ (L4 + L7)
Advanced routing	✅	❌	✅
Retries/timeouts	✅	❌	✅
Circuit breaking	✅	❌	✅
Observability
Connection metrics	✅	✅	✅
HTTP metrics	✅	❌	✅
Distributed tracing	✅	❌	✅
Operations
Resource overhead	🔴 High	🟢 Minimal	🟡 Moderate
Upgrade impact	🔴 Pod restart	🟢 Transparent	🟢 Transparent

OSS Ambient vs TSB Ambient

Feature	OSS Istio Ambient	TSB Ambient	Key Difference
Policy Management
Authorization Policies	✅ Native AuthorizationPolicy CRDs	✅ TSB SecuritySettings (high-level)	TSB abstracts complexity with intent-based policies
L4 Policy Enforcement	✅ Manual targeting (ztunnel)	✅ Automatic targeting	TSB auto-determines ztunnel vs waypoint
L7 Policy Enforcement	✅ Manual Gateway targetRef	✅ Automatic targeting	TSB handles waypoint attachment automatically
Traffic Policies	✅ VirtualService/DestinationRule	✅ TSB TrafficSettings	Single API for both sidecar and ambient
Multi-Tenancy
Namespace Isolation	✅ Manual RBAC setup	✅ Tenant-based isolation	Built-in tenant boundaries
Cross-Tenant Policies	⚠️ Complex manual config	✅ Workspace-level policies	Simplified cross-tenant communication
Audit Logging	⚠️ Limited	✅ Comprehensive audit trails	Enterprise compliance support
Cross-Cluster Connectivity
Intra-Cluster (same cluster)	✅ Native	✅ Native	Same capability
Inter-Cluster (multi-cluster)	⚠️ Manual ServiceEntry config	✅ Automatic service discovery	TSB auto-configures cross-cluster routing
Multi-Cluster Topology View	❌ No visibility	✅ Unified topology view	Single pane of glass across clusters
Cross-Cluster Policy	⚠️ Per-cluster configuration	✅ Global workspace policies	Policies apply across all clusters
East-West Gateway Config	⚠️ Manual setup required	✅ Automatic configuration	TSB manages gateway mesh
Hybrid Mode Support
Sidecar + Ambient Coexistence	✅ Supported	✅ Supported	Both support hybrid
Sidecar + Ambient Multi-Cluster Connectivity	❌ Not Supported	✅ Supported	TSB auto-configures cross-cluster routing
Hybrid Policy Management	⚠️ Separate configs	✅ Unified policy model	Same SecuritySettings for both modes
Deployment & Operations
Waypoint Management	⚠️ Manual Gateway creation	✅ TSB auto-deploys	Platform manages lifecycle
Configuration Sync	❌ No built-in GitOps	✅ Native GitOps integration	Declarative, version-controlled
Revision Based Upgrades	❌ No built-in support	✅ Revision based Gateways and Workload upgrades	Isolation Boundary & Istio revision based upgrades
Observability
Metrics Collection	✅ Prometheus format	✅ Unified TSB metrics	Aggregated across clusters
Service Topology	⚠️ Cluster-level only	✅ Global multi-cluster view	End-to-end service graph
Traffic Analytics	⚠️ Basic metrics	✅ Advanced analytics	Business-level insights
Security & Compliance
FIPS Compliance	❌ Not certified	✅ FIPS-validated builds	Enterprise security standards
Compliance Reporting	❌ Manual	✅ Built-in compliance reports	Audit-ready documentation
Certificate Management	✅ Cert rotation	✅ Enterprise CA integration	Vault, external CA support