Use Case 1: Organization-Owned API Exposed to an Organization-Owned API Consumer
Use case one covers all patterns of a scenario in which a trusted organization’s API is exposed to a trusted organization’s API consumer.
Pattern 1: Organization Internal API Exposed to an Organization Internal Consumer
Pattern examples:
-
A sales application accesses a customer service API in which both sales and customer service are internal areas of the customer organization
-
A call center application calls the API exposed by the customer domain to retrieve customer information
-
A mobile bank calls customer and account services to display the account overview screen to the end consumer
Pattern 1A: Organization Internal API Exposed to an Organization Internal Consumer that Uses the Same VPC or Network
In this use case pattern, both services are available on the same infrastructure, such as the same public cloud VPC, datacenter, or Kubernetes cluster. You can deploy Flex Gateway as either a sidecar or a standalone gateway.
The following diagram shows the physical implementation of a standalone Flex Gateway running in Connected Mode. A network policy (Netpol) permits ingress access only from Flex Gateway. You can configure the consumer application in the same or different namespace from Flex Gateway and the provider services.
When the API provider is located in a different Kubernetes cluster from Flex Gateway and the consumer application, you can do either of the following:
-
Deploy a Flex Gateway runtime on each of the clusters, as in Pattern 1B.
-
Establish network restrictions in the secure channel between clusters and deploy Flex Gateway in only one of them, as shown in the following diagram. The second cluster only allows connections from a Flex Gateway that acts as an ingress controller.
Pattern 1B: Organization Internal API Exposed to an Organization Internal Consumer that Uses a Different VPC or Network
In this pattern, the API provider is isolated from the API consumer. However, there is a secure communication channel available between the two networks.
You deploy Flex Gateway as an ingress behind a firewall because traffic is considered external to the location of the provider. Flex Gateway receives and processes the incoming traffic.
You can use Flex Gateway to terminate the TLS or mTLS connection if required.
The following diagram shows the physical implementation on Kubernetes.
Pattern 2: Organization Internal API exposed an Organization External Consumer
In pattern two, the organization-owned API is isolated from the organization-owned API consumer, for example, in a package delivery tracking API that is accessed from a user interface. The consumer can access the exposed API only via the internet. In this use case, you deploy Flex Gateway as an ingress.
This pattern is similar to Pattern 1B. However, in this pattern, traffic arrives from the public internet instead of from a private channel. Because traffic is coming from the public internet, you must add additional controls to strengthen communication security before reaching Flex Gateway.
The following diagram shows the physical implementation of a scenario in which an organization’s internal API is exposed to an organization’s internal consumer on Kubernetes. The diagram assumes that the firewall terminates the incoming external mTLS connection.
Pattern 3: Organization External API Exposed to an Organization Internal Consumer
In pattern three, the API Consumer is in the same network as Flex Gateway. You can use Flex Gateway to monitor, control, and enrich the flows to external services. For example, Flex Gateway can provide rate limiting for the external access traffic, or metrics and analytics tracking for this external service connection.
Pattern examples:
-
A payments service must obtain exchange rates from an external service provider.
-
An internal API Consumer accesses the organization’s external ServiceNow instance (SaaS service).
For pattern three, you deploy Flex Gateway as a standalone gateway that acts as an egress container.
The following diagram shows the physical implementation of a scenario in which an organization’s external API is exposed to an organization’s internal consumer on Kubernetes. The diagram assumes that the firewall terminates the incoming external mTLS connection.
Pattern 4: Organization External API Exposed to an Organization External Consumer
In pattern four, Flex Gateway acts as an intermediary between two organizations' external entities, for example, when an organization’s WorkDay instance (SaaS service) accesses the organization’s ServiceNow instance (SaaS service). In this pattern, Flex Gateway runs as an ingress and egress that applies secured communication and policy enforcement.
The following diagram shows the physical implementation of a scenario in which an external organization’s API is exposed to an external organization’s consumer on Kubernetes. The diagram assumes that the firewall terminates the incoming organization’s external mTLS connection.
