Merge "[arch-design] Consolidating security content"

doc/arch-design-draft/source/security-requirements.rst

@@ -2,8 +2,168 @@
 Security requirements
 =====================
 
-.. toctree::
-   :maxdepth: 2
+When deploying OpenStack in an enterprise as a private cloud, it is
+usually behind the firewall and within the trusted network alongside
+existing systems. Users are employees that are bound by the
+company security requirements. This tends to drive most of the security
+domains towards a more trusted model. However, when deploying OpenStack
+in a public facing role, no assumptions can be made and the attack vectors
+significantly increase.
 
+Consider the following security implications and requirements:
 
+* Managing the users for both public and private clouds. The Identity service
+  allows for LDAP to be part of the authentication process. This may ease user
+  management if integrating into existing systems.
 
+* User authentication requests include sensitive information including
+  usernames, passwords, and authentication tokens. It is strongly recommended
+  to place API services behind hardware that performs SSL termination.
+
+* Negative or hostile users who would attack or compromise the security
+  of your deployment regardless of firewalls or security agreements.
+
+* Attack vectors increase further in a public facing OpenStack deployment.
+  For example, the API endpoints and the software behind it become
+  vulnerable to hostile entities attempting to gain unauthorized access
+  or prevent access to services. You should provide appropriate filtering and
+  periodic security auditing.
+
+.. warning::
+
+   Be mindful of consistency when utilizing third party
+   clouds to explore authentication options.
+
+For more information OpenStack Security, see the `OpenStack Security
+Guide <http://docs.openstack.org/security-guide/>`_.
+
+Security domains
+~~~~~~~~~~~~~~~~
+
+A security domain comprises of users, applications, servers or networks
+that share common trust requirements and expectations within a system.
+Typically they have the same authentication and authorization
+requirements and users.
+
+Security domains include:
+
+Public security domains
+ The public security domain can refer to the internet as a whole or
+ networks over which you have no authority. This domain is considered
+ untrusted. For example, in a hybrid cloud deployment, any information
+ traversing between and beyond the clouds is in the public domain and
+ untrustworthy.
+
+Guest security domains
+ The guest security domain handles compute data generated by instances
+ on the cloud, but not services that support the operation of the
+ cloud, such as API calls. Public cloud providers and private cloud
+ providers who do not have stringent controls on instance use or who
+ allow unrestricted internet access to instances should consider this
+ domain to be untrusted. Private cloud providers may want to consider
+ this network as internal and therefore trusted only if they have
+ controls in place to assert that they trust instances and all their
+ tenants.
+
+Management security domains
+ The management security domain is where services interact. Sometimes
+ referred to as the control plane, the networks in this domain
+ transport confidential data such as configuration parameters, user
+ names, and passwords. In most deployments this domain is considered
+ trusted when it is behind an organization's firewall.
+
+Data security domains
+ The data security domain is primarily concerned with information
+ pertaining to the storage services within OpenStack. The data
+ that crosses this network has high integrity and confidentiality
+ requirements and, depending on the type of deployment, may also have
+ strong availability requirements. The trust level of this network is
+ heavily dependent on other deployment decisions.
+
+These security domains can be individually or collectively mapped to an
+OpenStack deployment. The cloud operator should be aware of the appropriate
+security concerns. Security domains should be mapped out against your specific
+OpenStack deployment topology. The domains and their trust requirements depend
+upon whether the cloud instance is public, private, or hybrid.
+
+Hypervisor security
+~~~~~~~~~~~~~~~~~~~
+
+The hypervisor also requires a security assessment. In a
+public cloud, organizations typically do not have control
+over the choice of hypervisor. Properly securing your
+hypervisor is important. Attacks made upon the
+unsecured hypervisor are called a **hypervisor breakout**.
+Hypervisor breakout describes the event of a
+compromised or malicious instance breaking out of the resource
+controls of the hypervisor and gaining access to the bare
+metal operating system and hardware resources.
+
+Hypervisor security is not an issue if the security of instances is not
+important. However, enterprises can minimize vulnerability by avoiding
+hardware sharing with others in a public cloud.
+
+Baremetal security
+~~~~~~~~~~~~~~~~~~
+
+There are other services worth considering that provide a
+bare metal instance instead of a cloud. In other cases, it is
+possible to replicate a second private cloud by integrating
+with a private Cloud-as-a-Service deployment. The
+organization does not buy the hardware, but also does not share
+with other tenants. It is also possible to use a provider that
+hosts a bare-metal public cloud instance for which the
+hardware is dedicated only to one customer, or a provider that
+offers private Cloud-as-a-Service.
+
+.. important::
+
+   Each cloud implements services differently. Understand the security
+   requirements of every cloud that handles the organization's data or
+   workloads.
+
+Networking security
+~~~~~~~~~~~~~~~~~~~
+
+Consider security implications and requirements before designing the
+physical and logical network topologies. Make sure that the networks are
+properly segregated and traffic flows are going to the correct
+destinations without crossing through locations that are undesirable.
+Consider the following factors:
+
+* Firewalls
+* Overlay interconnects for joining separated tenant networks
+* Routing through or avoiding specific networks
+
+How networks attach to hypervisors can expose security
+vulnerabilities. To mitigate hypervisor breakouts, separate networks
+from other systems and schedule instances for the
+network onto dedicated Compute nodes. This prevents attackers
+from having access to the networks from a compromised instance.
+
+Multi-site security
+~~~~~~~~~~~~~~~~~~~
+
+Securing a multi-site OpenStack installation brings
+several challenges. Tenants may expect a tenant-created network
+to be secure. In a multi-site installation the use of a
+non-private connection between sites may be required. This may
+mean that traffic would be visible to third parties and, in
+cases where an application requires security, this issue
+requires mitigation. In these instances, install a VPN or
+encrypted connection between sites to conceal sensitive traffic.
+
+Identity is another security consideration. Authentication
+centralization provides a single authentication point for
+users across the deployment, and a single administration point
+for traditional create, read, update, and delete operations.
+Centralized authentication is also useful for auditing purposes because
+all authentication tokens originate from the same source.
+
+Tenants in multi-site installations need isolation
+from each other. The main challenge is ensuring tenant networks
+function across regions which is not currently supported in OpenStack
+Networking (neutron). Therefore an external system may be required
+to manage mapping. Tenant networks may contain sensitive information requiring
+accurate and consistent mapping to ensure that a tenant in one site
+does not connect to a different tenant in another site.