Age | Commit message (Collapse) | Author | Files | Lines |
|
We need to make it configurable since these commands don't apply for
containerized environments. This way we can restart containers or
disable restarting and rely on other means.
This stems from the issue that some services get accidentally started by
certmonger on containerized environments, which makes the container
initialization fail.
bp tls-via-certmonger-containers
Change-Id: I62ff89362cfcc80e6e62fad09110918c36802813
|
|
This enables setting the subjectAltNames for HAProxy and httpd certs.
These will eventually replace the usage of many certs, to have instead
just one that has several subjectAltNames.
Change-Id: Icd152c8e0389b6a104381ba6ab4e0944e9828ba3
|
|
We used to rely on a standard directory for the certificates and keys
that are requested by certmonger. However, given the approach we plan to
take for containers that's described in the blueprint, we need to use
service-specific directories for the certs/keys, since we plan to
bind-mount these into the containers, and we don't want to bind mount
any keys/certs from other services.
Thus, we start by creating this directories if they don't exist in the
filesystem and adding the proper selinux labels.
bp tls-via-certmonger-containers
Change-Id: I0b71902358b754fa8bd7fdbb213479503c87aa46
|
|
This optionally enables TLS for keystone in the internal network.
If internal TLS is enabled, each node that is serving the keystone
service will use certmonger to request its certificate.
This, in turn should also configure a command that should be ran when
the certificate is refreshed (which requires the service to be
restarted).
bp tls-via-certmonger
Change-Id: I303f6cf47859284785c0cdc65284a7eb89a4e039
|