The Solo distribution of Istio includes basic built-in features by default, and numerous other features that you can unlock with an Enterprise-level license for Solo Enterprise for Istio. Review the following features that are supported when you install your ambient mesh with the Solo distribution of Istio and a Solo Enterprise for Istio Enterprise license.

Multicluster mesh

Create an ambient mesh setup across multiple clusters. In Solo Enterprise for Istio, you can deploy an ambient mesh to each workload cluster, create an east-west gateway in each cluster, and link the istiod control planes across cluster networks by using peering gateways. This feature allows you to easily route between ambient mesh services across clusters.

  • Multicluster mesh setup: To get started, you can install and link new ambient meshes. Alternatively, you can use automated cluster peering with the Gloo management plane to link multiple clusters. To faciliate communication between peered clusters, the east-west gateway’s LoadBalancer address is used by default. In the Solo distribution of Istio version 1.28 and later, you can choose to instead use NodePort addresses for direct pod-to-pod communication (alpha).
  • Multicluster app routing: You can then add your apps to the ambient mesh and make the services available across clusters with simple global service naming and routing.
  • Multitenancy with segments (alpha): In the Solo distribution of Istio version 1.28 and later, you can also enhance multitenancy in your multicluster mesh by grouping clusters into logical segments with their own domain suffixes and isolated service discovery.
  • Drain clusters in the mesh (alpha): In the Solo distribution of Istio version 1.28 and later, you can add the solo.io/draining-weightannotation to an east-west or remote peering gateway to indicate that a local or remote cluster is undergoing maintenance. This way, no new connections are opened to services in the cluster. For more information, see Drain clusters in the mesh.

Node-based Layer 7 monitoring

Extract Layer 7 attributes from traffic requests that are routed through ztunnels. These L7 attributes can be used for:

  • L7 metrics, such as istio_requests_total and istio_request_duration_milliseconds, with labels that are based on the L7 attributes (such as Result Code).
  • Access logs, based on L7 attributes in addition to the existing access log information.
  • Distributed tracing, such as to manage information about spans and their tags.

For example, you can check out the Solo Enterprise for Istio observability guides that include ztunnel steps, such as the Add Istio request traces guide.

SPIRE integration

SPIRE offers robust workload attestation capabilities that provide significantly more controls around how, when, and if identities are granted to workloads. The Solo distribution of Istio includes Enterprise support for using SPIRE node agents (over an Envoy SDS socket) to attest and grant identities to the ambient mesh workloads they proxy. This allows Istio to use these identities for mTLS connections between the ambient mesh workloads.

With the SPIRE integration, the ztunnel can act as a trusted spire-agent delegate on the node by using the SPIRE DelegatedIdentity API. Ztunnel can integrate with SPIRE to leverage SPIRE’s existing node and workload attestation plugin framework directly, as well as request workload certificates that are issued by SPIRE on the basis of those attestations.

To get started, check out Secure workload identities with SPIRE.

Per-client mTLS egress origination

Deploy a waypoint proxy that serves as a shared egress gateway for Istio workloads in your ambient mesh. This gateway originates mTLS egress traffic in which each Istio workload identity uses a per client-app service account as its own unique, external identity. This egress waypoint configuration essentially allows you to map a mesh identity onto an external identity, and originate mTLS connections with the mapped external identity based on the identity of the client that initiates the connection.

To get started, check out Advanced mTLS egress.

Automatic waypoint deployment

If you deploy an ambient mesh and require waypoint proxies to apply Layer 7 policies, you can use versions 1.25 and later of the Solo distribution of Istio to automate the waypoint deployment. Instead of manually creating a waypoint proxy resource, and then labeling a namespace, service, or service entry to use that waypoint, you can simply label the namespace, service, or service entry with istio.io/use-waypoint=auto. Istiod automatically creates the appropriate waypoint and applies it to your target resource.

Note that this automation currently only creates waypoints with the istio-waypoint Gateway class. For more information, see About waypoints.

