The Solo distribution of Istio is a hardened Istio enterprise image which maintains n-4 support for CVEs and other security fixes. Versions 1.22.3 and later of the Solo distribution of Istio also include enterprise-level features for ambient mesh on top of the features that are offered by the community distribution of ambient mesh.

Review the following enterprise-level ambient mesh features that are available in the Solo distribution of Istio. For more information about using these features, contact an account representative. If you already have a license, you can review the available versions of the Solo distribution of Istio by logging in to the Support Center and reviewing the Istio images built by Solo.io support article.

Safe in-place upgrades of istio-cni

In the community distribution of ambient mesh, istio-cni is a node-critical component that cannot be safely upgraded without disrupting nodes or using node cordons. For example, node cordoning ensures that new pods cannot be scheduled on nodes, which prevents unsecured traffic leaks while istio-cni is deleted and re-created during the upgrade.

The Solo distribution of Istio solves this problem by enhancing istio-cni. When istio-cni is scheduled for removal, it determines whether an upgrade is in process by checking the value of AGENT_UPGRADE_ID in the istio-cni ConfigMap against its internal upgrade ID. When istio-cni detects that the removal is due to an upgrade, it creates a “stub” CNI plug-in in its place on the node. This stub CNI plug-in stalls any newly scheduled pods on that node, and does not allow the pods to spin up until the replacement istio-cni is up and running.

This process ensures that in-place upgrades are smooth and do not require extra node preparation steps. For more information, check out the Upgrade ambient service meshes guide.

Layer 7 telemetry support for ztunnel

The Solo distribution of Istio adds the ability to extract Layer 7 attributes from traffic requests that are routed through ztunnels. These Layer 7 attributes can be used for:

  • Layer 7 metrics, such as istio_requests_total and istio_request_duration_milliseconds, with labels that are based on the Layer 7 attributes (such as Result Code).
  • Access logs, based on Layer 7 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 Gloo Mesh Core observability guides that include ztunnel steps, such as the Add Istio request traces guide.

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 HBONE by default. However, Envoy-based proxies cannot utilize waypoint proxies. This means that traffic between Envoy-based proxies and ambient mesh components will either fail or 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 ingress proxies is supported.

  • Sidecars: When a sidecar detects that a request must be sent to a service that has a service waypoint, the sidecar disables any client-side policies (such as skipping virtual services), and instead sends the request directly to the waypoint.
  • 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.

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 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.

This feature allows ztunnel to act as a trusted spire-agent delegate on the node, via the SPIRE DelegatedIdentity API. This allows ztunnel to 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.

VM support

Due to the SPIRE integration offered by the Solo distribution of Istio, the ability to add workloads that run on virtual machines (VMs) to your ambient mesh is also supported. You can use SPIRE attestation to grant a trusted identity to the external workload, and subsequently onboard the external workload to the ambient mesh dataplane.