Vanity URL for FAM Front-end and APIs

[basilv]

Instead of using an AWS generated URL for the FAM API gateway, set up a vanity URL - e.g. fam.nrs.gov.bc.ca. Consumers of FAM need a stable URL that never changes. Also likely need vanity URLs for Dev, test and Prod environments (fam-test.nrs.gov.bc.ca). Unclear how consumer apps will connect their test environments to FAM to secure them.

Connect with Rocket Chat community to confirm what is required for the URLs.

We will need the vanity URLs and destination/source URL for the front-end and APIs for Dev, Test, and PROD.

[basilv]

@ArogeG I think this should be part of MVP but it is debatable.

[ArogeG]

The conversation around this was that since we are not making the API publicly available, we could work on a vanity URL for the APIs post MVP @basilv Are there any major impacts to working on the vanity url post MVP?

[basilv]

Right, I remember now. I was thinking though that any apps (including FOM) should be using vanity URLs for talking to FAM (the Cognito component, not the APIs and API gateway).

[gormless87]

This requires an iStore request

[ArogeG]

@ConradBoydElliottGustafson looks like an iStore request might not be needed after all.
Michelle shared a link with me that documents how we can request for a vanity URL: https://apps.nrs.gov.bc.ca/int/confluence/display/1TEAM/AWS+Certificate+Manager+and+the+Kibana+Vanity+URL Michelle might also have access to Remedy for approval of the DNS. @ConradBoydElliottGustafson we can look at this together on Monday. Thanks.

[ArogeG]

looks like the destination changes with different deployment, we need to identify ways to pin the destination to cognito or CloudFront.

[basilv]

We have potentially 3 URLs needing vanity URLS: fam-frontend (pointing to cloudfront distribution holding static front-end) fam-cognito (pointing to by front-end and client applications I believe) fam-api (pointing to API gateway) - if this is only consumed by front-end and cognito then less important to have a vanity URL

One option is a single vanity URL with context path to route (e.g. fam-dev/ui, fam-dev/cognito), but this would require new infrastructure to do the routing. So we most likely want multiple URLS. E.g. fam-ui-dev fam-auth-dev (for cognito)

(All with a suffix of .nrs.gov.bc.ca)

[basilv]

Here's the AWS docs for using an alternate domain name for cloudfront: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html

The key step is to get the TLS certificate for the domain and register (add) it to the cloudfront distribution. However, the 2nd key step is to route traffic from our vanity URL to the cloudfront distribution domain name (d111111abcdef8.cloudfront.net type of format). So we are back to the problem of needing a stable cloudfront distribution domain name. (This isn't an issue for domains managed by AWS in Route 53, but we can't do that here.)

[ConradBoydElliottGustafson]

I think we can stabilize the cloudfront domain name and the api gateway domain names (the same way we did for the cognito domain name).

I don't think it's necessary to get Cognito working with a vanity URL. That sounds like a headache and won't achieve anything, since nobody "sees" those urls in their browser anyway (the redirects go by too fast).

[ConradBoydElliottGustafson]

It looks like we can control the domain name for the api gateway, but not cloudfront. We would have to keep our prod cloudfront alive and kicking as the cert would be registered to it I think. Not my area of expertise, but I think @basilv you are right that if we blow away prod and get a new cloudfront domain assigned, we would have to fix the CNAME entry in our DNS and potentially get a new cert as well.

Having said that, would we really be blowing away production once it's set up? I'm guessing changes would be incremental.

[basilv]

@ConradBoydElliottGustafson I was worrying about dev/test and having stable URLs for that, as I'm assuming vanity URLs for dev and test.

For the Cognito URL - don't consumer applications have to point to FAM Cognito from their front-end for getting the common login page? So we'd want them to use a stable vanity URL.

[ConradBoydElliottGustafson]

@basilv For the Cognito URL, it needs to be stable, but it doesn't need to be "vanity" IMHO. Users don't type it in or bookmark it or even see it as the redirects happen. The URL just needs to be configured in the client-side code. The cognito URL is currently stable, as the "domain" is something that we pass in with Terragrunt to each environment.

