Bug 1600011
| Summary: | [RFE] Day 2 operations: manage let's encrypt certificate | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Cédric Jeanneret <cjeanner> |
| Component: | rhosp-director | Assignee: | RHOS Maint <rhos-maint> |
| Status: | CLOSED WONTFIX | QA Contact: | Omri Hochman <ohochman> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | unspecified | CC: | dbecker, emacchi, hrybacki, josorior, mburns, morazi, ohochman |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | https://blueprints.launchpad.net/tripleo/+spec/day-2-lets-encrypt-support | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-07-16 14:36:40 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1545371 | ||
This is Security focused feature |
Hello, Currently, there isn't any "nice" way to manage let's encrypt certificate due to the following reasons: HA: Let's Encrypt CLI doesn't support clustered web servers when using webroot module HA: Let's Encrypt CLI doesn't really support propagating new certificate to other servers Containers: Let's Encrypt CLI might have some issue with the containerized environment In order to circumvent these issue, I'd propose the following thing: add a new task (letsencrypt.yaml) find a way to detect where the VIP is actually attached ("master" node) ensure we actually have horizon vhost "/var/www" available on the host directly (container volume, see this merged¹ change for more information) run Let's Encrypt CLI on that node fetch the certificate push the certificate on the other controllers A way to get the "master" node would be to just create an inventory with two "groups", one containing only the public CloudName (i.e. cloud.domain.tld), the second one having the three controllers (either by IP or by name). A first check would be to get the FQDN of the controller having the IP, and filtering out the actions with some kind of "ansible_fqdn == master_node" and the like. Would that feature be interesting in this project? Of course, being able to automate the LE renewal is the best thing - and maybe we might do that using this ansible role, a dedicated playbook and a cronjob. We might use this ansible module (preview, available in 2.5 at least) in order to avoid having to activate EPEL repository for acme libraries: https://docs.ansible.com/ansible/latest/modules/letsencrypt_module.html The really nice part of this module is: we can handle as WE want the challenge, meaning we're pretty free to do whatever we want. Some additional nodes: In an HA environment, the haproxy will need to deactivate all horizon backends but the one we're connected to. This can be done using the haproxy socket, provided we have an "admin" level to it. For now, the socket might not be accessible from the host, so we might need to run docker exec commands - as there is a "|" in them, it might be a bit tricky. If you agree, I can try to do that new task and its dependencies - that would be a nice exercise for me :). Cheers, C. ¹ https://review.openstack.org/#/c/565753/