It’s not uncommon for organizations to have to deploy solutions across (or among) multiple security domains. Here, we use the term “security domain” to refer to a segregated network environment, like a restricted internal network or a DMZ. This post will explore some design considerations when deploying Kong Mesh (and Kuma, the CNCF-hosted open source project upon which Kong Mesh is built) in environments with multiple security domains. After reading this post, you’ll have a better idea of some of the different ways Kong Mesh can be architected to meet your specific security requirements.

Although this blog post only refers to Kong Mesh, everything mentioned here also applies to Kuma unless noted otherwise.

Potential Approaches

When deploying Kong Mesh in an environment with multiple security domains, customers have at least three general approaches to consider:

1. Using a zone as your security domain boundary
2. Using a mesh as your security domain boundary
3. Using the control plane as your security domain boundary

Which one of these approaches is right for you? The answer is, “It depends.” Each of these approaches has its advantages and disadvantages. It is up to customers to evaluate the advantages and disadvantages of each approach to determine which approach is the right one for their organization.

Before proceeding, you may find it useful to review this blog post on the role of zones and meshes in Kong Mesh.

First, let’s take a deeper look at using a zone as your security domain boundary.

The Importance of Zero-Trust Security When Making the Microservices Move

Using a Zone as Your Security Domain Boundary

In this architecture, each zone resides entirely within a single security domain; no zone ever exists in multiple security domains. This means you would end up with separate zones for your DMZ and your internal network, for example. Because each zone exists only within a single security domain, this also means that each zone control plane (recall that when using multiple zones, each zone has its own control plane) also resides entirely within a single security domain. However, the global control plane would “span” multiple security domains.

This architectural approach is illustrated in this diagram:

Using only a zone as a security boundary

This architecture has some advantages. One of the most notable advantages is that this architecture could be considered more flexible than the other approaches described here. Mesh policies can be applied “end to end” to any traffic flow between any two services in any zone, all from a single global control plane. Similarly, a single global control plane aggregates metrics and observability data. This simplifies the integration of Kong Mesh into customers’ existing observability infrastructure.

However, this approach also has some drawbacks of which users should be aware. Keep in mind that zones do not restrict connectivity (again, refer back to this blog post on zones and meshes for more details). Therefore, cross-zone—and therefore cross-security domain—traffic would be allowed by default. Users have to explicitly take steps to prevent cross-zone traffic, typically using a TrafficPermission policy. This means it’s easier to “accidentally” allow traffic between security domains that might not otherwise be permitted to communicate directly.

It would also be necessary to “punch” a hole in any intervening network segmentation mechanisms (like network firewalls, network access control lists, or security groups) to allow traffic between the zone control plane in each security domain and the global control plane (TCP port 5685, by default), as well as to allow traffic to flow between the Zone Ingresses for each zone (TCP port 10000, by default).

Given the drawbacks, you might think you can’t or shouldn’t use zones when dealing with multiple security domains. However, any Kong Mesh deployment that involves multiple security domains will likely involve multiple zones. Recall that a Kong Mesh zone is used to describe a network segment in which data plane proxies can freely communicate with each other. Therefore, it would be typical to use a zone to represent each security domain because you want Kong Mesh to know that data plane proxies in one security domain (zone) can’t freely communicate with data plane proxies in a different security domain (zone).

However, using only zones and nothing else may be overlooking a key part of Kong Mesh functionality that is very useful in dealing with multiple security domains: the mesh.

API Gateway vs. Service Mesh…Join me to learn how they work together.

Using a Mesh as Your Security Domain Boundary

Kong Mesh supports multiple, logical meshes as policy and traffic boundaries, as described in the blog post explaining zones and meshes in Kong Mesh. Since a mesh provides a logical boundary, it can make sense as part of a Kong Mesh architecture that involves multiple security domains.

What advantages does using multiple meshes bring to such an environment? For one, each mesh is a separate policy domain, meaning that policies must be managed on a per-mesh basis. This reduces the possibility that a policy intended for an internal mesh might accidentally be applied to a DMZ mesh or vice versa. Once applied, a policy assigned to one mesh cannot affect traffic on a different mesh.

A multi-mesh deployment shares the benefit of aggregating metrics and observability data from a single source with a single global control plane.

Finally, cross-mesh traffic is subject to additional inspection and controls. Since traffic must exit the source mesh and then re-enter the destination mesh, network segmentation mechanisms like firewalls, network access control lists, NAT devices, or security groups can act upon these cross-mesh traffic flows.

Typically, to address an environment with multiple security domains, meshes would be combined with zones in an architecture that might look something like this:

Using a mesh as a security boundary

This approach allows you to combine the logical separation provided by a mesh with the connectivity-modeling functionality of a zone. This puts the “superpowers” of these features of Kong Mesh to their best use.

However, even this approach is not without any drawbacks. Connectivity to and from the global control plane and connectivity between the Zone Ingresses must still be allowed through whatever network segmentation devices are in place, like network firewalls. Operationally, policies need to be managed for each mesh separately, potentially introducing additional operational overhead. As mentioned earlier, though, there is the related benefit that policies can be managed independently for each mesh.

As illustrated in the diagram above, though, there is still one shared element among the different security domains: the global control plane. The final approach eliminates even that shared component.

The age of the load balancer has come to an end. Here’s how Kong Mesh helps you break free with ZeroLB.

Using the Global Control Plane as Your Security Domain Boundary

The third and final approach we’ll discuss in this blog post is using the global control plane as the security domain boundary. This is a true “shared nothing” architecture; each security domain maintains its own global control plane, its own set of logical meshes and its own set of connectivity-modeling zones. Each Kong Mesh instance is completely autonomous and independent of other Kong Mesh instances.

This approach might look something like the following:

Using the global control plane as a security boundary

As you can see, you can (and should!) still use zones to model the underlying connectivity, and it’s still possible to use multiple meshes where it makes sense. Traffic moving between Kong Mesh instances has to exit the source instance and traverse the network to re-enter the destination instance, allowing external security mechanisms to control cross-security domain traffic and enforce appropriate security controls.

Each instance has its own control plane, so all policies are independently managed and maintained. Barring human error, this completely prevents policies in an instance of Kong Mesh in one security domain from affecting another instance of Kong Mesh in a different security domain.

While having a true “shared nothing” architecture does mean that policy and configuration are maintained separately for each Kong Mesh instance, this separate maintenance could be considered to be requiring additional operational overhead. It’s not possible, for example, to create a single policy that would affect traffic “end to end” across security domains. It’s also necessary to separately configure metrics and observability integration for each Kong Mesh instance. However, this configuration is a one-time task that usually occurs when Kong Mesh is deployed (and can often be automated).

Conclusion

So what’s the right approach for you? That depends on a lot of different factors. Some organizations may want—or even need—the rigid isolation provided by separate, independent instances of Kong Mesh in each security domain. Other organizations may want something more flexible, and choose to use a single Kong Mesh instance that leverages multiple meshes and multiple zones. The key takeaway here is that Kong Mesh supports a variety of ways to support your organization’s requirements and needs. How are you going to put Kong Mesh to work in your environment?