• The API Platform for AI.

      Explore More
      Platform Runtimes
      Kong Gateway
      • Kong Cloud Gateways
      • Kong Ingress Controller
      • Kong Operator
      • Kong Gateway Plugins
      Kong AI Gateway
      Kong Event Gateway
      Kong Mesh
      Platform Core Services
      • Gateway Manager
      • Mesh Manager
      • Service Catalog
      Platform Applications
      • Developer Portal
      • API and AI Analytics
      • API Products
      Development Tools
      Kong Insomnia
      • API Design
      • API Testing and Debugging
      Self-Hosted API Management
      Kong Gateway Enterprise
      Kong Open Source Projects
      • Kong Gateway OSS
      • Kuma
      • Kong Insomnia OSS
      • Kong Community
      Get Started
      • Sign Up for Kong Konnect
      • Documentation
    • Featured
      Open Banking SolutionsMobile Application API DevelopmentBuild a Developer PlatformAPI SecurityAPI GovernanceKafka Event StreamingAI GovernanceAPI Productization
      Industry
      Financial ServicesHealthcareHigher EducationInsuranceManufacturingRetailSoftware & TechnologyTransportation
      Use Case
      API Gateway for IstioBuild on KubernetesDecentralized Load BalancingMonolith to MicroservicesObservabilityPower OpenAI ApplicationsService Mesh ConnectivityZero Trust SecuritySee all Solutions
      Demo

      Learn how to innovate faster while maintaining the highest security standards and customer trust

      Register Now
  • Customers
    • Documentation
      Kong KonnectKong GatewayKong MeshKong AI GatewayKong InsomniaPlugin Hub
      Explore
      BlogLearning CentereBooksReportsDemosCase StudiesVideos
      Events
      API SummitWebinarsUser CallsWorkshopsMeetupsSee All Events
      For Developers
      Get StartedCommunityCertificationTraining
    • Company
      About UsWhy Kong?CareersPress RoomInvestorsContact Us
      Partner
      Kong Partner Program
      Security
      Trust and Compliance
      Support
      Enterprise Support PortalProfessional ServicesDocumentation
      Press Release

      Kong Advances Konnect Capabilities to Propel Today’s API Infrastructures into the AI Era

      Read More
  • Pricing
  • Login
  • Get a Demo
  • Start for Free
Blog
  • Engineering
  • Enterprise
  • Learning Center
  • Kong News
  • Product Releases
    • API Gateway
    • Service Mesh
    • Insomnia
    • Kubernetes
    • API Security
    • AI Gateway
  • Home
  • Blog
  • Enterprise
  • Deployment Patterns for API Gateways Within a DMZ
Enterprise
October 28, 2020
5 min read

Deployment Patterns for API Gateways Within a DMZ

Ahmed Koshok
Senior Staff Solutions Engineer, Kong

What is a DMZ Network?

A DMZ – Demilitarized Zone – is a military term, roughly summarized, as an area between two adversaries established as a buffer in order to reduce, or eliminate, the possibility of further conflict.

In networking, the term usually refers to an area that acts as a buffer between two segregated networks. Here is a simplified visualization.

Figure 1. Simplified diagram of a DMZ

The DMZ is the network zone between two network firewalls, marked by the two vertical bars, in the figure. The firewall on the left, the left vertical bar, may be configured to allow some traffic from the internet into the DMZ. The firewall on the right, the right vertical bar, may also be configured to allow traffic from the DMZ into the internal network. Traffic from the internet cannot reach the internal network directly without crossing the DMZ.

DMZ Network and API Security

It seems hardly a week goes by without a serious breach taking place at a high profile organization. As organizations continue to digitize their offerings they are using more APIs to create and expose their digital assets. This presents a new attack surface. The question then is: how can APIs be exposed to external parties to meet the digitization demands while reducing or mitigating the risk of a breach? In this article we review how the Kong API Gateway accomplishes this in a variety of deployment patterns.

First, we assume the APIs are deployed on-premise in an internal network. We can also deploy them in the cloud or in a hybrid model, but we keep our use case simple in this example. The models we describe apply equally to on-premise and cloud deployments and constitute and advantage for Kong’s flexibility.

Deploying API Gateway

The first model deploys a Kong gateway in the DMZ.

