Docsright arrowEdge Stackright arrow1.12right arrowIstio Integration

13 min • read

Istio Integration

Ambassador Edge Stack and Istio: Edge Proxy and Service Mesh together in one. The Edge Stack is deployed at the edge of your network and routes incoming traffic to your internal services (aka "north-south" traffic). Istio is a service mesh for microservices, and is designed to add application-level Layer (L7) observability, routing, and resilience to service-to-service traffic (aka "east-west" traffic). Both Istio and the Ambassador Edge Stack are built using Envoy.

Ambassador Edge Stack and Istio can be deployed together on Kubernetes. In this configuration, incoming traffic from outside the cluster is first routed through the Ambassador Edge Stack, which then routes the traffic to Istio-powered services. The Ambassador Edge Stack handles authentication, edge routing, TLS termination, and other traditional edge functions.

This allows the operator to have the best of both worlds: a high performance, modern edge service (Ambassador Edge Stack) combined with a state-of-the-art service mesh (Istio). While Istio has introduced a Gateway abstraction, the Ambassador Edge Stack still has a much broader feature set for edge routing than Istio. For more on this topic, see our blog post on API Gateway vs Service Mesh.

This guide will explain how to take advantage of both Ambassador and Istio to have complete control and observability over how requests are made in your cluster.

Prerequisites

  • A Kubernetes cluster version 1.15 and above
  • kubectl

Install Istio

Istio installation is outside of the scope of this document. Ambassador will integrate with any version of Istio from any installation method.

Install Ambassador

There a number of installation options for Ambassador. See the getting started for the full list of installation options and instructions.

Integrate Ambassador and Istio

WARNING - Istio Regression: There is a regression in Istio 1.9 that causes Ambassador (and other non-Istio services) to be unable to read Istio certificates.

A patch for this regression has been merged and is waiting for a release. https://github.com/istio/istio/pull/31531

Use Istio 1.8.2 or earlier until a version of Istio with a patch for this regression is released.

Ambassador integrates with Istio in three ways:

  • Uses Istio mutual TLS (mTLS) certificates for end-to-end encryption
  • Integrates with Prometheus for centralized metrics collection
  • Integrates with Istio distributed tracing for end-to-end observability

Integrating Ambassador and Istio allows you to take advantage of the edge routing capabilities of Ambassador while maintaining the end-to-end security and observability that makes Istio so powerful.

Mutual TLS

The process of collecting mTLS certificates is different depending on your Istio version. Select your Istio version below for instructions on how to integrate Ambassador with Istio.

Integrating Ambassador with Istio 1.5 and Above

Istio 1.5 introduced istiod which moved Istio towards a single control plane process.

Below we will update the deployment of Ambassador to include the istio-proxy sidecar, and configure the system to allow Istio and Ambassador to share mTLS certificates:

  • Both the istio-proxy sidecar and Ambassador mount the istio-certs volume at /etc/istio-certs.
  • The istio-proxy sidecar will save the mTLS certificates into /etc/istio-certs (per the OUTPUT_CERTS environment variable).
  • Ambassador will read the mTLS certificates from /etc/istio-certs (per the AMBASSADOR_ISTIO_SECRET_DIR environment variable) and create a secret named istio-certs.
    • At present, the secret name istio-certs cannot be changed.
    • To make use of the secret, use a TLSContext as shown below.

Make sure the istio-proxy is the same version as your Istio installation

Deploy the YAML above with kubectl apply to install Ambassador with the istio-proxy sidecar.

After applying the updated Ambassador deployment above to your cluster, we need to stage the Istio mTLS certificates for use.

We do this with a TLSContext using the istio-certs secret, which tracks the mTLS certificates provided from the istio-proxy.

Ambassador is now integrated with Istio for end-to-end encryption.

Integrating Ambassador with Istio 1.4 and Below

With Istio 1.4 and below, Istio stores it's mTLS certificates as a Kubernetes Secret in each namespace.

We can read these certificates from the istio.default Secret in the Ambassador namespace with a TLSContext.

Ambassador is now integrated with Istio for end-to-end encryption.

Integrating Prometheus Metrics Collection

Istio installs by default with a Prometheus deployment for collecting metrics from different resources in your cluster.

We can integrate Ambassador with the same Prometheus to give us a single metrics endpoint.

