Bug 1600011 - [RFE] Day 2 operations: manage let's encrypt certificate
Summary: [RFE] Day 2 operations: manage let's encrypt certificate
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: RHOS Maint
QA Contact: Omri Hochman
URL: https://blueprints.launchpad.net/trip...
Whiteboard:
Depends On:
Blocks: 1545371
TreeView+ depends on / blocked
 
Reported: 2018-07-11 08:25 UTC by Cédric Jeanneret
Modified: 2020-07-16 14:36 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-07-16 14:36:40 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Cédric Jeanneret 2018-07-11 08:25:23 UTC
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/

Comment 1 Jaromir Coufal 2019-06-14 16:00:47 UTC
This is Security focused feature


Note You need to log in before you can comment on or make changes to this bug.