Ambient-sidecar interoperability

In some cases, you might want to run a hybrid architecture in which you use ambient mesh components, such as waypoints and ztunnels, to provide mesh capabilities broadly across your environment while continuing to run sidecars for some of your pods, depending on your app’s requirements. This interoperable architecture is often implemented only temporarily or for specific use cases.

Waypoint interoperability for ingress and sidecars

In the community distribution of ambient mesh, Envoy-based proxies such as ingress gateways and sidecar-enabled workloads can communicate with ambient mesh components via the HBONE protocol by default. However, Envoy-based proxies cannot utilize waypoint proxies. This means that traffic between Envoy-based proxies and ambient mesh components that requires policy application either fail or do not perform correctly, because the expected policies enforced by the waypoint proxy do not apply to requests from the Envoy-based proxies.

In the Solo distribution of Istio, interoperability between waypoints and sidecars and between waypoints and ingress proxies is supported.

  • Sidecars: Client policies, such as routing rules, are applied either at the client sidecar, or at one waypoint if a waypoint exists. When a sidecar detects that a request must be sent to a service that uses a waypoint, the sidecar disables any client-side policies (such as skipping virtual services), and instead sends the request directly to the waypoint. Note that policy enforcement for some sidecar-inbound policies that can also be applied at the service’s waypoint might behave differently.
  • Ingress: By default, ingress proxies cannot determine the destination service for a request without applying the route. For this reason, the istio.io/ingress-use-waypoint: true label must be applied to any services that should respect waypoint proxies, so that the ingress proxy can send requests for the service’s route directly to the waypoint.

Interoperability scenarios

Because interoperability is supported, you can use the Solo distribution of Istio to run both sidecar and ambient components in your cluster. Typically, interoperability facilitates hybrid mesh setups for temporary reasons, such as during migration. However, some more permanent solutions might require a hybrid mesh as well. You might leverage interoperability in one of the following scenarios:

  • Migration: You can perform a zero-downtime migration from a sidecar mesh to an ambient mesh, in which ambient waypoints can route to sidecars during the migration process.
  • Multicluster mesh: In some cases, interoperability can be used intentionally, such as in multicluster sidecar mesh setups. In this setup, you install the Istio ambient components in each workload cluster to successfully create east-west gateways and establish multicluster peering, even if you plan to use a sidecar mesh. However, sidecar mesh setups continue to use sidecar injection for your workloads, and your workloads are not added to an ambient mesh.

Considerations for policy enforcement

Policy enforcement is an integral consideration when planning a sidecar-ambient architecture. Traffic policies that are applied at the sidecar-inbound level in a sidecar mesh are typically instead applied at the waypoint level in an ambient mesh. Because of this, in a setup in which your workload uses both a waypoint and a sidecar, the same policy might apply to traffic requests twice, such as in the following scenarios.

  • When you use the migration tool to move workloads from sidecar to ambient, you migrate to an ambient setup in multiple phases. One phase includes activating waypoints while retaining sidecars in workloads, thereby starting a brief period of time in which traffic from a waypoint is sent to both sidecar- and ambient-enabled workloads. The tool then analyzes your sidecar-inbound policies, and makes suggestions for adjusting the policies to apply them at the waypoint. The period of overlap time ends when you remove the sidecars from workloads in the final phase, and remove the old sidecar-inbound policies that are now enforced only at the waypoint.
  • You might have multiple clusters in a mesh setup, in which services in an ambient-mesh cluster make requests to services in a sidecar-mesh cluster. If both clusters define a global service, and a waypoint is defined in the ambient cluster, a request from the ambient cluster might pass through its local waypoint for policy enforcement, before being routed to the workload on the remote cluster where the policy is enforced again at the sidecar.

