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
- Management initiated communication to portal, analytics, and gateway subsystems. From v10.0.5.3 and later.
- Analytics ingestion: The flow of API event records from the gateway to the analytics subsystem.
From v10.0.5.4 and later.Note: If the gateway is under a high transaction load and sending many API events to the analytics subsystem, the enablement of JWT might impact the performance of your analytics subsystem. It is recommended to run performance tests under your expected analytics load before you decide to use JWT for the analytics ingestion path.
For more information about this feature, see Enable JWT security instead of mTLS.
Use services instead of routes (OpenShift) or ingresses (Kubernetes)
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
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
.validateApimClient
.Management REST API CA certificate validation
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.