Network requirements for inter-subsystem communication

Plan how to secure the network communications between your API Connect subsystems.

API Connect provides various configuration options that are related to inter-subsystem communication.

Support load-balancer TLS termination by disabling mTLS and enabling JWT security

If your network infrastructure requires that load-balancers implement TLS termination, then mTLS between API Connect subsystems can be disabled and JSON Web Token (JWT) security can be used instead.

Note: Although mTLS is disabled, the network communication is still secured with standard TLS, which does not require passthrough to be enabled on the load-balancers.

The management initiated communication to portal, analytics, and gateway subsystems can be secured with JWT. With JWT enabled, the portal, gateway, and analytics subsystems verify the JSON Web Token (JWT) sent from the management subsystem when it initiates communication with them. The subsystems that receive the token contact a JSON Web Key Set (JWKS) URL to verify it. The JWKS URL is hosted by the management subsystem, in a subpath of the management subsystem's platform REST API.

For more information about this feature, see Enable JWT security instead of mTLS.

Use services instead of routes (OpenShift) or ingresses (Kubernetes)

Note: This feature is available on Kubernetes and OpenShift deployments where the API Connect subsystems are within the same cluster. It is not available on two data center disaster recovery deployments: Two data center deployment strategy on Kubernetes and OpenShift.

For inter-subsystem communication, API Connect uses routes on OpenShift and Ingresses on Kubernetes. Both routes and ingresses require the exposure of external HTTPS endpoints. On API Connect deployments where all subsystems are in the same cluster, you can use services instead of routes or ingresses for inter-subsystem communication. When API Connect is configured to use services, all inter-subsystem communications are kept within the cluster, providing greater security and reduced load on external network infrastructure such as load-balancers.

In the context of inter-subsystem communication, the use of routes or ingresses is referred to as external communication, and the use of services is referred to as in-cluster communication.

You select whether to use external or in-cluster communication when you register your portal, gateway, or analytics subsystems with the management subsystem.

For more information about this feature, see In-cluster service communication between subsystems.

Enabling mTLS on management to gateway communication

On Kubernetes and on OpenShift installations where the top-level CR is not used, mTLS can be enabled for management to gateway communication. To enable mutual TLS between the Management client and the Gateway service’s manager endpoint, add mtlsValidateClient to the spec section:

spec:
  mtlsValidateClient: true

This ensures that the gateway service authenticates incoming requests from the API Manager, such as gateway service registration, and publishing APIs to the gateway service. Specifically, the gateway service requires that incoming requests present a certificate that was signed by the same CA that was used to sign the gateway service management endpoint. The gateway service management endpoint secret is specified under gatewayManagerEndpoint.hosts.secretName. The API Manager’s gateway client’s TLS credentials are specified in the ManagementCluster CR under gateway.client.secretName.

Note: In releases previous to 10.0.5.3, this property is called validateApimClient.

Note: On Cloud Pak for Integration and OpenShift where the top-level CR is used, mTLS enablement for management to gateway communication is not supported.

Management REST API CA certificate validation

The portal, gateway, and analytics subsystems make requests to the management subsystem through the REST API that is hosted by the management subsystem. This communication is standard TLS, where each REST API endpoint has a server certificate that is presented to the client during TLS handshaking. For extra security, validation of the management server certificate CA is enabled on all subsystems for new installations of API Connect v10.0.5.3 and later. If you are upgrading from an earlier release, the steps to enable this feature are

Certificates used to secure inter-subsystem communication

For information about the management of the certificates that are used in the TLS and mTLS communications between subsystems, see Key Concepts: Cert-manager, Issuers, and Secrets.