Re-expose APIs from another Apigee organization with PSC

[strebel]

In this Article we explain how you can re-expose an API that is exposed on a proxy in one Apigee X Organization via a proxy in another Apigee X organization. The requirement for this setup might be originating from a multitude of reasons including the separation of external and internal API gateways, strict network zoning or organizational fragmentation of infrastructure. Since we leverage PSC for connecting the two Apigee organizations, we remove any constraints imposed by network topologies and are able to connect two Apigee organizations that do not share any routable network path at the VPC level.

The high-level architecture is as follows: 

• Apigee A hosts a proxy that is pointing to an arbitrary backend service
• Apigee B should be able to consume the API exposed on Apigee A
• We use PSC to create a endpoint attachment in Apigee B for the automatically created service attachment in Apigee A

Implementation

To implement this, we first need to figure out the service attachment ID on Apigee A.

The service attachment ID can be found in the Apigee UI under Admin > Instances or alternatively via the Apigee API for listing instances.

The service attachments are regional and consist of the following format:

projects/xxxxx-tp/regions/europe-west1/serviceAttachments/apigee-europe-west1-abcd

Where:

• xxxxx-tp is the tenant project ID that hosts Apigee A’s runtime (note that this is a different to the project ID that you used when creating your Apigee Organization and will not be a project you have access to via the GCP console)
• europe-west1 is the region in which the instance is located
• apigee-europe-west1-abcd is the name of the automatically created service attachment

Take a note of these three parameters as they will be needed to configure the endpoint attachment on Apigee B. We will also have to come back to this service attachment once we figure out the tenant project ID of Apigee B because Apigee B’s tenant project needs to be allow-listed for accessing this service attachment of Apigee A.

On Apigee B we now create an endpoint attachment in Apigee B’s tenant project. In the Apigee UI under Admin > Endpoint Attachments we supply the three values we have gathered above:

If you click on next you will see the following hint:

Because the PSC service attachment in Apigee requires you to list all the consuming projects explicitly, we take the project ID we are given here and add it to the authorized projects on the service attachments on the Instance in Apigee A:

 

Back in Apigee B we can now create the service attachment and wait for it to become active. A successful Apigee endpoint attachment in Apigee B should look like this:

Where the IP address listed as “Host” is the IP that needs to be used as the target server in the Apigee proxy in Apigee B. 

The last point to remember is that the Apigee instance uses SNI to determine the correct environment group and ultimately the environment where the request should be sent. For testing purposes you could encode the host IP (in our example above this is 7.0.8.2) with a pseudo DNS service like nip.io. In our example a target configuration in Apigee B’s API proxy would then look like this:

<HTTPTargetConnection>
    <URL>https://7-0-8-2.nip.io</URL>
    <SSLInfo>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>true</IgnoreValidationErrors>
    </SSLInfo>
</HTTPTargetConnection>

Note that the ignore validation error property is required as the internal Apigee endpoint doesn’t serve a valid TLS certificate.

Instead of DNS encoding the endpoint attachment’s IP you can (and really should) use DNS peering functionality in Apigee as described in this blog post.

Regardless of the hostname you decided to use in your API proxy, you need to ensure you add it to the Apigee environment group that is associated with the environment that hosts your target API proxy in Apigee A.

Summary

We have created a connection between two Apigee organizations that do not share any connection at the VPC level and potentially even have overlapping IP ranges. By combining the Apigee features of northbound and southbound PSC we can call APIs exposed on one API gateway directly within another Apigee Proxy.

To learn more about the PSC capabilities of Apigee, please have a look at the PSC section in the Apigee documentation.