Migrate folio-iris domain to folio.colorado.edu

[steveellis]

@jwfuller is this the domain or is it something else. I can check on Route 53 also if you're not sure.

I believe the steps are: If I can have both a dev and a production stripes container in the same deployment then this kind of swap will be much easier to do next time.

[steveellis]

Going to try to migrate sandbox-folio.colorado.edu first since we have certificates etc loaded up for it already.

[steveellis]

The steps above aren't quite right. It's more like this:

• [x] Request certs from OIT for the new domain.
• [x] Upload the certs to the aws cert manager service. This will give the certs an ARN.
• [x] Bind the certs to the k8s services using the ARN. The process is documented in the readme for that. This is a pulumi change.
• [x] Request OIT to route DNS for the domains to the service endpoints that you get from k describe services.
• [x] Build stripes with the different okapi domain (if desired). This can be done last and probably needs to be done last since the new okapi domain won't work anyway.

Once all of this sticks it will "just work".

Need to think through my dual stripes container idea in this context.

[steveellis]

Steps for generating the CSR:

https://support.sectigo.com/PS_KnowledgeDetailPageFaq?Id=kA01N000000rgRb.

openssl req -nodes -newkey rsa:2048 -keyout myserver.key -out server.csr

Steps for generating the certificate from campus computing:

1. Visit the Comodo portal here: https://hard.cert-manager.com/customer/cuboulder/ssl
2. Enter for access code: <ask for this>
3. Use the contact email address (must be a colorado.edu or affiliate domain) for the cert as the login email account.
4. Click Check access code.
5. Enter the details for your system. Be sure to remember the password as you will need it to download the certificate after it is approved.
6. If your certificate is for a Microsoft Exchange Server or requires subject alternate names, make sure to select the Comodo Unified Communications Certificate as the certificate type, and to input your requested alternate names in the provided field.
7. Read the terms of the Subscriber Agreement and check the I agree checkbox.
8. Click Submit.

[steveellis]

Just noting the domains we're going for here for production:

folio.colorado.edu
okapi.colorado.edu

[steveellis]

With this ticket I also attempted to make it possible for a cluster to serve multiple domains to eventually make switching between domains easier and also make it possible to test out a cluster before mapping a given colorado.edu domain. I was partially successful. Having multiple stripes works great. Multiple okapis doesn't yet. The error is

 kubernetes:helm.sh/v3:Release (okapi-dev):
    error: rendered manifests contain a resource that already exists. Unable to continue with install: ConfigMap "okapi-log4j2-configmap" in namespace "[secret]-8rvomw1v" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "okapi-dev": current value is "okapi"

The okapi helm chart creates this this config map. If we're going to have multiple okapis this will need to be resolved, or perhaps we can use an outside loadbalancer to switch between these okapis. That's something we can't do with stripes because of the need for different container builds.

In the current configuration, where certs are bound directly to the EKS created LB, and it would appear that the classic load balancer (which I believe is what we have) won't support more than one cert. Reference: https://aws.amazon.com/premiumsupport/knowledge-center/acm-add-domain-certificates-elb/. If we had multiple certs we could easily point multiple domains to one okapi. ALBs support multiple which will make things easier when we get to that point. See #200 for more on that.