Using Gloo as an ingress gateway with Istio and mTLS (updated for Istio 1.1!)

Istio is a popular open-source service mesh with powerful service-to-service capabilities such as request-routing control, metric collection, distributed tracing, security, et. al. Istio also ships with an ingress-gateway component that makes it easy to get traffic into your service mesh. The Istio ingress gateway allows you to control what protocols, security requirements, and ports get exposed to the outside world, and then use Istio-native routing capabilities to route traffic to services. Gloo is an open-source API Gateway based on Envoy Proxy with advanced API Gateway capabilities like request/response transformation, function routing (Swagger, gRPC, cloud functions like Lambda, etc), a pluggable and extensible control plane and discovery system for Envoy, and more. As outlined in our “API Gateways are going through an identity crisis” blog, using an API gateway can give definition to your microservices, decouple front-end users/services from backend APIs, aggregate multiple APIs, and do more complex routing. One of the more powerful features of Istio is the ability to securely authenticate and encrypt all traffic flowing over the mesh with mutual TLS. Gloo complements service-mesh technology like Istio and brings higher-level API capabilities to a service mesh. With Gloo, we can tie into Istio’s mTLS capabilities and route directly into the mesh for both Istio 1.0.x as well as the newly released Istio 1.1 (as of 3 hours ago at the time of writing!). Let’s take a look.

Istio certificate provisioning

With Istio 1.0.x, Istio uses a component called Citadel to provision certificates to workloads and use an identity to encode into these certificates. The identity Istio uses on Kubernetes, for example, is based on Kubernetes service accounts. These certificates can then be used in the Istio service proxies (based on Envoy Proxy) to transparently establish mutual authentication/mTLS with any services with which it communicates.

With Istio 1.1 the certificates are issued differently to solve for some drawbacks of the 1.0.x approach. Istio 1.1 uses Envoy’s Secret Discovery Service API (SDS) which means we can avoid hot-restarting the proxy when new certificates are issues (or rotated), we can eliminate the distribution of private keys over the network, and we can avoid any of the risks of using Kubernetes secrets.

Gloo with Istio 1.0.x and mTLS

Integrating Gloo into Istio service mesh with mTLS enabled is simple as:

1. Mount the correct Istio service mesh certificates into the Gloo Proxy (based on Envoy)
2. Configure the Gloo Upstreams to use the Istio certificates for mTLS

Please see the documentation on configuring Gloo with Istio to see exactly how these steps are accomplished.

Gloo with Istio 1.1.x and mTLS

As aforementioned, Istio’s 1.1 mTLS configuration has changed and you can optionally use a more-secure SDS implementation. With Gloo, we can do that by:

1. Enabling the Unix Domain Socket in our Gloo Gateway (Envoy) to talk directly with the Istio SDS implementation (node agent)
2. Update the Gloo Upstream to use the new SDS configuration

Please see the documentation on configuring Gloo with Istio 1.1 to see exactly how these steps are accomplished. And there you have it: within 3 hours of releasing the new Istio SDS implementation, the Gloo engineering team has delivered Gloo+Istio mTLS integration. Please check it out and give us feedback on Slack or on our Issue Tracker. Huge shout out to Yuval Kohavi for the quick turn around on this implementation!