What Is Istio Ambient Mesh?

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 September 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 a powerful software to enable zero trust by enabling authentication, authorization, and audit using mTLS and identity controls. Platform teams and 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 to 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 lightweight data plane that does not require sidecar injection with any microservices. Ambient mesh has distinguished layers in the data plane — the 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 an L4 processing layer designed to implement TCP routing and handle zero trust network 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. It will be shared among all the workloads in a node it is deployed to. The ztunnel leverages Kubernetes CNI to establish connections between workloads, secure communication using mTLS, collect HTTP metrics, access logs, etc.

All the ztunnels are connected with each other using HTTP protocol (refer to 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 are referred to as HBONE (HTTP-Based Overlay Network Environment).

There are three important benefits of using ztunnel or a node-level proxy:

1. Phase-1 implementation of secured communication (using mTLS) for all your microservices will be fast.

2. Simple authentication and authorization policies can be defined at the node level.

3. Maintenance such as version upgrades or CVE patching to the 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 phase 2, they can create sophisticated traffic and security policies by using L7 proxy or waypoint proxy.

Waypoint Proxy for Network Management and Telemetry

Waypoint proxies are basically Envoy proxies, used to implement L7 traffic management capabilities in Istio ambient mesh. Based on the header and credentials, the proxy is capable of applying advanced networking policies, such as circuit breaking, traffic shaping and splitting, retries, fault injection, etc. Waypoint proxy also helps in achieving granular authorization policies for Role-based access control (RBAC) or Attribute-based access control (ABAC).

Waypoint or L7 proxy is deployed into a cluster per identity/workload type. If there are 5 services in a cluster, you can deploy 5 waypoint proxies to handle communication at the application level for each service. One can scale up the proxies as per the load. Coming to the deployment of the waypoint proxy (which is essentially an Envoy proxy) is not installed as a sidecar fashion- deployed to each pod of a service. Envoy was installed as a container in each of the pods of a service. And in case of breach of an app (essentially a pod), all the sensitive information such as tokens, keys, etc could be stolen from the proxy. However, in case of waypoint proxy, deployed at only service level, breach of an application cannot imply the access to secrets in the proxy.

In the above diagram, waypoint proxies are deployed per service and can be seen as individual gateways or policy enforcement points (PEPs) per service.

Note: One can configure Ambient mesh to have multiple services configured to a single waypoint proxy, but to contain security blast radius and improve lifecycle management operations, the ideal way of mapping the proxy to service is 1:1.

Istio Control Plane for Managing and Observing Network Security

Implementation of Enterprise-Wide Security from a Central Control Plane

The data plane can be handled from the Istio central plane to push the define and declare security and network policies for each node and each workload through ztunnel and waypoint proxy. Istio is capable of integrating with 3rd party authentication standards such as Okta, LDAP, SAML, SSO providers, etc.

Istio control plane also allows the ability to create granular access controls, RBAC, and multi-tenancy policies for all the inbound traffic (through waypoint proxies).

Securing Traffic at the Edge With Whitelisting

Security policies can be implemented at the edge and to the ingress traffic. Large enterprises can use the Istio control plane to whitelist IPs for using certain services. This is very useful while implementing network access controls, or remote access enablement, or beta testing (allowing a limited set of testers or beta customers to use your services and provide feedback).

Automated Certificate Management With Istio Agents

Security managers or platform engineers can provision stronger identities to every workload with X.509 certificate. The Istio control plane acts as the certificate authority and issues certificates to the Istio agents (running alongside each proxy). The control plane automates the key and the certificate management at scale with the help of the Istio agents. The idea is whenever a Kubernetes workload would start, Envoy proxy would seek the certificate and key from Istio agent in the same container. Istio agent will be responsible for monitoring the certificate's expiration and, accordingly, would rotate with the new certificate from the control plane. Note that the root certificate can be kept in Vault rather than stored in the same local PC.

Enabling WAF for Multicloud Apps With Istio

Cloud providers such as firewalls to protect web applications from common exploits at the edge. A few common ones are AWS WAF, Azure WAF, and Google Cloud Armor to provide defense against SQL injection, DDOS attacks, and cross-site scripting (XSS), at the edge. All the firewalls can be applied in front of Istio Envoy gateway before traffic enters the mesh.

Data Loss Prevention Using Istio Network Policies

You can avoid any sensitive information such as usernames, tokens, and financial transaction data that are not logged or leaked using Istio network policy rules. The data loss prevention (DLP) rules can be defined in HTTP listeners or virtual service objects of Istio. The DLP rules can be applied to mask access logs, or any output data with potentially sensitive information.

Gain Multicluster Visibility 

Istio allows security managers to monitor and measure the integrity and security posture of all microservices. Istio generates runtime telemetry to help network administrators, SREs, and DevOps constantly track the behavior and performance of services across the organizations. The control plane emits metrics, traffic flows, and service dependencies (using Kiali), which are essential to understanding and reacting to security incidents.  

Another noteworthy point is that the Istio ambient mode will have sidecar patterns as well. In case you want to have implemented the Istio sidecar pattern and now want to implement the ambient mesh, the control plane will support both versions. This is the best case for organizations that want to gain multicluster and multicloud visibility in a single plane.

Conclusion

Istio is used to manage a network connection and communication among microservices spread across Kubernetes clusters. It is used to ensure a secure network with verification of services and users in each transaction. You can attain 360-degree visibility for faster reaction in case of security breaches and have a fault-tolerant system for more resilience. 

The new sidecar-less data plane of Istio ambient mode makes it a more compelling, hassle-free, and computation-inexpensive option to implement a service mesh. Even though Istio ambient mesh is in beta now, it is expected to be production-ready in 2023.