Automatic API Gateway Route creation for Unity-Sips-Test deployments

[galenatjpl]

As a necessary prerequisite to getting https://github.com/unity-sds/unity-project-management/issues/71 done, we want to make sure some basic routing support is in place on the Unity-Test and Unity-Sips-Test accounts.

For this deployment, there will be two API Gateways:

1. Public Shared Services API Gateway in Unity-Test account
2. Public Account API Gateway (but only accessible from Shared Services) in the Unity-Sips-Test account

In the Unity-Sips-Test account, project deployments will occur (e.g. SPS deployments), and these SPS endpoints need to be automatically hooked up to the API Gateways.

The types of routes that need to be inserted are:

• Service-level-routes: routes between SPS endpoints (e.g. Mozart to Tosca), back through the shared-services API Gateway.
• Shared Services routes: route, for example that maps https://unity-sds.jpl.nasa.gov/sips/test to the private API Gateway.
  • NOTE: it's probably okay if this route is setup manually for the 23.2 release.
• Shared services routes from project account: for example, shared service API Gateway that SPS uses to access the Data Catalog or DAPA API (see also: https://github.com/unity-sds/unity-cs/issues/192). For these routes, @ramesh-maddegoda will most likely have to consult with @LucaCinquini or @drewm-jpl or @ryanhunter-jpl for further information.

Acceptance Criteria:

• [x] Prerequisite: Ticket about creating/destroying (independent of the Account API GW) SPS routes should be implemented
• [ ] Account API Gateway secured so that requests are only allowed from Shared Services API Gateway.
• [x] Account-level auth occurs at the Account level API Gateway via auth lambda
• [ ] Ensure that requests from service area components directly to other components in the private subnet aren't possible (security group would only allow from Account API Gateway to component)
• [x] Define the Shared Services API Gateway as a proxy with wildcard routes that delegate to fine-grained routes in the Account API Gateway

[LucaCinquini]

We should have a tag-up on this. If we are supporting multiple deployments in each venue, I would expect this kind of routing for the SIPS TEST venue and an EKS cluster named "fwd-processing":

WPS-T API endpoint: https://unity-sds.jpl.nasa.gov/sips/test/fwd-processing/wpst --> http://a0442fd7f829f49059fd68d1236aa263-650360946.us-west-2.elb.amazonaws.com:5001/

SPS API endpoint: https://unity-sds.jpl.nasa.gov/sips/test/fwd-processing/sps --> http://a7096fc6842e84da688b45586d194498-2116025617.us-west-2.elb.amazonaws.com:5002/

and similar for ADES specific endpoints if we want to support them, like the HySDS figaro and tosca.

[ramesh-maddegoda]

Evaluated the feasibility to pass traffic from Public API Gateway in Unity-Test account to a Private in the Unity-Sips-Test account. Usually this connectivity should be implemented as follows.

Public API -> VPC Link -> NLB -> Private API VPC Endpoint -> Private API

Related Posts/ Articles:

• How to get traffic from a public API Gateway to a private one?
• How to invoke a private API

However, this can introduce additional complexity and additional hops to the connectivity. Also, some of the approaches proposed in above links need the use of Amazon Route 53.

An alternative approach is to use public API gateways in API Gateway in Unity-Test account and also another public API Gateway in the Unity-Sips-Test account.Currently evaluating this approach.

Related References:

Controlling and managing access to a REST API in API Gateway

AWS API Gateway authentication - 6 ways to control access

Evaluating access control methods to secure Amazon API Gateway APIs

[galenatjpl]

Pushing this ticket to 23.3 release. We are partially blocked by MCP fully getting roles as code lambda integrated into their system. Also, the fully automatic API registration we decided isn't ready for 23.2.

[galenatjpl]

This work is all basically done, except for the remaining work pertaining to the locking down at the network level of the access to gateways/subnets/components, etc.. Will create a separate ticket for that work.