PYIC-5872: Expose core's internal API in dev

[Wynndow]

Proposed changes

What changed

Expose core's internal API to requets with an API key.

Why did it change

PYIC-5872: Expose internal API in dev

This change allows core's internal API to be accessed with an API key
when deployed to either of the dev accounts.

It adds a usage plan with API key to the internal API, and then makes
use of an API key required only for the dev accounts. It also adds DNS
to the API gateway to make use of the internal API easier.

Also, to allow programatic access to the API key, a new resource policy
is created to allow the OIDC identity provider enough permissions to
fetch the API key.

It removes the CoreFrontLocal parameter in favour of defaulting to
this behavour for dev accounts. This is because changing back to a
private API from the new regional version is a two step process - so not
as easy as just toggling the parameter.

It's a two step process as you can't change from regional to private if
it has custom domains associated with it. In CloudFormation there isn't
a way to specify that something should be removed before making changes,
resulting in having to remove the custom domain before changing the API
to private.

Ideally I would have liked to have conditionally created the UsagePlan -
only for the dev accounts. However there appears to be a bug in cfn-lint
that means we can't use an If function with the CreateUsagePlan
property.

The GHA workflow included in this PR is just to demonstrate that the
gateway is now available with an API key, and also how to
programatically access the API key. This would not be merged with the
PR.

PYIC-5872: Don't use SAM UsagePlan

SAM allows an easy way to create a usage plan and API key, by defining
the UsagePlan property in an Api resource. Unfortunately you can't
use an !If function with it do conditionally create it.

This removes the use of it and defines the resources requied using
plain old CloudFormation. This allows us to only create them when we
want.

Using the previous method would have caused a usage plan and api key to
be created in all envs including prod. This felt like murky ground - the
non dev api's would still be private so it wouldn't have been an issue,
but feels safer to only create them when actually needed.

PYIC-5872: Create separate API for internal testing

This creates a new API gateway to run in parallel with the original.
This means that the VPC protected internal API can still be used by
core-front without any changes, and the new regional, API token
protected API gateway can be used for testing.

cfn-lint has an issue with having an event defined in a lambda that
includes a reference to a conditionally created resource, even if that
resource is behind the same condition. This has lead to the ignore
written into the metadata of a number of resources.

Issue tracking

• PYIC-5872

[Joe-Edwards-GDS]

This seems better to me, what do you think?

It makes the prod configuration cleaner, and isn't much more code than before. The main thing that's annoying is configuring the extra events and overriding that cfn-lint rule :/

[Wynndow]

This seems better to me, what do you think?

It makes the prod configuration cleaner, and isn't much more code than before. The main thing that's annoying is configuring the extra events and overriding that cfn-lint rule :/

I think this is ok - at some point we're going to create a new lambda and forget to add the extra testing event on. We could write a macro to do that for us and not have to define the event at all....

[Joe-Edwards-GDS]

I'm happy to approve this, but I think we need to:

• Remove the test pipeline code
• Monitor this in build to make sure it doesn't cause any changes there

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud