21e9b81f10
Removing extra space after fullstop in both security notes and security guide. Change-Id: I23edcd68b015aa454845a3b9db56106a69bb717a
3.2 KiB
Domain names, dashboard upgrades, and basic web server configuration
Domain names
Many organizations typically deploy web applications at subdomains of
an overarching organization domain. It is natural for users to expect a
domain of the form openstack.example.org. In this context,
there are often applications which are deployed in the same second-level
namespace. This name structure is convenient and simplifies name server
maintenance.
We strongly recommend deploying dashboard to a second-level
domain, such as https://example.com, rather than
deploying dashboard on a shared subdomain of any level, for
example https://openstack.example.org or
https://horizon.openstack.example.org. We also advise
against deploying to bare internal domains like
https://horizon/. These recommendations are based on the
limitations of browser same-origin-policy.
Recommendations given in this guide cannot effectively guard against known attacks if you deploy the dashboard in a domain that also hosts user-generated content, even when this content resides on a separate sub-domain. User-generated content can consist of scripts, images, or uploads of any type. Most major web presences, including googleusercontent.com, fbcdn.com, github.io, and twimg.co, use this approach to segregate user-generated content from cookies and security tokens.
If you do not follow this recommendation regarding second-level domains, avoid a cookie-backed session store and employ HTTP Strict Transport Security (HSTS). When deployed on a subdomain, the dashboard's security is equivalent to the least secure application deployed on the same second-level domain.
Basic web server configuration
The dashboard should be deployed as a Web Services Gateway Interface
(WSGI) application behind an HTTPS proxy such as Apache or Nginx. If Apache is not
already in use, we recommend Nginx since it is lightweight and easier to configure
correctly.
When using Nginx,
we recommend gunicorn as
the WSGI host with an appropriate number of synchronous workers. When
using Apache, we recommend mod_wsgi to host the
dashboard.
Allowed hosts
Configure the ALLOWED_HOSTS setting with the fully
qualified host name(s) that are served by the OpenStack dashboard. Once
this setting is provided, if the value in the "Host:" header of an
incoming HTTP request does not match any of the values in this list an
error will be raised and the requestor will not be able to proceed.
Failing to configure this option, or the use of wild card characters in
the specified host names, will cause the dashboard to be vulnerable to
security breaches associated with fake HTTP Host headers.
For further details, see the Django documentation.
Horizon image upload
We recommend that implementers disable HORIZON_IMAGES_ALLOW_UPLOAD unless they have implemented a plan to prevent resource exhaustion and denial of service.