Sicherheitseinstellungen¶

Dieses Kapitel enthält Informationen zum Konfigurieren bestimmter Sicherheitseinstellungen für Ihre OpenStack-Ansible-Cloud.

Zum Verständnis des Sicherheitsdesigns siehe Sicherheit.

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 the haproxy playbook, but you want to regenerate the self-signed certificate, set the haproxy_pki_regen_cert variable to true 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

Aufhärtbar auftragen¶

Die ansible-hardening -Rolle gilt für physische Hosts innerhalb einer OpenStack-Ansible-Bereitstellung, die als ein beliebiger Typ von Knoten, Infrastruktur oder Computer ausgeführt werden. Standardmäßig ist die Rolle aktiviert. Sie können es deaktivieren, indem Sie den Wert der Variablen `` apply_security_hardening`` in der `` user_variables.yml`` Datei auf `` false`` setzen:

apply_security_hardening: false

Sie können Konfigurationen zur Sicherheitssicherung auf eine vorhandene Umgebung anwenden oder eine Umgebung mithilfe eines mit OpenStack-Ansible gelieferten Playbooks überwachen:

# Apply security hardening configurations
  openstack-ansible security-hardening.yml

# Perform a quick audit by using Ansible's check mode
  openstack-ansible --check security-hardening.yml

Weitere Informationen zu den Sicherheitskonfigurationen finden Sie in der Dokumentation security hardening role.

Sicherheitseinstellungen

Sicherheitseinstellungen¶

Sichern von Diensten mit SSL-Zertifikaten¶

Selbstsignierte Zertifikate¶

Generating and regenerating self-signed certificate authorities¶

Generieren und Regenerieren von selbstsignierten Zertifikaten¶

Vom Benutzer bereitgestellte Zertifikate¶

Beispiel für HAProxy¶

RabbitMQ Beispiel¶

LetsEncrypt certificates¶

Aufhärtbar auftragen¶

openstack-ansible 23.4.5.dev2

Page Contents