Debasree Panda 
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.
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 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 token, 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 the network security
Implementation of enterprise-wide security from 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 expiration of the certificate 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 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 firewall can be applied in front of Istio ingress gateway before traffic enters the mesh.
Data loss prevention using Istio network policies
You can avoid any sensitive information such as username, 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
Similarly 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 to constantly track the behavior and performance of services across the organizations. The control plane emits metrics, traffic flows and service dependencies (using Kiali), which is essential to understand and react 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 the versions. This is the best case for organizations who want to gain multicluster and multilcoud 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 sidecare-less dataplane 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 by the end of this year.
IMESH helps enterprises to implement and adopt Istio enterprise-wide without any operational hassle. If you are interested, book an Istio consultation demo today or contact an Istio expert today.