For the API Gateway, it's possible to configure a persistent domain and register CNAME and cert to point to it. We should write a ticket for that.

For Cloudfront, it appears that the cloudfront domain is created randomly each time and there is no way to pin it from changing when you recreate an environment. That's a huge pain because you would basically have to go change your CNAME values and regenerate your cert each time. It seems weird to me that it would be that hard. People must do this all the time?

[basilv]

After discussion with Conrad our conclusions:

1. We want vanity URLs for dev and test as well as prod
2. We want end users and consumer applications to use stable URLs.
3. Cognito (userpool) URL is stable currently. While it is not a vanity URL, it is only used by consumer applications not visible to end users so no vanity URL is required for Cognito
4. FAM front-end as cloudfront distribution is not a stable URL and no way to specify it via terraform/console to make it stable. And it is visible to FAM end users. So we will need a vanity URL for this. And we'll need to change terraform provisioning / environment teardown to never delete an existing cloudfront distribution. If the cloudfront distribution does ever get recreated, we'd have to update the DNS CNAME record. (There would be no impact to the certificate in this scenario.)

Actions to take:

1. Change terraform front-end provisioning to only update the distribution, not recreate it.
2. Change github action destroy environment to only destory the backend (API + database), leave front-end cloud distribution as-is.
3. Request vanity URL + certificate for development. Can be named fam-dev.nrs.gov.bc.ca.
4. Manually set up cloudfront distribution to use vanity URL supplying certificate
5. Change frontend terraform provisioning to automate step 4.

[basilv]

In response to Conrad's statement 'people must do this all the time' - yes for my other team but we're using a domain managed by AWS Route53 :). We should bring this up in the AWS meeting - request a feature to specify cloudfront distribution URL, and check with (complain to :) the cloud pathfinder team

[basilv]

Not discussed: what to do with the API gateway URL. Technically doesn't need to be a vanity URL (not visible to end users), and technically doesn't necessarily need to be stable as long as we update the front-end config (being worked on). Although for easier direct testing of API or direct reference to API locally there would be some benefit to having a stable URL. I'd say make this a lower priority item. Vanity URL could be fam-api-dev...

[basilv]

Created certificate request in AWS certificate manager for dev/test, sent required DNS configuration by email to Gbola and Michelle.

[webgismd]

Checked here https://developer.gov.bc.ca/AWS-Services and I see AWS Certificate Manager (ACM) approved

[basilv]

Three issues:

1. certificate request with DNS validation times out after 72 hours, have to request new certificate if it times out.
2. single certificate request with dev + test domains won't actually work because the separate AWS account for test most likely won't be able to see the certificate registered in the AWS dev account. So the solution is one certificate per AWS account.
3. integration with terraform automation. My plan is to manually create the certificate (per AWS account) and have the certificate ARN (id) as an input into terraform which will use it + the vanity URL to configure the cloudfront distribution.

[basilv]

@ArogeG Wording for the request: We are requesting the following vanity URL created named fam-dev.nrs.gov.bc.ca We also require the TLS certificate for this URL. We also need two additional DNS entries used for DNS validation by AWS certificate manager (ACM). Once the fam-dev domain is created and we receive the certificate, please contact us and we will obtain from AWS certificate manager the exact additional DNS entries required - there will be a 72 hour (3 day) window to have these entries created.

[ArogeG]

Service Desk ticket has been created: https://apps.nrs.gov.bc.ca/int/jira/servicedesk/customer/portal/1/SD-56347

[ArogeG]

Service Desk ticket has been created: https://apps.nrs.gov.bc.ca/int/jira/servicedesk/customer/portal/1/SD-56347

[webgismd]

I updated the ticket - Please note - for this to work correctly in AWS.. this cannot be a subdomain for NRS.GOV.BC.CA (it has to be its own Domain).

Page the describes the process that was used before is here – https://apps.nrs.gov.bc.ca/int/confluence/display/1TEAM/AWS+Certificate+Manager+and+the+Kibana+Vanity+URL

note: the TLS Certificate isn't created by Tier 3, but by the AWS Certificate Manager.