Age | Commit message (Collapse) | Author | Files | Lines |
|
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: Iba3adb9464a755e67c6f87d1233b3affa8be565a
|
|
This sets up the CRL file to be triggered on the certmonger_user
resource. Furtherly, HAProxy uses this CRL file in the member options,
thus effectively enabling revocation for proxied nodes.
So, if a certificate has been revoked by the CA, HAProxy will not proxy
requests to it.
bp tls-via-certmonger
Change-Id: I4f1edc551488aa5bf6033442c4fa1fb0d3f735cd
|
|
bp tls-via-certmonger
Change-Id: I85dda29bcad686372a74bd7f094bfd62777a3032
|
|
|
|
bp secure-etcd
Change-Id: I0759deef7cbcf13b9056350e92f01afd33e9c649
Signed-off-by: Feng Pan <fpan@redhat.com>
|
|
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 merely requests the certificates that will be used for libvirt's
live migration if TLS-everywhere is enabled.
bp tls-via-certmonger
Change-Id: If18206d89460f6660a81aabc4ff8b97f1f99bba7
|
|
This profile will specifically be used to create all the certificates
required in the node. These are fetched from hiera and will be ran in
the first step of the overcloud deployment and in the undercloud.
The reasoning for this is that, with services moving to containers, we
can't yet do these requests for certificates within the containers for
the specific services. this is because the containers won't have
credentials to the CA, while the baremetal node does. So instead we
still do this on the baremetal node, and will subsequently bind mount
the certificates to the containers that need them. Also, this gives us
flexibility since this approach still works for the baremetal case.
There will be a subsequent commit removing the certificate requests from
the service-specific profiles.
Change-Id: I4d2e62b5c1b893551f9478cf5f69173c334ac81f
|