Firewall requirements on Kubernetes

Diagram for port configuration, and list of active ports, for an IBM® API Connect deployment on Kubernetes.

Required Ports between zones

The following network diagram example helps to explain which ports must be configured in an API Connect network. Specific ports must be configured to enable the communication between the various zones, both public and private, in a network.

The ports specified in the diagram are default ports. Check your deployment to understand which communication, if any, is configured to use non-default ports.

Network diagram
Table 1. Key for the network diagram example.

The following table lists the port numbers with a usage description.

  Usage description Default port number
 1  API request/response – Users invoking the provided APIs. 443 HTTPS from Public zone to Gateway zone
 2  DataPower® administration – Internal operators who are managing the Gateway servers. 22 SSH, 9090 HTTPS from Protected zone to Gateway zone
 3  API Manager – Internal business users who are defining and monitoring APIs. 443 HTTPS from Protected zone to Management zone
 4  Cloud Manager – Internal operators who are administering the Cloud. 22 SSH, 443 HTTPS from Protected zone to Management zone
 5  Developer Portal administration – Internal operators who are managing the Portal servers. 22 SSH, 443 HTTPS from Protected zone to Management zone
 6  Gateway servers post traffic to Analytics service. 443 HTTPS from Gateway servers to Analytics service
 7  Push configuration – Management servers communicate bi-directionally with Gateway servers. 3000 or 443 (dependent on configuration) HTTPS Management servers to and from Gateway servers for webhook delivery
 8  Push configuration/webhooks – Management servers push configuration and webhooks to the Developer Portal. 443 HTTPS Management servers to Developer Portal servers for webhook delivery
 9  Pull configuration/make API calls – Developer Portal servers pull configuration and call REST APIs. 443 HTTPS from Developer Portal servers to Management servers within Management zone
 10  Developer Portal – External developers who are accessing the Developer Portal. 443 HTTPS from Public zone to Developer Portal management zone. The reverse proxy/DataPower WAF for incoming web traffic to the Developer Portal cluster must be a transparent proxy - no modification of the portal URL, port, host name or path is allowed. For more information, see Configuring a proxy.
 11  Push API definition to Management server. Pick up credential for microservice code push. 443 HTTPS from Protected zone to Management zone
 12  Analytics offload Port will depend on type of plugin and protocol used for the offload. Some possible protocols are: HTTP, HTTPS, TCP, UDP, KAFKA
 13  Analytics accesses NTP Standard NTP
 14  Analytics access DNS Standard DNS
 15  Management service queries Analytics service 443 HTTPS within Management zone
 16  The Portal service invokes an API (GET) on the Analytics service to retrieve data. 443 HTTPS within Management zone

Firewall port requirements on Kubernetes

The following tables lists ports that must be open in both cluster and non-clustered deployments.

Table 2. Firewall port requirements common to all subsystems
Subsystem Ports and description
Ports that must be open on all API Connect subsystems

The following ports must be open on the Management Server, Analytics, and Developer Portal subsystems, whether in a cluster or not.

  • 22 (inbound and outbound) SSH
  • 53 (outbound) DNS
  • 123 (outbound) NTP
  • 443 (inbound and outbound) Used by all subsystems for communication with other subsystems
  • 44135 (inbound and outbound)

Each subsystem uses ports in addition to the ports in Table 2. See the following table.

Table 3. Additional firewall port requirements for each subsystem
Subsystem Ports and description
Management Service

Management Service uses the ports in Table 2 plus:
Developer Portal

The Developer Portal uses the ports listed in Table 2, plus:
Analytics

The Analytics subsystem uses the ports listed in Table 2.

Analytics port usage considerations:

  • 161 for SNMP is required for both non-clustered and clustered deployments
  • In a non-clustered deployment, no additional ports are required.
  • Analytics supports an optional configuration for offload of data. This configuration might require additional outbound ports to be open.
Gateway Server The Gateway Server uses these ports in both non-clustered and clustered deployments:
  • 161 (inbound and outbound) SNMP
  • 162 (outbound) SNMP traps
  • 3000 (inbound) Gateway Service local port (configurable)
  • 5550 (inbound) XML management port (configurable)
  • 5554 (inbound) REST management port (if enabled; configurable)
  • 9022 (inbound) Gateway SSH (if enabled; configurable)
  • 9090 (inbound) Web GUI console (if enabled; configurable)
  • 9443 (inbound) Gateway local port (configurable)

Communications inside the Gateway cluster

There are a number of important points to note regarding the communications within the Gateway cluster.

  • We advise that you use the same port for all Gateway servers within a cluster.
  • Gateway servers communicate with each other to synchronize invocation counts.
  • All Gateway servers in a Gateway cluster must be able to reach all of the other Gateway servers in the same Gateway cluster.
  • Gateway servers in a Gateway cluster do not directly communicate with Gateway servers in a different Gateway cluster.
  • All Gateway servers must be able to reach the management subsystem platform API endpoint, which was configured during the installation of your API Connect environment.

Ethernet interface usage

To separate network traffic, you can use two or more Ethernet interfaces on the DataPower appliance on which a Gateway server is installed. For example, you can use one interface for internal IBM API Connect communications, and another for processing incoming API calls.