[ English | русский | Deutsch | 한국어 (대한민국) | English (United Kingdom) | Indonesia | español | français ]
Sichern von Diensten mit SSL-Zertifikaten¶
Das OpenStack Security Guide empfiehlt die sichere Kommunikation zwischen verschiedenen Diensten in einer OpenStack-Bereitstellung. Das OpenStack-Ansible-Projekt bietet derzeit die Möglichkeit, SSL-Zertifikate für die sichere Kommunikation zwischen Diensten zu konfigurieren:
All public endpoints reside behind haproxy, resulting in the only certificate management for externally visible https services are those for haproxy. Certain internal services such as RabbitMQ also require proper SSL configuration.
Bei der Bereitstellung mit OpenStack-Ansible können Sie entweder selbst signierte Zertifikate verwenden, die während des Bereitstellungsprozesses generiert werden, oder SSL-Zertifikate, Schlüssel und CA-Zertifikate von Ihrer eigenen vertrauenswürdigen Zertifizierungsstelle bereitstellen. In stark gesicherten Umgebungen werden vertrauenswürdige, vom Benutzer bereitgestellte Zertifikate für so viele Dienste wie möglich verwendet.
Bemerkung
Führen Sie die Konfiguration des SSL-Zertifikats in der Datei `` / etc / openstack_deploy / user_variables.yml`` durch. Bearbeiten Sie die Playbooks oder Rollen nicht selbst.
Openstack-Ansible uses an ansible role ansible_role_pki as a general tool to manage and install self-signed and user provided certificates.
Selbstsignierte Zertifikate¶
Self-signed certificates enable you to start quickly and encrypt data in transit. However, they do not provide a high level of trust for public endpoints in highly secure environments. By default, self-signed certificates are used in OpenStack-Ansible. When self-signed certificates are used, certificate verification is automatically disabled.
Self-signed certificates can play an important role in securing internal services within the Openstack-Ansible deployment, as they can only be issued by the private CA associated with the deployment. Using mutual TLS between backend services such as RabbitMQ and MariaDB with self-signed certificates and a robust CA setup can ensure that only correctly authenticated clients can connect to these internal services.
Generating and regenerating self-signed certificate authorities¶
A self-signed certificate authority is generated on the deploy host during the first run of the playbook.
To regenerate the certificate authority you must set the
openstack_pki_regen_ca
variable to either the name of the root CA
or intermediate CA you wish or regenerate, or to true
to regenerate
all self-signed certificate authorities.
# openstack-ansible -e "openstack_pki_regen_ca=ExampleCorpIntermediate" certificate-authority.yml
Take particular care not to regenerate Root or Intermediate certificate authorities in a way that may invalidate existing server certificates in the deployment. It may be preferable to create new Intermediate CA certificates rather than regenerate existing ones in order to maintain existing chains of trust.
Generieren und Regenerieren von selbstsignierten Zertifikaten¶
Während der ersten Ausführung des Playbooks werden für jeden Dienst selbstsignierte Zertifikate generiert.
To generate a new self-signed certificate for a service, you must set
the <servicename>_pki_regen_cert
variable to true in one of the
following ways:
Um zu erzwingen, dass ein selbstsigniertes Zertifikat neu generiert wird, können Sie die Variable in der Befehlszeile an "openstack-ansible" übergeben:
# openstack-ansible -e "haproxy_pki_regen_cert=true" haproxy-install.yml
To force a self-signed certificate to regenerate with every playbook run, set the appropriate regeneration option to
true
. For example, if you have already run thehaproxy
playbook, but you want to regenerate the self-signed certificate, set thehaproxy_pki_regen_cert
variable totrue
in the/etc/openstack_deploy/user_variables.yml
file:haproxy_pki_regen_cert: true
Vom Benutzer bereitgestellte Zertifikate¶
Für zusätzliches Vertrauen in hochsichere Umgebungen können Sie Ihre eigenen SSL-Zertifikate, Schlüssel und CA-Zertifikate bereitstellen. Das Abrufen von Zertifikaten von einer vertrauenswürdigen Zertifizierungsstelle liegt außerhalb des Geltungsbereichs dieses Dokuments. Im Abschnitt Certificate Management des Linux-Dokumentationsprojekts wird jedoch erläutert, wie Sie Ihre eigene Zertifizierungsstelle erstellen und Zertifikate signieren.
Verwenden Sie den folgenden Prozess, um von Benutzern bereitgestellte SSL-Zertifikate in OpenStack-Ansible bereitzustellen:
Kopieren Sie Ihre SSL-Zertifikat-, Schlüssel- und CA-Zertifikatdateien auf den Bereitstellungshost.
Geben Sie den Pfad zu Ihrem SSL-Zertifikat, Schlüssel und CA-Zertifikat in der Datei `` / etc / openstack_deploy / user_variables.yml`` an.
Führen Sie das Playbook für diesen Dienst aus.
Beispiel für HAProxy¶
Die zu setzenden Variablen, die den Zertifikaten für die HAProxy-Konfiguration den Pfad auf dem Implementierungsknoten bereitstellen, sind:
haproxy_user_ssl_cert: /etc/openstack_deploy/ssl/example.com.crt
haproxy_user_ssl_key: /etc/openstack_deploy/ssl/example.com.key
haproxy_user_ssl_ca_cert: /etc/openstack_deploy/ssl/ExampleCA.crt
RabbitMQ Beispiel¶
Um von Benutzern bereitgestellte Zertifikate für RabbitMQ bereitzustellen, kopieren Sie die Zertifikate auf den Implementierungshost, bearbeiten Sie die Datei `` / etc / openstack_deploy / user_variables.yml`` und legen Sie die folgenden drei Variablen fest:
rabbitmq_user_ssl_cert: /etc/openstack_deploy/ssl/example.com.crt
rabbitmq_user_ssl_key: /etc/openstack_deploy/ssl/example.com.key
rabbitmq_user_ssl_ca_cert: /etc/openstack_deploy/ssl/ExampleCA.crt
Führen Sie dann das Playbook aus, um die Zertifikate anzuwenden:
# openstack-ansible rabbitmq-install.yml
Das Playbook stellt das von Ihnen bereitgestellte SSL-Zertifikat, den Schlüssel und das CA-Zertifikat für jeden RabbitMQ-Container bereit.
Der Prozess ist für die anderen Dienste identisch. Ersetzen Sie rabbitmq in den vorhergehenden Konfigurationsvariablen durch` horizon`, haproxy oder` keystone`. Führen Sie dann das Playbook für diesen Dienst aus, um von Benutzern bereitgestellte Zertifikate für diese Dienste bereitzustellen.
LetsEncrypt certificates¶
The HAProxy ansible role supports using LetsEncrypt to automatically deploy trusted SSL certificates for the public endpoint. Each HAProxy server will individually request a LetsEncrypt certificate.
The http-01 type challenge is used by certbot to deploy certificates so it is required that the public endpoint is accessible directly on the internet.
Deployment of certificates using LetsEncrypt has been validated for openstack-ansible using Ubuntu Bionic. Other distributions should work but are not tested.
To deploy certificates with LetsEncrypt, add the following to
/etc/openstack_deploy/user_variables.yml
to enable the
letsencrypt function in the haproxy ansible role, and to
create a new backend service called letsencrypt
to service
http-01 challenge requests.
haproxy_ssl: true
haproxy_ssl_letsencrypt_enable: True
haproxy_ssl_letsencrypt_install_method: "distro"
haproxy_ssl_letsencrypt_email: "email.address@example.com"
If you don’t have horizon deployed, you will need to define dummy service that will listen on 80 and 443 ports and will be used for acme-challenge, whose backend is certbot on the haproxy host:
haproxy_extra_services:
# the external facing service which serves the apache test site, with a acl for LE requests
- service:
haproxy_service_name: certbot
haproxy_redirect_http_port: 80 #redirect port 80 to port ssl
haproxy_redirect_scheme: "https if !{ ssl_fc } !{ path_beg /.well-known/acme-challenge/ }" #redirect all non-ssl traffic to ssl except acme-challenge
haproxy_port: 443
haproxy_frontend_acls: "{{ haproxy_ssl_letsencrypt_acl }}" #use a frontend ACL specify the backend to use for acme-challenge
haproxy_ssl: True
haproxy_backend_nodes: #apache is running on locally on 127.0.0.1:80 serving a dummy site
- name: local-test-service
ip_addr: 127.0.0.1
haproxy_balance_type: http
haproxy_backend_port: 80
haproxy_backend_options:
- "httpchk HEAD /" # request to use for health check for the example service