Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nexus Letsencrypt Certificate #1514

Closed
wants to merge 21 commits into from
Closed

Conversation

oliver7598
Copy link
Contributor

@oliver7598 oliver7598 commented Mar 15, 2022

PR for issue #1480

Related to #1089 and #1479

What is being addressed

Lets Encrypt certificate to be generated for nexus-<tre_id>.<location>.cloudapp.azure.com to allow use in newly hosted nexus service in a VM (#1479).

How is this addressed

  • Additional storage account created hosting a static site
  • Public IP created with domain nexus-<tre_id>
  • Application gateway used to route IP to static site.
  • Letsencrypt used to generate certificate based on above resources, triggered by a make command
  • New make command nexus-cert-install deploys required azure resources
  • New make command nexus-letsencrypt runs letsencrypt script and stored cert to base TRE keyvault (kv-<tre_id>)

Future Changes

The certificate produced from the changes in this PR need testing with #1479 to confirm whether it successfully addresses #1089.

Once this is confirmed to be working in its current state there may be a few possible optimizations:

  • Make the nexus-cert shared service more generic/parameterized so it can be used to create additional certificates for other components
  • Additional support for a wildcard cert if a custom domain is used
  • Letsencrypt extracted out of templates/core/terraform/scripts/ and out of the new nexus-cert shared service to reduce repeated code.

@github-actions github-actions bot added the external PR from an external contributor label Mar 15, 2022
oliver7598 and others added 6 commits March 17, 2022 12:59
Co-authored-by: Stuart Leeks <stuart@leeks.net>
Co-authored-by: Stuart Leeks <stuart@leeks.net>
Co-authored-by: Stuart Leeks <stuart@leeks.net>
Copy link
Member

@marrobi marrobi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple of questions:

  1. Looks like this deploys its own app gateway - is a cost associated with this - does it need its own app gw? Can the public IP be associated with the existing app gateway maybe?
  2. How do renewals work?

I like the idea of a lets encrypt shared service to handle requesting and renewing certs.

@daltskin
Copy link
Contributor

daltskin commented Mar 18, 2022

I've created a story to track management of the letsencrypt certs #1540

lifecycle { ignore_changes = [tags] }
}

resource "azurerm_application_gateway" "agw" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we creating a new AppGateway?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently, yes. But I imagine a single shared gateway may be adaquate. But I will test this fully on Monday as I ran out of time today.

I had designed it as a separate component for now specifically for letsencrypt but if integrated I`m happy to ammended.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ross-p-smith After a bit of digging I don't think we'd be able to amend the existing app gateway on deployment of this and a new one would be required. It wouldn't be needed outside of acquiring the certificate however so could be stopped/started when required which would avoid the additional cost?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have also tested the uses of a container instance although this is resolving to the wrong FQDN. The IP seems to be generated by the CI so ends in azurecontainer.io. This would maybe work if Nexus was also hosted in a CI although would then need to look at writing the auth hook to the container rather than a storage account blob.

@daltskin daltskin marked this pull request as draft March 23, 2022 13:09
@stuartleeks
Copy link
Contributor

FYI - this PR is moved to draft and @jjgriff93 will incorporate into the PR that consumes these changes

@jjgriff93
Copy link
Collaborator

Closing as addressed in #1584

@jjgriff93 jjgriff93 closed this Apr 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
external PR from an external contributor
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants