[Misc] private and public fhir-service API Gateway

[Zambonilli]

What's on your mind? We're looking to have traffic to fwoa routed internally from our ec2 instances. However, when trying to route the traffic internally, we were unable to because the fhir-service is currently public. Setting up a VPC Endpoint for API gateway blocks the public DNS for the fhir-service unless it's a custom DNS. Looking more closely at the documentation for setting up VPC endpoints for API Gateway, the diagrams depict creating both a public and a private API in API Gateway if you want to service both kinds of traffic.

Is this analysis correct or is there a better way to use the existing fhir-service and route internally? If the analysis is correct, is adding a private fhir-service something that we would want as part of fwoa? I can see a lot of implementations wanting both a private and public APIs here.

Versions (please complete the following information):

• v3.0.0

[rsmayda]

A private API GW is something of interest for some of our customers. Unfortunately we have not had a chance to dive deep into how or what it would look like. I will add this to our backlog! If you need a quicker answer we can rope in some SA specialists and pick their brains.

[Zambonilli]

Thanks, this is blocking us so we'll dive on it and get a PR going.

[Zambonilli]

FYI, we have a branch in our fork that is setting up a private API gateway here. https://github.com/Zambonilli/fhir-works-on-aws-deployment/tree/feature/private_api_gateway with most of the change in https://github.com/Zambonilli/fhir-works-on-aws-deployment/blob/feature/private_api_gateway/cloudformation/apiGateway.yaml

We were able to leverage the clone function in API Gateway to clone the public API and change the EndpointType to private. The Deployment and stages are not cloned so we were able to reference the serverless provider settings to match that of the public API. We have to still do a full audit of every field between public and private APIs and regression test our use of FHIR in our application when calling the private API but it looks pretty solid from the early results.

We'll open a PR once we've completed our audit and regression testing.

[Zambonilli]

Update for supporting a dynamic URL when using a private api gateway. We were seeing our HAPI FHIR client SDK throw exceptions on paging search requests because the TLD used in the response's link values was the public API gateway and not private API gateway. I added a configuration boolean called dynamicHostName to the config's server property. When this value is set to true, the setServerUrl middleware replaces hostname of the configured API_URL with the incoming request's hostname. When dynamicHostName is not set to true, the configured API_URL is used as the base serverUrl path like before. Similarly, the metadata endpoint now has the request's hostname passed to the handler and the dynamicHostName configuration value is checked to see if the implementation.url value needs to be updated to match the request's hostname.

There are changes here to the interface, routing and deployment modules to support private API gateways and all the PRs will need to be merged. The routing and deployment PRs will fail until the interface PR is merged and the package.json's updated in routing & deployment to point to the new interface version. In addition, the latest serverless version has removed support for user parameters on the deploy command and the resolution is to use environment variables (hence why I didn't follow the custom parameter convention in serverless.yaml).

interface PR: https://github.com/awslabs/fhir-works-on-aws-interface/pull/96 routing PR: https://github.com/awslabs/fhir-works-on-aws-routing/pull/153 deployment PR: https://github.com/awslabs/fhir-works-on-aws-deployment/pull/544

Testing: I have deployed fwoa with private API gateways enabled and disabled and have confirmed the following test cases.

1. Private API gateway metadata implementation.url uses the private API gateway's host name.
2. Public API gateway metadata implementation.url uses the public API gateway's host name.
3. Private API gateway search response's next, self and previous URLs use the private API gateway's host name.
4. Public API gateway search response's next, self and previous URLs use the public API gateway's host name.

The testing here is a bit tricky because you need to have a VPC and VPC endpoint to connect to the private API gateway and a runtime in that VPC's network context. I used a different account's VPC to confirm we are indeed traversing the internal AWS region's network and not just working because of some sort of shared networking/permissions in the same account. The easiest way to do this testing is by creating a vpc, vpc endpoint for api gateway and ec2 and then using ssm to ssh into the ec2 and fire curl commands. Here's the curl commands I used against my private API gateway after writing 20+ AuditEvents.

curl -v https://oi5uhwge88.execute-api.us-west-2.amazonaws.com/dev/metadata curl -v -H "Authorization: Bearer ${ACCESS_TOKEN}" -H "x-api-key: ${API_KEY}" https://oi5uhwge88.execute-api.us-west-2.amazonaws.com/dev/AuditEvent

Let me know if you have any questions or concerns about merging this PR and I'll be happy to help.

[carvantes]

Hi @Zambonilli ,

Thanks for submitting all the PRs. Looks like there are 2 things:

• Changes in interface/routing to allow dynamic hostnames.
• Changes in deployment to actually setup the private APIGW

At this moment we've decided to only merge the interface/routing changes. The deployment package serves as a starting point for customers and it showcases how to assemble all the different FWoA components. However, many customers end up modifying it heavily(or not using it at all) to fit their needs. We feel that the private APIGW is a bit too specific of a use case to be included on the default deployment setup(although that can change if more customers request that!)

We'll focus on reviewing the interface/routing changes that allow dynamic hostnames. We feel that this feature can be helpful in a wider range of use case.

[Zambonilli]

No worries and thanks for letting me know @carvantes. We have our private fork that we can manage anything that doesn't make sense in the public fwoa project like this private API gateway setup.

[Zambonilli]

Updated the following PRs per @carvantes feedback to only merge in the logic for optionally using dynamic hostnames.

interface PR: https://github.com/awslabs/fhir-works-on-aws-interface/pull/96 routing PR: https://github.com/awslabs/fhir-works-on-aws-routing/pull/153 deployment PR: https://github.com/awslabs/fhir-works-on-aws-deployment/pull/580

[nisankep]

FHIR Works on AWS has been moved to maintenance mode. While in maintenance, we will not add any new features to this solution. All security issues should be reported directly to AWS Security at [[email protected]] (mailto:[email protected]). If you are new to this solution, we advise you to explore using [HealthLake] (https://aws.amazon.com/healthlake), which is our managed service for building FHIR based transactional and analytics applications. You can get started by contacting your AWS Account team. If you are an existing customer of FHIR Works on AWS, and have additional questions or need immediate help, please reach out to [email protected] or contact your AWS Account team.