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.