Domain-Namen, Dashboard-Upgrades und grundlegende Web-Server-Konfiguration

Domain Namen

Viele Organisationen stellen in der Regel Webanwendungen in Subdomains einer übergreifenden Organisationsdomäne bereit. Es ist natürlich für Benutzer, eine Domain der Form ``openstack.example.org``zu erwarten. In diesem Zusammenhang gibt es häufig Anwendungen, die im selben Namespace der zweiten Ebene eingesetzt werden. Diese Namensstruktur ist bequem und vereinfacht die Wartung des Nameservers.

Wir empfehlen dringend, das Dashboard auf eine * Second-Level-Domain * zu installieren, z. B. https://example.com, anstatt das Dashboard auf einer * gemeinsamen Subdomain * auf jeder Ebene zu implementieren, z.B. `` https://openstack.example.org``oder https:// horizon.openstack.example.org. Wir raten auch beim Einsatz auf nackten internen Domains wie https://horizon/. Diese Empfehlungen basieren auf den Einschränkungen der Browser same-origin-policy.

Empfehlungen, die in diesem Leitfaden gegeben werden, können nicht wirksam gegen bekannte Angriffe schützen, wenn Sie das Dashboard in einer Domäne bereitstellen, die auch benutzergenerierte Inhalte hostet, auch wenn sich dieser Inhalt auf einer separaten Subdomain befindet. Benutzergenerierte Inhalte können aus Skripten, Abbildern oder Uploads jeglicher Art bestehen. Die meisten großen Web-Auftritte, einschließlich googleusercontent.com, fbcdn.com, github.io und twimg.co, verwenden Sie diesen Ansatz, um User-generated Content aus Cookies und Sicherheitstoken zu trennen.

Wenn Sie diese Empfehlung nicht auf Domains der zweiten Ebene befolgen, vermeiden Sie einen Cookie-unterstützten Session Store und verwenden HTTP Strict Transport Security (HSTS). Bei der Bereitstellung auf einer Subdomain entspricht die Sicherheit des Dashboards der am wenigsten sicheren Anwendung, die auf derselben Domäne der zweiten Ebene bereitgestellt wird.

Grundlegende Web-Server-Konfiguration

Das Dashboard sollte als Web Services Gateway Interface (WSGI) Anwendung hinter einem HTTPS Proxy wie Apache oder Nginx eingesetzt werden. Wenn Apache nicht bereits benutzt wird, empfehlen wir Nginx, da es leicht und einfacher richtig zu konfigurieren ist.

Bei Verwendung Nginx empfehlen wir gunicorn als WSGI-Host mit einer entsprechenden Anzahl von synchronen Workern. Bei der Verwendung von Apache empfehlen wir mod_wsgi, um das Dashboard zu hosten.

Allowed hosts

Konfigurieren Sie die ALLOWED_HOSTS-Einstellung mit dem vollqualifizierten Hostnamen, der vom OpenStack-Dashboard bedient wird. Sobald diese Einstellung zur Verfügung gestellt wird, wird der Fehler, wenn der Wert im Header Host:einer eingehenden HTTP-Anforderung nicht mit einem der Werte in dieser Liste übereinstimmt, ein Fehler erhoben und der Anforderer kann nicht fortfahren. Wenn Sie diese Option nicht konfigurieren oder die Verwendung von Platzhalterzeichen in den angegebenen Hostnamen verwenden, wird das Dashboard anfällig für Sicherheitsverletzungen

Weitere Informationen finden Sie in der Django Dokumentation.

Horizont Abbilder hochladen

Wir empfehlen, dass die Implementierer HORIZON_IMAGES_ALLOW_UPLOAD deaktivieren <https://docs.openstack.org/horizon/latest/user/manage-images.html#upload-an-image>`_ es sei denn, sie haben einen Plan zur Vermeidung von Ressource Erschöpfung und Denial-of-Service umgesetzt.