API Gateway federation with gravitee.io and AWS gateway

In version 4.4 gravitee.io introduced the new Federation feature that allows you to manage your API’s in gravitee.io while having the runtime on a 3rd party gateway. This means that some API’s are for example running in AWS, others in Apigee, but their swaggers and urls are visible for the developers in the gravitee.io portal, together with the documentation that can be managed in gravitee.io (for example by linking it to Github Seamlessly Integrate Gravitee API Documentation with GitHub – i8c). From that portal the developers can also request access and subscribe to the API’s they want to use. These subscriptions are then synced with the 3rd party gateway.

In this blog, I’ll demonstrate just how easy it was to create a local demo where I’ve set up federation in gravitee.io. For a more business perspective on why you might want to use API federation, I refer you to the blog written by Gravitee.

To enable Federation in Gravitee, you need to set up an agent that manages all interactions between the gravitee.io platform and a third-party gateway. As of this writing, the following third-party gateways are supported: AWS API Gateway, Azure APIM, Apigee, IBM API Connect, Solace and Confluent Platform. In this blog, I’ll focus on the AWS Gateway agent, but the setup process for other providers follows the same principles: you set up an agent that contains all configuration and specific properties for the 3rd party gateway and you connect that agent to the gravitee.io platform.

For this demo I wanted to set up Federation from my local gravitee installation, running in docker compose, to our AWS API Management environment. Obviously this is not a production fit-environment, but it is perfect to try things out and showcase the capabilities of API Federation on Gravitee.io.

Prepare management server

Enable Federation

Since Federation is not enabled by default, you need to enable this explicitly. To do this with a docker-compose installation, all you have to do is add this environment variable to your yaml file.

In your docker-compose file it looks like this:

Expose port 8072

Since we are working with a local docker setup, the agent will connect to a local port 8072 of your Management API server. This port needs to be added to the management_api docker config so that it can be called from the agent.

Prepare users and access

gravitee.io

• Create a service account for the agent on organisation level

• Assign it the FEDERATION_AGENT role

• Create a personal token for this service account. You need this auth token for the configuration of your agent in later steps, so save it to a local file.

AWS Gateway

To allow your agent to access AWS Gateway you need a user that has access to the API’s, the usage plans and the keys. The full list of required access rights can be found here: https://documentation.gravitee.io/apim/using-the-product/federating-your-apis/3rd-party-providers/aws-api-gateway#minimum-aws-permissions-required-by-the-agent

You will need the access key id and a secret of the user for your agent configuration.

Creating the agent

In the API Manager UI, go to the ‘Integrations’ page and click the button ‘Create Integration’. Select the integration of your choice and fill in a name and description. Once created the following page will be displayed:

• Copy the Integration ID for the configuration of the agent.

• Next go to the ‘Agent’ tab and find the docker compose config for the agent. You can either copy this in a new docker-compose.yaml file or add it to the existing docker file if your other gravitee.io components are also running in docker compose. Just make sure that the docker container can reach your API Management container on port 8072 and AWS.

• Fill in the blanks of the template, following values need to be filled in:

  • WS_ENDPOINTS: The endpoint on your gravitee.io server, typically suffixed with /integration-controller For a local docker install such as our POC, this url is slightly different; it becomes: http://localhost:8072

  • WS_AUTH_TOKEN: The auth token for the Gravitee user created above

  • AWS_ACCESS_KEY_ID: The AWS user access key id.

  • AWS_REGION: The region of you AWS APIM.

  • AWS_SECRET_ACCESS_KEY: The AWS user secret access key.

  • INTEGRATION_ID: The integration_id that you collected above when setting up the AWS Gateway Agent.

• Add the user that you created before and which you will use for the agent in the AWS Gateway Agent configuration and make it owner.

The agent is running in a separate container. Since I am running my environment in docker compose I will just add the config to my existing docker-compose.yaml and make sure it is in the correct network so that it can reach the api-management-api container.

Demo

Now that both my agent and Gravitee have been configured correctly, we can test out if the Gateway federation works. After restarting my docker-compose setup, I have now a separate AWS Agent container running, next to my Gravitee containers:

With the agent active, it should also have a connection to the AWS cluster now and that should be visible on the ‘Integrations’ page of the Gravitee Manager UI

To import the API’s on AWS, you can use the Discover functionality. The API’s that will be discovered depend on the (optional) filters in the docker config of your agent. For my demo I filtered on the ‘GraviteeHCTest’ stage that I created in AWS.

If you can’t find a specific API that you know exists in AWS, it is possible that it does not show because the API has no plan assigned to it in AWS (something likely to happen in a test/demo environment).

After creation of the Federated APIs you will find them on the APIs page:

As you can see, not only the definition is imported, but also the plans linked to the API are imported:

Once the API is published, it becomes visible in the Portal. As expected, the gateway is still AWS, so the url here will also point to our AWS endpoint.

For the last part of this demo we will subscribe, as a user, to the HealthCheck API from our Gravitee.io Portal. Once the subscription is validated by an admin, the API Key for this new subscription to the plan will also show up and be active in AWS.