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.
- Analytics ingestion: The flow of API event records from the gateway to the analytics
subsystem.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
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.