API Gateway and Service Mesh: Bridging the Gap Between API Management and Zero-Trust Architecture

Over the last ten years, Kongers have witnessed hundreds of companies adopting a full lifecycle API management platform and have been working with the people behind the scenes, the “API tribes.” We’ve also learned from the field that API tribes most often have to deal with heterogeneous platforms, infrastructures, and clouds. It’s a common fact that they operate API platforms along with more legacy middleware platforms. 

On top of that, the security teams are regularly challenging the API tribes about security standards like SOC2, GDPR, or PSD2.

Last but not least, the fresh paradigm of Zero-Trust is spreading all over company IT programs and roadmaps. CISOs' recurrent calls for help in obtaining the budget to implement a Zero-Trust approach have finally been heard by top management.

While it has become relatively easy for companies to safely expose APIs to a broader audience, with the help of enterprise API management platforms like Kong, there’s still a long way to go for securing internal service-to-service communications, a.k.a. East-West traffic.

This is where service mesh platforms come into play with their nice promises like Traffic Control, Observability, and Zero-Trust.

Now comes the time to bridge the gap between your enterprise API gateway and service mesh platforms in a seamless and future-proof way.

For more on this topic, watch the on-demand webinar: How an API Gateway and Service Mesh Architect Secure and Reliable Applications.

Overview

When it comes to securing your services, there are different ways of implementing security policies depending on the context. End-user-to-API calls are generally subject to authentication and authorization policies. But how do you address those for service-to-service connectivity? 

Again, depending on the granularity of these connections, you can imagine different scenarios either with internal gateways or through direct connections backed by a service mesh platform. 

With Kong Gateway and Kong Mesh, you can mix and match two breeds of gateways and enforce your API governance where it makes sense. For instance, you can apply authentication, authorization, rate-limiting, analytics, etc., at the edge of your platform with Kong Gateway, and apply authentication, authorization, and tracing for east-west traffic with Kong Mesh.

The combination of Kong Gateway and Kong Mesh will not only support Cross-App Connectivity but also cross-zone traffic, as detailed throughout this article.

Different zones and different concerns

A typical API gateway deployment looks like the following:

The enterprise API gateway is deployed in a public zone and sits in front of other private zones. Then, the security between these zones is typically enforced by firewalls. We all know how tedious firewall changes can be, and they generally allow access to the whole target subnet — which today sounds like an outdated way of working, far away from the principle of least privileges brought by the Zero-Trust paradigm.

To finely secure such East-West traffic, it’s now recommended to leverage service mesh platforms. Service mesh solutions have their own gateways that can perform a first round of authorization checks.

Gateway war?

Service mesh platforms aren’t meant to replace your enterprise API gateway. They’re just a new building block that best fits with microservices architecture and distributed applications.

Full lifecycle API Management platforms are here to stay. For instance, among the many purposes they are assigned, API monetization is one of them, and it basically can’t work without the metrics generated by such a platform.

Gateway hops

When our customers start deploying Kong Mesh, they quickly realize that they will have to compose with more gateways. But not all gateways are born the same, and it’s fine to use lightweight gateways where it makes sense.

One recurring — and totally valid — schema we see is using “micro-gateways” at the edge of each platform/zone. A micro-gateway can validate incoming requests and, for instance, could only allow access to the traffic exiting the enterprise API gateway.

One common question we hear from our customers is: “How do I prevent the misusage of my internal/mesh gateways?”. 

One of the first steps of a longer answer is to authenticate the client of the request. Doing so is easy at the API gateway level, with end-user authentication standards like OpenID Connect, or inside a service mesh (thanks to the underlying SPIFFE architecture). 

Still, how do you ensure the client goes through the enterprise API gateway before jumping into the mesh? And how do you pass the client identity from the enterprise API gateway to the mesh-ed applications?

Crossing network boundaries

North-South traffic

A common usage of the internal gateway is to make it trust the enterprise API gateway. Therefore, if the client request hits an internal gateway with a stamp from the trusted enterprise gateway, then the traffic is allowed.

Kong Gateway Enterprise comes with a great collection of ready-to-use plugins, and some of them are categorized as authentication plugins.

Typically, a Kong Gateway would be configured with the “OpenID Connect” plugin to authenticate end-users, bringing up a new header in the form of a JWT, itself carrying the identity of the end-user. 

This JWT is generally signed by the Identity Provider, protecting its claims against alteration. 

There are two scenarios here:

• This JWT is passed along with the original request to the upstream service (here, the Kong Mesh Gateway)
• A new JWT can be coined, or the existing JWT can be re-signed with an internal secret (private key) before forwarding the request upstream

If you choose to go with the second option, you might be interested in the “Kong JWT Signer” plugin.

In the end, when the request exits the Kong Gateway, there is a freshly signed token carrying a set of claims.

Now, on the mesh side, the Kong Mesh Gateway can be leveraged to verify this JWT.

With the help of Open Policy Agent, which is embedded into our Kong Mesh Data Plane (and built-in gateway) binaries, it becomes straightforward to validate the signature of a JWT (cryptographically signed bearer token). 

All you need to do is apply the MeshOPA policy to these built-in gateways.

Kong Mesh OPA policy — embracing the GitOps way

The policy shown above is applied at the built-in gateway level, at the edge of the mesh. The policy will use the JWT present in the HTTP request and validate it against a remote JWKS, which exposes public keys. It is a common way to ensure the identity of the client.

East-West traffic

Another kind of cross-zone traffic happens in service-to-service communication when the applications are spread across clusters. These connections don’t necessarily need to go through the enterprise gateway, but you still want to leverage service-mesh capabilities like encryption, zero-trust, monitoring, traffic shifting, etc.

Below is an example of how meshes can coexist and span multiple clusters or zones.

It’s a good practice to segregate applications into different meshes that belong to different domains or business units. With this approach, you get a first level of isolation for the different departments sharing the underlying platforms and therefore helps to reduce costs.

When a mesh spans multiple clusters and if you want to enforce fine-grained access policies between microservices, Kong Mesh does a lot of cryptographic work behind the scenes so that secured connections can happen in such a distributed system.

As shown in the following figure, when two services that are part of the same mesh talk to each other, then the traffic transparently flows through Ingress Gateways that are acting both as modern firewalls and routers.

Implement Zero-Trust step-by-step

As a general rule of thumb, it’s recommended to slowly move the cursor in your journey to the Zero-Trust wonderland. Start with platform-scoped policies, then application-scoped policies, and eventually shift to fine-grained microservice-scoped policies.

Kong will help you go down that path, starting with Kong Konnect runtime groups for environment/departments/LoB-scoped policies, then Kong Mesh mesh-wide policies for groups of application (or tenants) scopes (which can span multiple platforms), and eventually with Kong Mesh TrafficPermissions for more fine-grained policies like service-to-service communications (best fit for microservices).

As explained above, it’s OK to spread your applications across your platforms. Such applications can also be composed of databases and VMs or bare-metal servers. Kong Mesh supports all kinds of workloads thanks to its universal data plane.

If you’re looking for a quick demo of Kong Mesh capabilities, watch this workshop on getting started with Kong Mesh.