Istio's Prometheus deployment is configured using a ConfigMap. To add Ambassador as a Metrics endpoint, we need to update this ConfigMap and restart Prometheus.

  1. Export the current Prometheus configuration.

    • If you installed Istio with istioctl, you can get the YAML that was installed with

      This will export all of the YAML configuration used by Istio to a file named istio.yaml so you can update the ConfigMap there.

    • If you did not install with istioctl, you can export the YAML of the current ConfigMap in your cluster with kubectl:

      You should now have a ConfigMap that looks something like this:

  2. Update the Prometheus ConfigMap to add Ambassador as a scraping endpoint

    To configure Prometheus to get metrics from Ambassador, add the following config under scrape_configs in the Prometheus ConfigMap we exported above and apply it with kubectl.

  3. Restart and access the Prometheus UI

    The Prometheus pod must be restarted to start with the new configuration.

    After the pod restarts you can port-forward the Prometheus Service to access the Prometheus UI.

    You can now access the UI at http://localhost:9090/

Integrating Distributed Tracing

Enabling the tracing component in Istio gives you the power to observe how a request behaves at each point in your application.

Since Istio will propagate the tracing headers automatically, integrating Ambassador with the Istio Jaeger deployment will give you end-to-end observability of requests throughout your cluster.

To do so, simply create a TracingService and point it at the zipkin Service in the istio-system namespace.

After applying this configuration with kubectl apply, restart the Ambassador pod for the configuration to take effect.

You can now access the tracing service UI to see Ambassador is now one of the services.

Routing to Services

Above, we integrated Ambassador with Istio to take advantage of end-to-end encryption and observability offered by Istio while leveraging the feature-rich edge routing capabilities of Ambassador.

Now we will show how you can use Ambassador to route to services in the Istio service mesh.

  1. Label the default namespace for automatic sidecar injection

    This will tell Istio to automatically inject the istio-proxy sidecar container into pods in this namespace.

  2. Install the quote example service

    Wait for the pod to start and see that there are two containers: the quote application and the istio-proxy sidecar.

  3. Route to the service

    Traffic routing in Ambassador is configured with the Mapping resource. This is a powerful configuration object that lets you configure different routing rules for different services.

    The above kubectl apply installed the following basic Mapping which has configured Ambassador to route traffic with URL prefix /backend/ to the quote service.

    Since we have integrated Ambassador with Istio, we can tell it to use the mTLS certificates to encrypt requests to the quote service.

    Simply do that by updating the above Mapping with the following one.

    Send a request to the quote service using curl:

    While the majority of the work being done is transparent to the user, you have successfully sent a request to Ambassador which routed it to the quote service in the default namespace. It was then intercepted by the istio-proxy which authenticated the request from Ambassador and exported various metrics and finally forwarded it on to the quote service.

Enforcing Authentication Between Containers

Istio defaults to PERMISSIVE mTLS that does not require authentication between containers in the cluster. Configuring STRICT mTLS will require all connections within the cluster be encrypted.

  1. Configure Istio in STRICT mTLS mode.

    This will enforce authentication for all containers in the mesh.

    We can test this by removing the tls configuration from the quote-backend Mapping and sending a request.

  1. Configure Ambassador to use mTLS certificates

    As we have demonstrated above we can tell Ambassador to use the mTLS certificates from Istio to authenticate with the istio-proxy in the quote pod.

    Now Ambassador will use the Istio mTLS certificates when routing to the quote service.

Grafana

The Istio Grafana addon integrates a Grafana dashboard with the Istio Prometheus deployment to visualize the metrics collected there.

The metrics Ambassador adds to the list will appear in the Istio dashboard but we can add an Ambassador dashboard as well. We're going to use the Ambassador dashboard on Grafana's website under entry 4689 as a starting point.

First, let's start the port-forwarding for Istio's Grafana service:

Now, open Grafana tool by accessing: http://localhost:3000/

To install the Ambassador Edge Stack Dashboard:

  • Click on Create
  • Select Import
  • Enter number 4698

Now we need to adjust the Dashboard Port to reflect our Ambassador Edge Stack configuration:

  • Open the Imported Dashboard
  • Click on Settings in the Top Right corner
  • Click on Variables
  • Change the port to 80 (according to the ambassador service port)

Next, adjust the Dashboard Registered Services metric:

  • Open the Imported Dashboard
  • Find Registered Services
  • Click on the down arrow and select Edit
  • Change the Metric to:

Now let's save the changes:

  • Click on Save Dashboard in the Top Right corner

FAQ

How to Test Istio Certificate Rotation

Istio mTLS certificates, by default, will be valid for a max of 90 days but will be rotated every day.

Ambassador will watch and update the mTLS certificates as they rotate so you will not need to worry about certificate expiration.

To test that Ambassador is properly rotating certificates you can shorten the TTL of the Istio certificates so you can verify that Ambassador is using the new certificates.

In Istio 1.5 and above, you can configure that by setting the following environment variables in the istiod container.

In Istio 1.4 and below, you can configure this by passing the following arguments to the istio-citadel container

This will make the certificates Istio issues expire in one hour so testing certificate rotation is much easier.