Gateway Management

What is an API Gateway and Gateway Management?

An API Gateway is the central management point for API traffic. It processes client requests by routing them to the appropriate backend services, transforming requests and responses when necessary, enforcing security policies, monitoring traffic, and ensuring overall API reliability.

Key Functions of an API Gateway

• Routing: Directs client requests to the appropriate backend service.
• Transformation: Converts request or response formats as needed.
• Authentication & Authorization: Validates client credentials and grants access permissions.
• Traffic Control: Manages and restricts API traffic to prevent backend overload.
• Logging & Monitoring: Records API usage data for tracking and analysis.
• Security & Protection: Blocks malicious attacks and enhances API security.

In APIM, the Kong API Gateway is used and provisioned as a Kubernetes (K8s) Deployment.

Gateway Management Menu

The Gateway Management menu in APIM allows users to:

• View and manage the list of gateways.
• Monitor the status of individual gateways.
• Query, create, update, and delete gateways per project.
• Manage multiple Gateway URLs.
• Configure node affinity, toleration, and topology settings.
• Set up TLS certificates for HTTPS security.
• Add metadata via annotations/labels (K8s Ingress Annotations/Labels).

Each Gateway URL represents an endpoint used for API requests.

For example, if an API is accessed via https://api.company.com/path, then the Gateway URL is api.company.com.

Gateway List Screen

The Gateway List screen provides an overview of all gateways within a project, enabling users to:

• View all gateways at a glance.
• Check CPU, Memory, and Replicas configurations.
• Monitor the running or standby status of each gateway.
• Search for specific gateways or create new ones.

Creating a Gateway

To create a new gateway, follow these steps:

Navigate to the Gateway Management menu.

Click "Create A Gateway"

Select a project

Select a project under which the gateway will be managed. For instruction to create a Project, please refer to Tenant Manager Console/Create a Project.

Configure the gateway settings

The Gateway Configuration section allows detailed customization of a gateway. Below are the key fields:

Gateway Type

• Purpose: Defines the API Gateway type.
• Mandatory: Yes
• Input Instructions: Aligns with project’s gateway type. Cannot be changed.

Gateway Name

• Purpose: Unique identifier for the Gateway.
• Mandatory: Yes
• Input Instructions: Can only use English letters, numbers, spaces, hyphen ‘-’, underscores ‘_’, or double commas ‘:’. Must start with an English letter.

Gateway Instance Name

• Purpose: Identifies the gateway instance.
• Mandatory: Yes
• Input Instructions: Automatically populated based on the Gateway Name.

Gateway Description

• Purpose: Provides additional details about the Gateway.
• Mandatory: No
• Input Instructions: Enter a short description.

Gateway Tags

• Purpose: Helps in filtering and searching Gateways.
• Mandatory: No
• Input Instructions: Gateway can have many tags. Input tags separated by pressing Enter.

Gateway CPU/Memory

• Purpose: Allocates resources for the Gateway.
• Mandatory: Yes
• Input Instructions: Adjust using sliders. Value ranges from 500 to 16000 m/mi.

DataBase CPU/Memory

• Purpose: Allocates resources for the internal database used by the Gateway.
• Mandatory: Yes
• Input Instructions: Adjust using sliders. Value ranges from 500 to 16000 m/mi.

Gateway Autoscaling

• Purpose: To auto scale the gateway resource allocation once deployed
• Mandatory: Yes
• Instructions: Toggle to turn on autoscaling. Once turned on, configure the autoscaling value for Minimum Replicas, Maximum Replicas, CPU usage, Memory usage.

Kong Namespace

• Purpose: Determines where the Gateway runs in Kubernetes.
• Mandatory: Yes
• Input Instructions: Select a Namespace from the dropdown list.

Kong Storage Class

• Purpose: Defines how storage is provisioned for the Gateway.
• Mandatory: Yes
• Input Instructions: Select a Storage Class from the dropdown list.

Storage Capacity

• Purpose: Specifies the storage allocation for the Gateway.
• Mandatory: Yes
• Input Instructions: Enter a value between 5 and 500 (Gi).

Kong Proxy Service Type

• Purpose: Determine the service type for the Kong proxy
• Mandatory: Yes
• Input Instructions: Select one from ClusterIP, NodePort, LoadBalancer. If NodePort or LoadBalancer is selected, requires user to enter Kong Proxy Service NodePort value (between 30000 and 32767)

Affinity

• Purpose: Affinity is used to control which nodes the gateway pods will be scheduled on, by matching node labels.
• Mandatory: Yes if toggled ON.
• Input Instructions: Toggle Affinity to ON to enable it. Then provide the Key and Value for node labels. This translates to a nodeAffinity rule in Kubernetes using requiredDuringSchedulingIgnoredDuringExecution. For example:

note

nodeAffinity:

Toleration

• Purpose: Toleration allows gateway pods to be scheduled onto nodes that are marked (tainted) for specific workloads.
• Mandatory: Yes if toggled ON.
• Input Instructions: After toggled ON, input the following:
  • Operator: Choose between Equal or Exists. Equal: key and value must match exactly. Exists: only the key needs to exist; value is not required.
  • Key and Value: Provide the taint key and value (value is optional if operator is Exists).

note

tolerations:

• effect: NoSchedule

key: "tolerationKey"

operator: "Equal" or Exists

value: "tolerationValue"

Topology Spread

• Purpose: Topology Spread Constraints ensure that gateway pods are distributed evenly across failure domains (like zones or nodes), improving resilience and availability.
• Mandatory: Yes if toggled ON.
• Input Instructions: After toggled ON, input the following:
  • Max Skew: The maximum allowed difference in the number of gateway pods between topology domains (e.g., if set to 1, the number of pods per zone must not differ by more than 1).
  • When Unsatisfiable: Select one of the following: ScheduleAnyway (default): still allows scheduling even if spread constraint can’t be fully satisfied; DoNotSchedule: blocks pod scheduling if constraint fails; DoNotScheduleIfNotSatisfied: newer strategy that restricts scheduling only if the spread condition is unsatisfied.

note

Example Kubernetes rule this maps to:

topologySpreadConstraints:

• maxSkew: 1

topologyKey: topology.kubernetes.io/zone

whenUnsatisfiable: ScheduleAnyway

labelSelector:

matchLabels:

app.kubernetes.io/instance: test-kong

Inner Redis

• Purpose: Allows internal Redis instance for caching.
• Mandatory: Yes if toggled
• Input Instructions: Toggle ON/OFF. If ON, the default Redis is installed when the Gateway is deployed. If OFF, user will be informed that APIM Redis does not support policies that use Redis (rate-limiting, jwt blacklist, OIDC). User needs to confirm on prompt to continue switching to OFF.

Fluent Bit

• Purpose: Fluent Bit is a lightweight log processor that collects, filters, and forwards logs from the gateway container.
• Mandatory: No
• Input Instructions: Once enabled, you can additionally select one of the following options for destination:
  • OpenTelemetry: Forwards logs and telemetry data using the OpenTelemetry agent.
  • Elasticsearch: Forwards logs to an Elasticsearch cluster for indexing and search.

Note: Only one of these options can be active at a time. If you enable one while the other is already active, a confirmation prompt will appear to disable the currently active one.

Kong Configuration

• Purpose: This field allows you to apply advanced, low-level configurations directly to the Kong Gateway runtime by providing raw configuration in JSON format, in case of needing fine-tuned performance or behavior.
• Mandatory: Yes if toggled
• Input Instructions: After toggled, a JSON editor will appear where you can enter custom Kong runtime settings.

note

Example:

"upstream_keepalive_idle_timeout": 60,

"upstream_keepalive_max_requests": 100000,

"nginx_http_keepalive_requests": 100000,

"upstream_keepalive_pool_size": 1024

Note: Misconfiguration may lead to unstable gateway behavior. Consult Kong documentation or your platform administrator before applying changes.

Gateway Configurations are summarized in the table below:

Field Name	Purpose	Input Notes	Mandatory
Gateway Type	Defines the API Gateway type.	Aligns with project’s gateway type. Cannot be changed.	Yes. Default is kong.
Gateway Name	Unique identifier for the Gateway.	Can only use English letters, numbers, hyphen ‘-’, underscores ‘_’, or double commas ‘:’. Must start with an English letter.	Yes
Gateway Instance Name	Identifies the gateway instance.	Automatically populated based on the Gateway Name.	Yes
Gateway Description	Provides additional details about the Gateway.	Enter a short description.	No
Gateway Tags	Helps in filtering and searching Gateways.	Gateway can have many tags. Input tags separated by pressing Enter.	No
Gateway CPU/Memory	Allocates resources for the Gateway.	Adjust using sliders. Value ranges from 500 to 16000 m/mi.	Yes
DataBase CPU/Memory	Allocates resources for the internal database used by the Gateway.	Adjust using sliders. Value ranges from 500 to 16000 m/mi.	Yes
Gateway Autoscaling	Enables automatic pod resource scaling after deployed.	Toggle ON/OFF. If ON, configure: Min Replicas, Max Replicas, CPU threshold (%), Memory threshold (%)	Yes if toggled
Kong Namespace	Determines where the Gateway runs in Kubernetes.	Select a Namespace from the dropdown list.	Yes
Kong Storage Class	Defines how storage is provisioned for the Gateway.	Select a Storage Class from the dropdown list.	Yes
Storage Capacity	Specifies the storage allocation for the Gateway.	Enter a value between 5 and 500 (Gi).	Yes
Kong Proxy Service Type	Defines the service type of Kong proxy for external access	Choose from: ClusterIP, NodePort, or LoadBalancer. Default is ClusterIP.	Yes
Affinity	Schedules gateway pods to nodes with matching labels.	Toggle ON/OFF. If ON, input Key and Value for node label	Yes if toggled
Toleration	Allows gateway pods to run on tainted nodes.	Toggle ON/OFF. If ON, select operator: Equal or Exists. Input Key, optional Value.	Yes if toggled
Topology Spread	Distributes pods evenly across zones to enhance availability.	Toggle ON/OFF. If ON, input: Max Skew (e.g., 1). Select option for When Unsatisfiable: choose from ScheduleAnyway, DoNotSchedule, DoNotScheduleIfNotSatisfied	Yes if toggled
Inner Redis	Allows internal Redis instance for caching.	Toggle ON/OFF. If ON, the default Redis is installed when the Gateway is deployed.	Yes if toggled
Fluent Bit	Enables OpenTelemetry agent for metric collection or Elasticsearch for log collection.	Can only choose between OpenTelemetry or Elasticsearch	Yes if toggled
Kong Configuration	Enables manual override of Kong configurations.	Toggle ON to enable editor and enter valid JSON.	Yes if toggled

Complete creation

Click on CREATE A GATEWAY button to complete the creation and store the gateway configuration.

Adding & Managing Gateway URLs

The Gateway URL Configuration allows users to define one or multiple public-facing domains for the API Gateway. It also supports TLS certificates for HTTPS, a Global BasePath for API routing, and additional metadata through annotations. Each gateway can have multiple Gateway URLs, defining how the API Gateway is accessed.

To start adding Gateway URLs, user can click on created Gateway listed in Gateway Management Screen to enter the Gateway Modification Screen.

From there, user can find the Gateway URL Configuration section underneath.

Below are the steps to create Gateway URLs:

Create a URL

Click ADDITION to create multiple URLs. New block to configure a URL will be created underneath.

Configure Gateway URL

Below are the key fields to configure for a Gateway URL:

Gateway URL

• Purpose: Defines the public domain(s) where the Gateway is accessible. If user changes the Gateway URL that is being used, the existing API may not be called properly.
• Mandatory: Yes
• Input Instructions: Enter a valid domain.
• Example:

note

your.domain.com

your.domain.com:8443

Global BasePath

• Purpose: Sets a common prefix for all APIs under this Gateway. If defined, all APIs under this Gateway will inherit this prefix. If Basepath is changed while being used, existing APIs may not be called properly.
• Mandatory: Yes
• Input Instructions: Enter a base path. If left /, the root is used.
• Example:

note

/ /apim

HTTPS Only and TLS Certificates

• Purpose: including tls.crt to enable HTTPS communication by providing the SSL certificate and tls.key file to authenticate the TLS certificate. If a network policy is applied that only allows HTTPS when communicating with the Gateway URL, user needs to toggle on HTTPS onl. If user is registering TLS Certificates with K8s Secret and processing TLS authentication through K8s Ingress, user must enter the tls.crt/tls.key value.
• Mandatory: Depending
• Input Instructions: Paste the certificate content in PEM format. Required for secure HTTPS connections.