A policy that is applied at both the waypoint and sidecar-inbound level, thereby being applied to traffic requests twice, might have the following levels of issues:

  • None: Policy is fully idempotent and causes no issues or changes to the traffic flow, such as matching a header for routing.
  • Potential: Policy might cause issues, but does not necessarily break the traffic flow. For example, a rate limit policy might count requests twice and allow for half of the effective rate limit quota.
  • Breaking: Policy completely breaks the traffic flow. For example, a PeerAuthentication policy that disables mTLS for a workload in a sidecar setup does not function in an ambient mesh, in which encryption with mTLS is always enabled through the HBONE communication protocol.

Review the following table to understand the effects of double policy enforcement for each resource type.

ConfigurationIssue levelEffects
AuthorizationPolicyNoneGenerally, double authorization policy application causes no issues. For specific changes you might need to make during migration from sidecar to ambient, see authorization policy migration.
AuthorizationPolicy with a custom ExtensionProviderBreakingOnly one extension provider is permitted per workload. In a sidecar setup, you might have multiple policies with different providers, that are individually applied to different workloads. However, when you apply an AuthorizationPolicy with a custom ExtensionProvider to a waypoint, you can define only one provider for all workloads that the waypoint serves. This can cause an issue in which only one provider, which is potentially the incorrect provider for a workload, is applied to traffic that is routed through the waypoint for that workload.
Global rate limitPotentialBecause both the waypoint and sidecar send rate limit requests to the global rate limiting server, both affect its state. This can result in counting requests twice and allowing for only half of the effective rate limit quota. Update the quotas to account for double the amount of requests.
Local rate limitNoneLocal rate limiting is evaluated independently by Envoy on both the waypoint and sidecar, so requests are not counted twice.
PeerAuthentication with DISABLEBreakingIn ambient mode, traffic between ztunnel node agents uses the HBONE protocol, which includes encryption with mTLS. Because of this, the DISABLE mTLS mode is not supported in ambient and cannot be applied in a PeerAuthentication policy on the waypoint. You can alternatively use STRICT mode to ensure that connections cannot bypass the mesh.
RequestAuthentication with forwardOriginalTokenBreakingIf forwardOriginalToken is set to false (default setting), Envoy removes the token header after successful validation. This can cause requests that successfully authenticate at the waypoint to fail authentication at the sidecar, because the authentication token is removed before it is forwarded from the waypoint to the sidecar. Set forwardOriginalToken to true to ensure the token is forwarded.
RequestAuthentication with outputClaimToHeadersNoneIf outputClaimToHeaders is set, the header is overwritten if it already exists in the request.
RequestAuthentication with outputPayloadToHeaderPotentialIf outputPayloadToHeader is set, the payload is added twice, which results in a multi-value header. This can cause an issue if the upstream service that consumes the header cannot handle multi-value headers.
Trace sampling percentageNoneThe trace sampling rate set in the randomSamplingPercentage can increase because the sampling decision is made by both the waypoint and sidecar. If a request is sampled for tracing by the waypoint, the x-b3-sampled header is added, and the request is also sampled by the sidecar to emit a trace. If a request is not sampled by the waypoint, it might still be sampled at the sidecar according to the configured rate.

ECS services integration

In the Solo distribution of Istio version 1.28 and later, you can extend the mesh to include workloads running in an ECS cluster by leveraging the istioctl ecs add-service command. This command automatically bootstraps existing ECS services with a ztunnel sidecar container, which uses IAM roles to authenticate with your Istio installation. The workloads in ECS can then use the ztunnel to communicate with the in-mesh services in your cluster.

To get started, check out Add ECS services to the mesh. For more information about this command, see the CLI reference.

Next

Ready to move to an ambient mesh? Check out the following guides and resources to get started.

  • Quickly install a demo deployment of an ambient mesh with the Gloo Operator.
  • If you want to plan a migration from your existing sidecar mesh to an ambient mesh, review the ambient migration guide. This guide uses the Solo.io ambient migration tool to provide a prescriptive migration path based on your existing environment.
  • Check out the free Ambient Estimator Tool, which assesses your Istio environment to estimate potential cost savings from migrating from sidecars to a sidecarless mesh architecture.