Dedicated Cloud Gateways public network architecture and security

Public Dedicated Cloud Gateways should be used when you are proxying your own infrastructure over public internet. Use a public deployment when your:

• Upstream services are already internet-facing (for example, SaaS backends or services shared across business units without private networking)
• Traffic volume doesn’t justify the operational overhead of private network peering
• Security model relies on application-layer controls rather than network-layer isolation

Public Dedicated Cloud Gateway endpoints are exposed via a public fully-qualified domain name (FQDN) and static public IP addresses.

Kong data planes egress to your upstream services over the public internet. Konnect exposes static egress IP addresses for each public Dedicated Cloud Gateway network. You must allowlist these IPs at your firewall or load balancer so that only Kong proxy traffic can reach your backends.

The following diagram shows how the architecture of a public Dedicated Cloud Gateway:

 
flowchart LR
    subgraph kong_account["Cloud provider"]
        subgraph kong_vpc["Kong-managed VPC"]
                dp1["Data plane node"]
                dp2["Data plane node"]
                dp3["Data plane node"]
        end
    end

    subgraph customer_infra["Customer infra"]
        lb["Load balancer"]
        vm1["VM"]
        vm2["VM"]
        vm3["VM"]
        lb -.-> vm1
        lb -.-> vm2
        lb -.-> vm3
    end

    dp1 --proxy--> lb
    dp2 --proxy--> lb
    dp3 --proxy--> lb

    style kong_account stroke-dasharray:3,rx:10,ry:10
  

When a Dedicated Cloud Gateway proxies traffic to upstream services over the public internet, you need security controls across the full request path. These validate who can call your APIs, and ensure your upstream services can trust that requests genuinely originate from Kong.

There are multiple security controls you can use to protect public Dedicated Cloud Gateways:

• Allow Kong proxy traffic by allowlisting egress IPs.
• Validate inbound API consumers before requests reach your upstream (mTLS Auth, OIDC).
• Authenticate Kong to your upstream service (upstream mTLS, shared secrets).
• Secure the inbound entry point itself (CDN/WAF).

These security controls protect against the following:

Public Dedicated Cloud Gateway security controls are complementary. A robust public internet configuration typically combines multiple layers:

• A minimal production configuration for sensitive services: Egress IP allowlisting with upstream mTLS
• A configuration for services that cannot do mTLS: Egress IP allowlisting with shared secret and OIDC

Note: We strongly recommend combining IP allowlisting with additional security controls in production.

For workloads with stricter isolation requirements, consider private upstream connectivity instead.

When to configure security controls

Public Dedicated Cloud Gateways are subjected to scanners when they are created, like any other publicly-exposed network. We recommend creating and securing your public Dedicated Cloud Gateway in the following order:

1. Before creating Gateway Services and Routes, create the Dedicated Cloud Gateway network and control plane in Konnect. The network will be scanned, but since there aren’t any Routes, scanners get 404s or connection resets.
2. Configure your CDN/WAF in front of the Dedicated Cloud Gateway data plane before you configure any Routes or Services.
3. Allowlist the Dedicated Cloud Gateway network egress IPs.
4. Configure the IP Restriction plugin globally (allowlisting your CDN’s egress IPs) so that even if someone hits the Dedicated Cloud Gateway data plane directly, they get rejected before any Route matching happens.
5. Configure your Routes and Services pointing to real upstreams.

Web Application Firewall (WAF)

You can use a Web Application Firewall (WAF) in front of your Dedicated Cloud Gateway as a first-line defense that filters and blocks malicious traffic before it reaches Kong Gateway. A WAF provides Layer 7 protection for HTTP(S) traffic and helps protect APIs against:

• OWASP Top 10 vulnerabilities
• Malicious bot traffic
• IP reputation threats
• Rate-based abuse
• Geo-based access restrictions

Kong strongly recommends configuring a WAF for public Dedicated Cloud Gateways. WAF configuration differs for public deployments.

A public Fully Qualified Domain Name (FQDN) exposes the Public Dedicated Cloud Gateways. WAF inspection requires HTTP visibility, which means the WAF must sit at an HTTP-aware layer, like:

• A CDN distribution
• An Application Load Balancer
• A cloud edge service

Because the Kong-managed Dedicated Cloud Gateway data plane exposes a DNS hostname instead of an IP address, you can’t chain another public load balancer in front of it (most load balancers’ target groups don’t support DNS-based targets). Instead, you must use a CDN because it natively supports DNS-based origins and can attach WAF policies at the distribution level.

Examples of CDN or edge services that support this pattern:

• Amazon CloudFront with AWS WAF
• Azure Front Door with Azure WAF
• Cloudflare (WAF built in)
• Fastly with Next-Gen WAF

The following diagram shows how traffic flows through a public Dedicated Cloud Gateway with an AWS WAF:

 
sequenceDiagram
    Client->>+CloudFront/WAF: Sends request, TLS terminated
    CloudFront/WAF->>CloudFront/WAF: WAF evaluates

    alt WAF blocks request
        CloudFront/WAF-->>Client: 403 Forbidden
    else WAF passes request
        CloudFront/WAF->>CloudFront/WAF: CloudFront injects origin header
        CloudFront/WAF->>Kong DP: Forwards request
        Kong DP->>Kong DP: Validates header

        alt Header missing or invalid
            Kong DP-->>Client: 403 Forbidden
        else Header valid
            Kong DP->>Kong DP: Matches route
            Kong DP->>Your upstream in AWS: Applies plugins, proxies request
            Your upstream in AWS-->>Kong DP: Response
            Kong DP-->>CloudFront/WAF: Response
            CloudFront/WAF-->>Client: Response
        end
    end
  

In this model:

• CloudFront acts as the public edge entry point.
• AWS WAF is attached to the CloudFront distribution.
• The CloudFront origin is the Dedicated Cloud Gateway public DNS edge (public FQDN).
• The Dedicated Cloud Gateway data plane receives traffic from CloudFront and forwards it to the gateway data planes.

The sections in this guide describe how to configure a WAF in AWS, but they can be adapted for Azure and GCP.

For more information about all Kong Gateway WAF configurations and plugins, see Kong Gateway WAF capabilities.

Configure AWS WAF

When a Dedicated Cloud Gateway is deployed in public mode, it exposes a public FQDN. Without additional controls, clients could attempt to access this public endpoint directly and bypass CloudFront and AWS WAF protections.

To ensure all traffic passes through CloudFront, configure origin validation between CloudFront and Kong:

1. Configure CloudFront to inject a custom origin header. For example: X-Origin-Verify: <shared-secret-value>.
2. Configure your Dedicated Cloud Gateway to require the header. You can do this in two different ways:

   • Route-level header matching. For example:

     routes:
      - name: my-route
        paths:
          - /anything
        headers:
          x-origin-verify:
            - your-secret-value
     

     Copied!

   • Use a plugin, like Pre-Function or Request Termination.

3. Reject requests that don’t include the expected header value.
4. Store the shared header value securely, like in a Vault, and rotate the shared secret periodically.
5. If your CDN publishes static egress IP ranges, configure the IP Restriction plugin globally (allowlisting your CDN’s egress IPs). Requests arriving from IPs outside the CDN’s published ranges are rejected at the Kong layer before any route matching occurs. Some CDNs that publish static egress IP ranges include CloudFront, Cloudflare, Azure Front Door, and Fastly.
6. Combine origin validation with AWS WAF managed rules and rate limiting for layered protection.

Egress IP allowlisting

Konnect exposes the static egress IP addresses for your Dedicated Cloud Gateway network in the Konnect UI. You must configure your upstream firewall, security group, or load balancer to accept inbound connections from these IPs only. This ensures that even if a Service is publicly accessible, only your Kong data planes can call it.

Egress IPs are scoped per Dedicated Cloud Gateway network and per region. If you use multiple Dedicated Cloud Gateway networks, allowlist the egress IPs from each relevant network.

To allowlist the egress IPs, do the following:

1. In the Konnect sidebar, click API Gateway.
2. Click your Dedicated Cloud Gateway.
3. Click Connect.
4. Copy and save the IPs listed in Public Egress IPs.
5. In your cloud provider console, add inbound rules to your upstream service’s security group or firewall to allow traffic from those IP ranges on the relevant port (typically 443 or 80).
6. Restrict inbound traffic on that port to the allowlisted IPs, in addition to any other legitimately permitted sources.

Mutual TLS (mTLS)

Mutual TLS authenticates both the Kong data plane and your upstream service cryptographically. The upstream rejects any connection that doesn’t present a valid certificate, regardless of source IP. This provides a strong identity guarantee even if an IP allowlist is bypassed or shared with another system.

Kong supports two mTLS modes for upstream connections: upstream mTLS and inbound mTLS.

Upstream Mutual TLS (mTLS)

Kong presents a client certificate to your upstream service when establishing the connection. Configure this on the Kong Service object by referencing a certificate stored in Konnect via the client_certificate field.

The following is an example Service configuration using decK:

_format_version: "3.0"
services:
  - name: my-service
    url: https://api.internal.example.com
    client_certificate:
      id: "$CERT_ID"
    tls_verify: true
    ca_certificates:
    - "$CA_CERT_ID"

In this example, your upstream verifies Kong’s client certificate against a known CA before accepting the connection.

Inbound mTLS with the mTLS Auth plugin

The mTLS Auth plugin validates client certificates presented to Kong from downstream API consumers. Use this when your consumers must also authenticate with certificates, creating end-to-end mutual authentication. For Services handling sensitive data, combine upstream mTLS with egress IP allowlisting for in-depth defense.

Example plugin configuration:

echo '
_format_version: "3.0"
plugins:
  - name: mtls-auth
    service: my-service
    config:
      ca_certificates:
      - "$CA_CERT_ID"
' | deck gateway apply -

Shared secrets with the Request Transformer plugin

If your upstream service cannot terminate mTLS but you need a lightweight way to verify that requests originate from Kong, inject a shared secret header using the Request Transformer plugin.

Example plugin configuration:

echo '
_format_version: "3.0"
plugins:
  - name: request-transformer
    config:
      add:
        headers:
        - x-kong-origin-verify:{vault://env/KONG_SHARED_SECRET}
' | deck gateway apply -

Replace env/KONG_SHARED_SECRET with the path matching your configured vault backend (hcv, aws, gcp, or env). See the Secrets management documentation for vault configuration options.

Your upstream service validates the presence and value of this header before processing the request. If the header is absent or incorrect, the upstream rejects the request.

Keep the following in mind:

• Store the secret as a Konnect Vault reference, not as a plaintext value
• Rotate the secret on a regular schedule
• Combine with egress IP allowlisting so the header alone isn’t the only control

Token-based authentication with OpenID Connect

For APIs where caller identity matters beyond network origin, use the OpenID Connect plugin to validate JWTs or opaque tokens before forwarding requests upstream.

Kong does the following:

1. Validates the token at the Gateway.
2. Forwards claims to your upstream as headers.

Your backend receives a verified identity without needing to perform its own token validation.

This is particularly useful when:

• Upstream services are shared across multiple calling systems
• You want Kong to act as the centralized token validation and enforcement point
• You need fine-grained authorization based on token claims (scopes, roles, tenant ID)

For an example plugin configuration, see JWT access token authentication