What is Istio ambient service mesh
Istio, an open source and widely used service mesh, is used to manage network and security for cloud-native applications. In Sept, 2022, Istio project released- Ambient mesh– a modified and sidecar less data plane for Istio developed for enterprises that want to deploy mTLS and other security features first, and seek to deploy an advanced network later.
Istio ambient mesh architecture
Istio service mesh is the powerful software to enable zero trust by enabling authentication, authorization, and audit using mTLS and identity controls. Platform teams, cloud architects of large organizations have implemented security using Istio. To implement security, Istio involves the following components- a certificate authority (CA) for key management, API to distribute Authn/Authz policies to proxies, Policy Enforcement Points (PEPs) implemented using sidecars (Envoy proxies), and extensions to manage telemetry.
Although achieving zero trust using Istio is straightforward, the sidecar implementation (refer the image below) of Istio is usually very computationally expensive and hard to maintain; so the project has released a new version called Istio ‘ambient’ mesh.
Istio ‘ambient’ mesh provides a light-weight data plane that does not require sidecar injection with any microservices. Ambient mesh has distinguished layers in the data plane- secure overlay layer and L7 processing layer which are designed to implement Istio sequentially in a phase-wise manner and tackle security concerns first.
- Secure overlay layer (also known as zero-trust tunnel or ztunnel)is a L4 processing layer designed to implement TCP routing and handle zero trust security for traffic such as mTLS, Authentication and Authorization policies.
- L7 processing layer (also known as waypoint proxy) is designed to handle complex traffic management functionalities such as HTTP routing, circuit breaking, chaos engineering, reties, timeouts, rate limiting, etc, and handle granular Authn/Authz policy implementation.
Ztunnel for secure connection and authentication of services
Ztunnel is an agent, primarily a rust-based proxy, whose responsibility is to securely connect and authenticate elements within the mesh. One can deploy ztunnel as a DaemonSet workload resource on a Kubernetes cluster. Ztunnel is a dedicated L4 technology and is deployed per node in a cluster. The idea is ztunnel will be shared among all the workloads in a node it is deployed to. The ztunnel leverages leverages Kubernetes CNI to establish connections between workloads, secure communication using mTLS, collect HTTP metrics, access logs, etc.
And all the ztunnels are connected with each other using HTTP protocol (refer the image below). If Service A wants to pass data to another Service C in another node, then the ztunnel of node-1 will send HTTP connection requests (over mTLS) to the ztunnel of node-2. Once a TCP connection is established between the ztunnel, the data packets can be transported securely to Service C. Such connections between ztunnel is referred as HBONE (HTTP-Based Overlay Network Environment).
Fig: Implementation of ztunnel
There three important benefits of using ztunnel or a node-level proxy:
- Phase-1 implementation of secured communication (using mTLS) for all your microservices will be fast.
- Simple authentication and authorization policies can be defined at node-level.
- Maintenance such as version upgrades or CVE patching to node-level proxy will be easier and faster.
Whenever teams have implemented phase-1: Security of services, they can implement phase-2: Network management of microservices. In the phase-2 they can create sophisticated traffic and security policies by using L7 proxy or waypoint proxy.