-
Notifications
You must be signed in to change notification settings - Fork 160
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
Conversation
Co-authored-by: Stuart Leeks <stuart@leeks.net>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple of questions:
- 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?
- How do renewals work?
I like the idea of a lets encrypt shared service to handle requesting and renewing certs.
I've created a story to track management of the letsencrypt certs #1540 |
lifecycle { ignore_changes = [tags] } | ||
} | ||
|
||
resource "azurerm_application_gateway" "agw" { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
FYI - this PR is moved to draft and @jjgriff93 will incorporate into the PR that consumes these changes |
Closing as addressed in #1584 |
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
nexus-<tre_id>
make
commandnexus-cert-install
deploys required azure resourcesnexus-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: