Chapter 5. Coexistence of ambient and sidecar modes


Red Hat OpenShift Service Mesh supports running sidecar and ambient workloads in the same Istio mesh. Use this capability to migrate workloads to ambient mode in increments. You can keep specific workloads in sidecar mode if they depend on features that ambient mode does not yet support.

Coexisting sidecar and ambient workloads operate under a single Istio control plane that uses the ambient profile. With this configuration, you can enforce policies and route traffic across both deployment types. Review the following capabilities, limitations, and operational guidelines for managing this architecture.

5.1.1. Supported features

Note

Ambient and sidecar coexistence requires Red Hat OpenShift Service Mesh version 3.2 or later.

The following features work when sidecar and ambient workloads coexist.

CategoryFunctionalityDescription

Connectivity

East-west traffic

Sidecar pods and ambient pods communicate bidirectionally across namespace boundaries.

Security

mTLS

Sidecar proxies automatically detect HBONE (HTTP-Based Overlay Network Environment) endpoints and use HBONE for outbound connections to ambient pods. Ztunnel uses HBONE to reach sidecar proxies. Traffic between both modes is encrypted with mutual TLS.

Security

L4 AuthorizationPolicy

The mesh enforces authorization policies based on principals, source IPs, and ports in both directions across modes.

Security

PeerAuthentication with STRICT mTLS

A PeerAuthentication policy set to STRICT mode accepts traffic from both sidecar and ambient workloads.

Gateways

Egress gateways

Ambient pods interoperate with egress gateways.

Gateways

Ingress gateways

Ingress gateways deployed in non-ambient namespaces expose services in both sidecar and ambient namespaces.

Observability

L4 TCP metrics

Basic Layer 4 TCP metrics and telemetry are available for traffic between sidecar and ambient workloads.

5.1.2. Limitations

  • Unsupported VirtualService features: Ambient mode does not support a gateway API required by the following features. Workloads that rely on these features must remain in sidecar mode:

    • HTTPFaultInjection
    • JWT claim-based routing
    • Delegate rules
    • Rate limiting
    • ignoreCase for path matching
  • One-Way L7 policy bypass (sidecar to ambient): Traffic from a sidecar pod to an ambient pod bypasses the waypoint proxy of the destination.

    As a result, the mesh enforces only L4 authorization policies on this path; L7 policies (such as HTTP routing or rules) do not apply.

    Note

    Traffic in the opposite direction (ambient to sidecar) works without this limitation. The destination sidecar proxy enforces L7 policies normally.

  • Ingress gateway waypoint bypass: By default, traffic from an ingress gateway to an ambient service bypasses the waypoint proxy. To force traffic through the waypoint for L7 enforcement, you must:

    1. Set the environment variable ENABLE_INGRESS_WAYPOINT_ROUTING to true in the Istio CR.
    2. Label the target service or namespace with istio.io/ingress-use-waypoint: "true".

5.1.3. Best practices

  • Keep ambient and sidecar workloads in separate namespaces to make the data plane mode of each workload explicit and to avoid label conflicts.
  • Do not label a namespace or pod with both istio-injection: enabled and istio.io/dataplane-mode: ambient. If both labels are present, sidecar injection takes precedence, but the resulting configuration is ambiguous and difficult to maintain.

Add ambient workloads to an existing sidecar-mode OpenShift Service Mesh installation by updating the control plane configuration and deploying the ztunnel proxy. After you complete this procedure, you can run sidecar and ambient workloads in separate namespaces within the same mesh.

Prerequisites

  • You have an existing OpenShift Service Mesh installation (version 3.2 or later) in sidecar mode on OpenShift Container Platform.
  • You are logged in to the OpenShift Container Platform cluster as a user with the cluster-admin role.

Procedure

  1. Update the existing Istio CR to set profile: ambient and to configure the trusted ztunnel namespace, as shown in the following example. Save the configuration to a file named istio_ambient.yaml.

    apiVersion: sailoperator.io/v1
    kind: Istio
    metadata:
      name: default
    spec:
      namespace: istio-system
      profile: ambient
      values:
        pilot:
          trustedZtunnelNamespace: ztunnel
    Important

    You must set spec.profile to ambient and set spec.values.pilot.trustedZtunnelNamespace to ztunnel. This is the namespace in which you install the ZTunnel resource.

  2. Apply the updated Istio CR by running the following command:

    $ oc apply -f istio_ambient.yaml
  3. Update the IstioCNI resource to enable the ambient profile, as shown in the following example. Save the configuration to a file named istiocni_ambient.yaml.

    apiVersion: sailoperator.io/v1
    kind: IstioCNI
    metadata:
      name: default
    spec:
      profile: ambient
  4. Apply the updated IstioCNI resource by running the following command:

    $ oc apply -f istiocni_ambient.yaml
  5. Confirm that the IstioCNI resource is ready by running the following command:

    $ oc wait --for=condition=Ready istiocnis/default --timeout=3m
  6. Create the ztunnel namespace by running the following command:

    $ oc create namespace ztunnel
  7. Create a file named ztunnel.yaml that has the ZTunnel resource. For example:

    apiVersion: sailoperator.io/v1
    kind: ZTunnel
    metadata:
      name: default
    spec:
      namespace: ztunnel
      targetRef:
        kind: Istio
        name: default
    Note

    The spec.targetRef field associates the ZTunnel instance with an Istio control plane. When you set this field, the system automatically copies values relevant to ZTunnel, such as global, meshConfig, and revision, from the referenced Istio or IstioRevision resource. Values that you set in the ZTunnel spec.values field override inherited values.

  8. Apply the ZTunnel CR by running the following command:

    $ oc apply -f ztunnel.yaml
  9. Confirm that the ZTunnel resource is ready by running the following command:

    $ oc wait --for=condition=Ready ztunnels/default --timeout=3m
  10. Confirm that the Istio control plane is ready by running the following command:

    $ oc wait --for=condition=Ready istios/default --timeout=3m
  11. Restart existing sidecar pods in each namespace that has sidecar workloads. Run the following command for each namespace:

    $ oc rollout restart deployment -n <sidecar_namespace>

    The restart re-injects the pods with ISTIO_META_ENABLE_HBONE set to true. Without this setting, the sidecar proxies cannot communicate with workloads in the ambient data plane. If you have a large number of sidecar pods, consider restarting them in small batches or one at a time to avoid disruption.

  12. Create a namespace for your ambient workloads by running the following command:

    $ oc create namespace <ambient_namespace>
  13. Label the namespace to enable ambient mode by running the following command:

    $ oc label namespace <ambient_namespace> istio.io/dataplane-mode=ambient
  14. Deploy your application workloads to <ambient_namespace>.

    The mesh uses the ztunnel proxy to intercept traffic for pods in this namespace. You do not need to change your workload manifests.

Verification

  1. Verify that your ambient workloads run without a sidecar proxy:

    $ oc get pods -n <ambient_namespace>

    Example output:

    NAME                        READY   STATUS    RESTARTS   AGE
    my-app-6d8f94b7c9-xk2pj    1/1     Running   0          45s

    Pods in an ambient namespace show 1/1 containers in the READY column. This output confirms that the mesh did not inject a sidecar proxy into the pod.

  2. Verify that ztunnel registered your ambient workloads and configured HBONE. Run the following command:

    $ istioctl ztunnel-config workloads --namespace ztunnel --workload-namespace <ambient_namespace>

    The output lists the mesh workloads:

    NAMESPACE          POD NAME                                IP          NODE                  WAYPOINT PROTOCOL
    example            example-gateway-istio-59dd7c96db-q9k6v 10.244.1.11 ambient-worker        None     TCP
    example            example-app-cf74bb974-5sqkp            10.244.1.5  ambient-worker        None     HBONE

    Confirm that the PROTOCOL column displays HBONE for your new ambient pods. This protocol value indicates that ztunnel configured HBONE.

Note

When a sidecar pod sends traffic to an ambient pod, the traffic bypasses the waypoint proxy of the destination. As a result, the mesh enforces only L4 authorization policies on this path; L7 policies do not apply.

Add sidecar workloads to an existing ambient-mode OpenShift Service Mesh installation by configuring automatic sidecar injection for a dedicated namespace. After you complete this procedure, you can run sidecar and ambient workloads in separate namespaces within the same mesh.

Prerequisites

  • You have an existing OpenShift Service Mesh installation (version 3.2 or later) in ambient mode on OpenShift Container Platform.
  • You are logged in to the OpenShift Container Platform cluster as a user with the cluster-admin role.

Procedure

  • Follow the procedure Enabling sidecar injection with namespace labels in this guide.

    Important

    Do not apply the istio.io/dataplane-mode: ambient label to sidecar namespaces. If you apply both labels, sidecar injection takes precedence, but the resulting configuration is ambiguous and difficult to maintain.

Verification

  • Confirm that the namespace does not have the ambient label:

    $ oc get namespace <sidecar_namespace> --show-labels

    The output displays the active labels. Verify that the string istio.io/dataplane-mode=ambient does not appear.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

Legal Notice

Theme

© 2026 Red Hat
Back to top