Deployment considerations for connecting API Connect runtimes

An overview of how the location of federated API management deployment affects the way API Connect runtimes connect and authenticate with it.

How runtimes connect to federated API management depends on where the federated API management subsystem is deployed relative to your API Connect environments.

Many customers operate multiple API Connect stacks such as:

  • Development
  • Test
  • UAT or staging
  • Production

Each stack is a separate API Connect deployment.

Regardless of the number of API Connect stacks in the environment, only a single instance of federated API management is supported.

The customer must choose which API Connect stack hosts the subsystem.

Scenario 1 deployed in the same stack as API Connect (shared namespace)

If is deployed in the same Kubernetes/OpenShift cluster as the API Connect subsystems:

  • All communication between federated API management and the runtimes occurs over mutual TLS (mTLS).
  • Agents use the admin mTLS endpoint (fam-admin-endpoint) for secure communication.
  • This design enforces strong authentication and ensures secure intra-cluster communication.

Scenario 2 deployed in a different API Connect stack (different namespace or environment)

If federated API management is deployed in one API Connect stack and the runtimes are located in other API Connect stacks. For example:

  • Federated API management in production

  • API Connect runtimes in development or test

Then:

  • mTLS communication is still used across cluster.

  • Agents in remote clusters authenticate by using the same mTLS admin endpoint exposed by federated API management.

For details, see Establishing cross-cluster communication with Federated API Management.