Ambient Mode Is Promoted to Beta in Istio 1.22

The biggest and arguably most exciting release of Istio in 2024 is finally here! The most notable feature in the Istio 1.22 release is ambient mode reaching beta.

Since the original announcement in 2022, Solo.io has been deeply involved in the development and innovations in ambient mode and collaborated with engineers from Google, Microsoft, Intel, and others.

What Is Ambient Mode?

Istio ambient mode is a new way to deploy Istio that doesn’t require sidecar proxies. It’s designed to be simpler to deploy and manage and is more lightweight than the traditional Istio sidecar model.

One of the most significant innovations in Istio ambient mode is the separation of processing layer 4 and layer 7 traffic. While in the sidecar mode, L4 and L7 traffic is processed by the sidecar proxy that runs as a container inside the workload pod; in ambient, the L4 traffic is processed by a per-node zero trust tunnel proxy called ztunnel, and the L7 traffic is processed by an optional waypoint proxy.

The ztunnels transparently capture the traffic and handle the encryption before sending it to other pods in the mesh. Since there are no longer sidecars involved, you can enable mTLS between your workloads by labeling the namespace. You won’t even have to restart your workloads! If you need layer 7 functionality, you can deploy an optional waypoint proxy to handle the L7 policies.

From our initial research, you can automatically cut overhead by 90% or more by removing the need for sidecar proxies and moving to ambient mode.

What Does Ambient Mode in Beta Mean?

The ambient mode features in Istio 1.22 are now ready to be used in production with certain caveats as specified in Istio’s feature phase definitions.

You can also read the announcement blog post on Istio.io, which goes into more detail about the scope of the beta release.

Promoting Istio APIs From Stable to v1

The majority of features provided by the Istio’s APIs for security, networking, and telemetry have been considered stable for some time now, but the API versions in the CRDs have remained at v1beta1.

In the 1.22 release, the Istio community has promoted the number of APIs to v1. You can check the official blog post for more information.

Service Mesh Support for Gateway API Reaches GA

With the Kubernetes Gateway API v1.1.0 release, the mesh support has graduated to GA and is now part of the standard release channel.

The mesh support for Kubernetes Gateway API allows users to use the same APIs to manage ingress (north-south) and mesh (east-west) traffic.

If you’re already using the Kubernetes Gateway API for ingress traffic, you are familiar with the HTTPRoute resource, where you’d use the parentRefs field to target the Gateway resource. The idea is similar when using HTTPRoute for the east-west traffic, where you instead target the service.

For example:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: hello-world
spec:
  parentRefs:
  - group: ""
    kind: Service
    name: hello-world
    port: 5000
  rules:
  - matches:
    - path:
      - type: PathPrefix
        value: /v1
    backendRefs:
    - name: hello-world-v1
      port: 8080
  - matches:
    - path:
      - type: PathPrefix
        value: /v2
    backendRefs:
    - name: hello-world-v2
      port: 8080

The above route is attached to the hello-world Kubernetes Service and will be applied to all requests sent to that service on port 5000. In the rules section, we’re matching the path prefixes and routing the traffic to the backing service.

Templating Support in AuthorizationPolicy

This long awaited feature allows you to specify path template patterns for matching URI paths in the AuthorizationPolicy.

You can now write an AuthorizationPolicy using patterns {*} (matches a single path component up to the next separator) and {**} (matches zero or more path segments).

For example:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: auth-policy
spec:
  selector:
    matchLabels:
      app: my-app
  rules:
    - to:
        - operation:
            paths: ["/v1/*", "/{**}/users"]
            notPaths: ["*/admin"]

Incremental xDS Protocol Enabled by Default

This release also makes the Delta xDS protocol the default option. This change allows Istio’s control plane to communicate about resources with the data plane (Envoys) more efficiently. Instead of sending all the information about every resource every time, it only sends the changes, which makes it faster and uses less network traffic.

Traffic Management Improvements

Out of multiple improvements and bug fixes in the traffic management area, here are a couple of interesting ones:

• Waypoints no longer have to be scoped to the entire namespace or single service account. Resources such as pods, services, and namespaces can now be annotated with the istio.io/use-waypoint annotation.
• Ability to opt-in or opt-out pods into the ambient mode using the istio.io/dataplane-mode label
• Environment variables were added (PILOT_GATEWAY_API_DEFAULT_GATEWAYCLASS_NAME, PILOT_GATEWAY_API_CONTROLLER_NAME) that allow overriding the default name of the GatewayClass resource and the Istio Gateway API controller.
• Improved ServiceEntry resource that uses resolution: NONE to respect the target port.

Security Improvements

In addition to the path templating support for AuthorizationPolicy, here are a couple of other updates in the security area:

• Ability to customize the connection timeout when resolving jwksUri.
• Support for multi-cluster node Istio CA to handle node authorization for CSRs by impersonating the identity of remote clusters. This helps support multi-cluster scenarios in ambient mode.
• You can now disable the metrics endpoint from outside of the pod using the METRICS_LOCALHOST_ACCESS_ONLY environment variable.

Before upgrading to 1.22, check out the upgrade notes. To get started with the latest release and check out the ambient mode in beta, follow this guide.