Figure 2. An API Gateway in a DMZ

In this configuration, traffic originating from the internet is allowed to reach the Kong instance that is running in the DMZ via HTTP or HTTPS. Kong will then do a few useful things, possibly including:

  • Ensure the traffic is confidential
  • Identify the consumers
  • Permit or reject consumers from doing certain things
  • Log requests
  • Cache requests
  • Put a limit on how fast requests may be consumed

Upstream of Kong, there are two internal systems that currently have functionality, or data that are made available to external consumers.

This configuration is suitable for this purpose. Now we will make things more interesting…

The two teams that exposed APIs became highly successful. Their products and services are heavily used, and the organization is benefiting from this. More teams are encouraged to equally expose data and to digitally enable transactions. We initially had 2 systems, now we have 12. Is this still a suitable configuration? Could there be a better fitting configuration? Do we want to manage 12, and increasingly more configurations, through the firewall? If there is a breach into another system in the DMZ, that system could potentially have access to any exposed internal systems from the firewall on the right.

Figure 3. An API Gateway behind a DMZ

To mitigate this, we introduce an alternative to our first configuration. We move the gateway into the internal network as seen in Figure 3. We then configure the left firewall to direct the traffic originally intended to Kong to go to the right firewall instead. The right firewall then passes this traffic to Kong. We, in effect, tunnel through the DMZ. The gateway carries on enforcing the same policies as it has done before. We did not have to open more paths in the right firewall than we did in the previous configuration; only two ‘holes' , one for HTTP and one for HTTPS, remain open. The API consumers do not know, or mind, where the API gateway is running. But now things get more interesting again…

API Internal Applications

The internal applications now need to offer APIs to one another that are different from APIs offered to the external consumers. Should we have the same instance of Kong be the gateway for these internal applications and consumers? If we do, do we not provide an attack surface via the lack of segregation of APIs? In theory, if somehow, an external consumer knows the path to an internal API, they could try to access it. We need to mitigate this. Fortunately, there are a handful of useful tools available to us.

  • We can use the access control list plugin to restricted access to certain routes or services to only internal consumers.
  • Instead, or in combination with this, we can use the IP restriction plugin to limit access to services or routes based on certain IP or IP ranges that we know, with certainty, are internal.
  • We can run another instance of the gateway for internal traffic only, and this will be the instance the applications use to communicate with one another, as seen in Figure 4.

Figure 4. An internal and external API Gateway behind a DMZ

  • We can run another instance of Kong in the DMZ, which filters traffic to the internal gateway, ensuring that only routes that are externally facing are allowed to continue, as seen in Figure 5.

Figure 5. Two gateways, in and behind a DMZ

In both of the last two deployment patterns, we introduced a second gateway, which needs a necessary configuration and administrative overhead. They are also more ‘complex' deployments. They have to be as they are solving a more complex use case.

We demonstrated in this progressively more complex environment that there is no single deployment model that is suitable for all conditions. All deployments have their pros, cons, and overheads. The choice of deployment is a function of mitigating legitimate security concerns. Fortunately, Kong's flexibility in deployment, and configuration, lends itself to adapt to such situations.

At Kong, we encourage you to exercise sound analysis of your potential security threats, and to apply a suitable approach to ensure the safety of your data and services. We hope this article assists you in this regard.

Topics:API Gateway
|
API Security
|
Ingress
Powering the API world

Increase developer productivity, security, and performance at scale with the unified platform for API management, service mesh, and ingress controller.

Sign up for Kong newsletter

Platform
Kong KonnectKong GatewayKong AI GatewayKong InsomniaDeveloper PortalGateway ManagerCloud GatewayGet a Demo
Explore More
Open Banking API SolutionsAPI Governance SolutionsIstio API Gateway IntegrationKubernetes API ManagementAPI Gateway: Build vs BuyKong vs PostmanKong vs MuleSoftKong vs Apigee
Documentation
Kong Konnect DocsKong Gateway DocsKong Mesh DocsKong Insomnia DocsKong Plugin Hub
Open Source
Kong GatewayKumaInsomniaKong Community
Company
About KongCustomersCareersPressEventsContactPricing
  • Terms•
  • Privacy•
  • Trust and Compliance
  • © Kong Inc. 2025