Closed basilv closed 1 year ago
@ArogeG I think this should be part of MVP but it is debatable.
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?
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).
This requires an iStore request
@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.
looks like the destination changes with different deployment, we need to identify ways to pin the destination to cognito or CloudFront.
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)
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.)
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).
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.
@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.
@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?
After discussion with Conrad our conclusions:
Actions to take:
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
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...
Created certificate request in AWS certificate manager for dev/test, sent required DNS configuration by email to Gbola and Michelle.
Checked here https://developer.gov.bc.ca/AWS-Services and I see AWS Certificate Manager (ACM) approved
Three issues:
@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.
Service Desk ticket has been created: https://apps.nrs.gov.bc.ca/int/jira/servicedesk/customer/portal/1/SD-56347
Service Desk ticket has been created: https://apps.nrs.gov.bc.ca/int/jira/servicedesk/customer/portal/1/SD-56347
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.
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.