In September 2022, we at Solo.io announced, along with Google, a new Istio data plane mode called Istio ambient mesh. The ambient mesh was designed in a way that doesn’t sacrifice security or functionality and maintains the core features of Istio, which are zero trust security, telemetry, and traffic management.
Now, less than a year after its release, we’ll explore a few things we expect to see happen with ambient mesh in 2023.
What is ambient mesh?
In traditional service mesh deployments, sidecar proxies are part of the data plane and run alongside every application in the service mesh. The sidecar proxies manage and monitor each application’s incoming and outgoing network traffic.
In the Istio ambient mesh, there’s no need for sidecar proxies anymore. The network concerns are split between a per-node component called ztunnel and a per-service-account component called waypoint proxy.
The ztunnel takes care of networking concerns at the transport layer, for example, mTLS, telemetry, authentication, and L4 authorization. In contrast, the waypoint proxy deals with the Layer 7 protocol and concerns such as routing traffic, L7 telemetry, and L7 authorization policies. While ztunnel components get deployed by default on each node in the cluster, the decision on whether to deploy the waypoint proxy is in the end-user’s hand.
If you’re using any L7 features, you’ll deploy the waypoint proxy; otherwise, you won’t. For a more in-depth look at the ztunnel, check out the Understanding Istio Ambient Ztunnel and Secure Overlay blog post.
In addition to architectural changes, there are other advantages to running Istio ambient mesh. Adopting Istio service mesh is a somewhat invasive process as it requires modification of all applications that are part of the mesh to inject the sidecar proxies. The invasiveness always introduces risks that result in a reasonably steep adoption curve.
In contrast, the ambient mesh is non-invasive by design. Users can incrementally adopt the service mesh features while their applications run by labeling the namespaces. As no sidecars are involved, there’s no need for application restarts. Once the ztunnel takes care of the L4 network on the nodes, your applications will instantly get the mTLS and L4 observability.
This makes the ambient mesh deployment model much leaner as it allows for incremental adoption of service mesh features, making it less risky.
Moreover, as ambient mesh includes fewer components, this directly leads to reduced infrastructure costs and performance improvements. Ambient mesh does all this while retaining all the service mesh critical features, including zero trust security.
Ambient mesh in 2023
With nearly a year of engineering efforts poured into the ambient mesh from engineers from Solo.io and Google, let’s look into what Istio ambient mesh might bring next.
Promotion from experimental to GA in 2023
As of Istio 1.16, the ambient mesh is not yet part of the official releases, and it’s still designated as experimental. Currently, the ambient mesh code lives in a separate branch; however, one of the ambient working group’s top priorities is to transition that code into Istio’s main branch.
Merging the work into the main branch won’t affect existing Istio users, but it will make it easier to test and experiment with ambient mesh. The next step for ambient mesh is a promotion to the Alpha phase, probably in the next quarter, and then to Stable by the end of 2023.
With the significant difference in the deployment models of Istio and Istio ambient mesh, the first and most obvious question is: how will the feature parity be handled, and what happens to the APIs?
Improved interoperability
One way to achieve feature parity between sidecar-less and sidecar deployment modes is by using the same and existing Istio APIs. That means one can use the same CRDs to configure the mesh, regardless of the underlying deployment model.
In the ideal world, the APIs would stay the same. However, as ambient mesh introduces a different architecture and separates concerns between two components, this isn’t the case.
There are ongoing discussions in the ambient working group on implementing certain Istio APIs and whether it even makes sense to implement them for ambient mesh.
Re-using all existing APIs in the context of the ambient mesh might make little sense due to its architecture. One example here is the Sidecar resource used for configuring the sidecar proxies in the Istio mesh. Since there are no more sidecar proxies in the ambient mesh, implementing this API doesn’t make much sense. The same goes for any annotations related to these APIs.
New ambient-only APIs
On the other hand, ambient mesh introduces new components – ztunnel and waypoint proxy. These new components might push the creation of an ambient-only set of APIs to configure the components and potentially other ambient-only features.
A reasonably safe bet to make is that ambient mesh won’t support a full suite of Istio APIs. Instead, it will likely implement the APIs that most users are interested in and perhaps include ambient-only APIs for configuring the waypoint proxies and ztunnels. One such API that’s being discussed is IstioNetworkPolicy.
This API is only one of the multiple options that would be used for configuring ztunnels. As waypoint proxies are tied to the Kubernetes Gateway API, it’s safe to assume this won’t change. Especially as the Kubernetes Gateway API was recently promoted to Beta.
Using this model, users can start their service mesh journey with the ambient mesh. If the need arises for specific APIs or scenarios not available or supported in the ambient mesh, they can implement them in the sidecar deployment model. The key to this is a good interoperability model between the two deployment modes.
We’re expecting to see investments into interoperability between the meshes with sidecar and sidecarless workloads, and as a result of this work, we’ll see some API changes as well.
HBONE replaces Istio’s mTLS
We mentioned how existing APIs might not be supported and how new APIs might get added; however, how about the instances where APIs might get deprecated?
The ztunnel components use HTTP Based Overlay Network Encapsulation protocol (HBONE) to communicate with each other and with waypoint proxies. The HBONE support for sidecars and ingress gateways was included in Istio 1.16 under a feature flag, as it’s not production ready yet. The new feature allows sidecars and ingress gateways to communicate using the HBONE protocol, the same way ztunnel and waypoint proxies communicate.
As HBONE and Istio’s mTLS are considered equivalent from a security perspective, there are discussions on what happens with the current APIs that control the mTLS behavior. For example, it brings into question the PeerAuthentication resource and whether to remove it and use AuthorizationPolicy instead to assert that requests must come from a trusted identity.
We can rest assured that ambient mesh implementation won’t sacrifice security, just like any other mesh functionality. Ambient mesh pushing the transport security to a secure overlay changes the security boundaries for the better!
For example, if your application gets compromised in the sidecar deployment model, the attackers gain access to the identity and keys associated with the workload. As ambient mesh doesn’t run any components in the same pod as the application, compromising the application doesn’t give attackers access to any secrets.
Check out the Ambient Mesh Security Deep Dive blog post for a deeper view of ambient mesh security.
Getting ambient mesh to production
As co-creators of the ambient mesh data plane and leaders on the Istio Steering and Technical Oversight Committee (TOC), we are working hard to get ambient production ready. We are working with early adopters and interested parties to close any gaps in critical functionality and harden what’s already there. If you’re interested in POCing ambient mesh with a trusted partner who can help you with your mesh use cases, please reach out to us.
Next steps with ambient mesh
In this blog post, we looked a bit into the future and tried to see where the development of ambient mesh is going in 2023.
With its design, the ambient mesh allows organizations to adopt service mesh incrementally and minimizes the risks while doing so. Albeit the feature is still in the experimental phase at the moment, with all the work being done by the Istio community, we’re confident we’ll see the ambient mesh get to production readiness by the end of 2023.
Join the Get Started with Istio Ambient Mesh course at Solo.io Academy to try the Istio ambient mesh yourself and get the Istio Ambient Mesh Foundation Certificate.
To get involved and start contributing to the Istio ambient mesh, join the Istio Slack and Solo.io community.