Ingress Class

• Purpose: Specifies which ingress controller to use for this Gateway URL configuration.
• Mandatory: Yes
• Input Instructions: Select an ingress class from the dropdown. Available options may include:
  • nginx (default)
  • alb
  • appsec-kong

This setting routes the Gateway URL through the selected ingress controller.

Labels

• Purpose: Adds Kubernetes labels to the ingress resource created for this Gateway URL. Useful for classification or automation purposes.
• Mandatory: No
• Input Instructions: Input one or more Key-Value pairs. These labels will be applied to the created ingress object. Use the plus button to add multiple entries or the cross button to remove added entries.

Annotations

• Purpose: Adds Kubernetes ingress annotations for advanced configuration, such as custom timeouts, header manipulation, or controller-specific options.
• Mandatory: No
• Input Instructions: Can enter annotations using two modes:

Form Mode (JSON toggle OFF): Input Key and Value manually for each annotation. Some fields may be locked from editing depending on system constraints. Can add multiple annotations by clicking on the plus button, or removed added annotations by clicking on the cross button. Must keep at least one annotation.

Example:
Key: [nginx.ingress.kubernetes.io/proxy-connect-timeout](http://nginx.ingress.kubernetes.io/proxy-connect-timeout)
Value: more_clear_headers \"server\

JSON Mode (JSON toggle ON): Enter annotations as an array of key-value JSON objects in the editor.

Example:
"key": "[nginx.ingress.kubernetes.io/configuration-snippet](http://nginx.ingress.kubernetes.io/configuration-snippet)",
"value": "more_clear_headers \"server\";more_clear_headers \"via\";"

Gateway URL Configurations are summarized in the table below:

Field Name	Purpose	Input Notes
Gateway URL	Defines the public domain(s) where the Gateway is accessible. If user changes the Gateway URL that is being used, the existing API may not be called properly.	Enter a valid domain (e.g., api.example.com). Required field.
Global BasePath	Sets a common prefix for all APIs under this Gateway. If defined, all APIs under this Gateway will inherit this prefix.	Enter a base path (e.g., /api). If left /, the root is used.
TLS Certificates (tls.crt)	Enables HTTPS communication by providing the SSL certificate.	Paste the certificate content in PEM format. Required for secure HTTPS connections. If user is registering TLS Certificates with K8s Secret and processing TLS authentication through K8s Ingress, user must enter the tls.crt/tls.key value.
TLS Private Key (tls.key)	Used to authenticate the TLS certificate.	Paste the private key content in PEM format. Must match the certificate provided.
Ingress Class	Specifies which ingress controller to use for this Gateway URL configuration.	Select an ingress class from nginx (default), alb or appsec-kong
Labels	Adds Kubernetes labels to the ingress resource created for this Gateway URL.	Input one or more Key-Value pairs. Can add or remove pairs.
Annotations	Adds Kubernetes ingress annotations for advanced configuration.	Can enter multiple annotations using two modes: Key-Value pairs (JSON mode OFF) or JSON script (JSON mode ON).

Example:

note

If two Gateway URLs (api.example.com and service.example.com) are configured with a BasePath /api, then:

https://api.example.com/api/{API-Path}

https://service.example.com/api/{API-Path}

would be the valid API endpoints.

Modifying a Gateway

Users can modify existing gateways by:

• Selecting a gateway from the list.

• Editing configurable fields and input (Gateway Description, Gateway Tags, Gateway CPU/Memory, Database CPU/Memory, toggles and value,…).

• Updating Gateway URLs as needed.
• Saving changes to apply updates.

If user makes changes to Gateway URLs, remember to click on SAVE GATEWAY URL button before clicking on SAVING A GATEWAY button.

Delete gateway

Deleting a gateway will permanently remove all related data. This action cannot be undone.

• Navigate to Gateway Management.
• Select the gateway to be deleted.

• Click "Deleting A Gateway" and confirm the action.

warning

• APIs relying on this gateway will no longer be accessible.
• Ensure no active APIs are dependent before deleting.