October 25, 2023
9 min read

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

Discover how API management and service mesh can go hand in hand toward secured platforms

Baptiste Collard
Kong Technical Account Manager

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.


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.

Youtube thumbnail

Modernization challenges

Service meshes provide you with new capabilities like cloud migration or multi-tenancy. This article explains how multi-tenancy can be implemented both in the data plane and the control plane.

Also, by leveraging the Kong Mesh universal data plane, it becomes possible to migrate legacy workloads to the cloud. Our recent announcement about Kong Mesh certification on Red Hat OpenShift goes into more detail for this use case.

Accelerate product development cycles

With the spread of microservices, there are many cross-cutting concerns that developers have to deal with. For instance, client-side load-balancing, failover, retries, and many more. These capabilities can be delegated to the underlying platform. 

The service mesh platform is transparent to the developers and is used as a commodity. Developers can control the mesh features through a collection of ready-to-use policies that are shipped along with their apps (typically YAML files, which are easily versionable).

Also, the mesh platform will produce normalized access logs, metrics, and traces. Developers will appreciate not having to work on those and benefit from ready-to-use connectivity dashboards.

Gather all the N/S and E/W metrics into your Observability platform

API gateways produce metrics, as well as service mesh platforms and their sidecars. It’s best to choose a platform that is cloud-agnostic and that embraces the OpenTelemetry standard.

Kong Gateway and Kong Mesh both come with ready-to-use Grafana dashboards that both surface the health of the data plane, as well as the control plane.

Furthermore, with a universal data plane, you can gain observability from legacy workloads like heavyweight Java runtimes (Tomcat, WebSphere, FUSE/Karaf, etc.)

Benefits of a global control plane

Building services for the business is where you should spend the most time. Enforcing security policies is another big step. Operating control planes for your API gateway or service mesh is again another job. 

Kong Konnect is here to help when it comes to operating all these control planes. Think of Kong Konnect as a super control plane that was designed for both platform operators and developers.

Kong Konnect helps you operate your API gateways and service mesh with high availability and multi-tenancy as its core building blocks.

Kong Konnect helps you to focus on your business and data rather than on some technical control planes.

A global control plane like Kong Konnect helps you gather North-South traffic metrics with East-West traffic metrics and traces

Key takeaways

  • Enterprise API gateways are still required for business-oriented applications and also for analytics and monetization.
  • Adopt mesh gateways at the edge of each platform/zone.
  • A mesh gateway can validate incoming requests and optionally only allow traffic exiting the enterprise API Gateway (signed tokens are good practice).
  • 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.
  • It’s OK to spread applications across your platforms. They can be part of an extended but unified mesh.
  • You can also have multiple meshes on a single platform or span multiple platforms.
  • Choose a platform that is cloud-agnostic and that embraces OpenTelemetry.
  • Developers use the mesh platform as a commodity to increase their velocity and avoid code duplication.
  • With a universal data plane, you can gain observability from legacy workloads like heavyweight Java runtimes (Tomcat, WebSphere, FUSE/Karaf, etc.) or databases.
  • Service meshes provide you with new capabilities like workload migration or multi-tenancy (which help reduce costs).
  • global control plane like Kong Konnect helps you gather North-South traffic metrics with East-West traffic metrics and traces.
  • Focus on your business and data, not on the technical control plane that you can delegate to Kong Konnect.


As companies adopt microservices and distributed systems, securing internal east-west traffic between services becomes crucial. While API gateways like Kong Gateway help manage north-south traffic at the edge, service meshes like Kong Mesh provide granular control over service-to-service communications.

Kong Gateway and Kong Mesh can work together to implement a zero-trust security model. 

Ready to get started with Kong and implement zero-trust architecture across your APIs and microservices? Start a free trial of Kong Konnect today.