This chapter discusses the legal and security requirements you need to consider for the different OpenStack scenarios.

Many jurisdictions have legislative and regulatory requirements governing the storage and management of data in cloud environments. Common areas of regulation include: Data retention policies ensuring storage of persistent data and records management to meet data archival requirements. Data ownership policies governing the possession and responsibility for data. Data sovereignty policies governing the storage of data in foreign countries or otherwise separate jurisdictions. Data compliance policies governing certain types of information needing to reside in certain locations due to regulatory issues - and more importantly, cannot reside in other locations for the same reason. Examples of such legal frameworks include the data protection framework of the European Union and the requirements of the Financial Industry Regulatory Authority in the United States. Consult a local regulatory body for more information.

When deploying OpenStack in an enterprise as a private cloud, despite activating a firewall and binding employees with security agreements, cloud architecture should not make assumptions about safety and protection. In addition to considering the users, operators, or administrators who will use the environment, consider also 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. This can result in loss of reputation and you must protect against it through auditing and appropriate filtering. It's important to understand that user authentication requests encase sensitive information such as user names, passwords, and authentication tokens. For this reason, place the API services behind hardware that performs SSL termination. Be mindful of consistency when utilizing third party clouds to explore authentication options.

A security domain comprises users, applications, servers or networks that share common trust requirements and expectations within a system. Typically, security domains have the same authentication and authorization requirements and users. You can map security domains individually to the installation, or combine them. For example, some deployment topologies combine both guest and data domains onto one physical network. In other cases these networks are physically separate. Map out the security domains against specific OpenStack topologies needs. The domains and their trust requirements depend on whether the cloud instance is public, private, or hybrid. The public security domain is an untrusted area of the cloud infrastructure. It can refer to the Internet as a whole or simply to networks over which the user has no authority. Always consider this domain untrusted. For example, in a hybrid cloud deployment, any information traversing between and beyond the clouds is in the public domain and untrustworthy. Typically used for compute instance-to-instance traffic, 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. The management security domain is where services interact. The networks in this domain transport confidential data such as configuration parameters, user names, and passwords. Trust this domain when it is behind an organization's firewall in deployments. The data security domain is concerned primarily with information pertaining to the storage services within OpenStack. The data that crosses this network has integrity and confidentiality requirements. Depending on the type of deployment there may also be availability requirements. The trust level of this network is heavily dependent on deployment decisions and does not have a default level of trust.

The hypervisor also requires a security assessment. In a public cloud, organizations typically do not have control over the choice of hypervisor. For example, Amazon uses its own particular version of Xen. 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. There is not an issue if the security of instances is not important. However, enterprises need to avoid vulnerability. The only way to do this is to avoid the situation where the instances are running on a public cloud. That does not mean that there is a need to own all of the infrastructure on which an OpenStack installation operates; it suggests avoiding situations in which sharing hardware with others occurs.

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. It is important to realize that each cloud implements services differently. What keeps data secure in one cloud may not do the same in another. Be sure to know the security requirements of every cloud that handles the organization's data or workloads. More information on OpenStack Security can be found in the OpenStack Security Guide.

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 example 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 against exploiting 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.

Securing a multi-site OpenStack installation brings extra 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. Another security consideration with regard to multi-site deployments is Identity. Centralize authentication within a multi-site deployment. Centralization provides a single authentication point for users across the deployment, as well as a single point of administration 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. Just as tenants in a single-site deployment need isolation from each other, so do tenants in multi-site installations. The extra challenges in multi-site designs revolve around ensuring that tenant networks function across regions. Unfortunately, OpenStack Networking does not presently support a mechanism to provide this functionality, therefore an external system may be necessary to manage these mappings. Tenant networks may contain sensitive information requiring that this mapping be accurate and consistent to ensure that a tenant in one site does not connect to a different tenant in another site.

Most OpenStack installations require a bare minimum set of pieces to function. These include OpenStack Identity (keystone) for authentication, OpenStack Compute (nova) for compute, OpenStack Image service (glance) for image storage, OpenStack Networking (neutron) for networking, and potentially an object store in the form of OpenStack Object Storage (swift). Bringing multi-site into play also demands extra components in order to coordinate between regions. Centralized Identity service is necessary to provide the single authentication point. Centralized dashboard is also recommended to provide a single login point and a mapped experience to the API and CLI options available. If needed, use a centralized Object Storage service, installing the required swift proxy service alongside the Object Storage service. It may also be helpful to install a few extra options in order to facilitate certain use cases. For instance, installing DNS service may assist in automatically generating DNS domains for each region with an automatically-populated zone full of resource records for each instance. This facilitates using DNS as a mechanism for determining which region would be selected for certain applications. Another useful tool for managing a multi-site installation is OpenStack Orchestration (heat). The Orchestration module allows the use of templates to define a set of instances to be launched together or for scaling existing sets. It can set up matching or differentiated groupings based on regions. For instance, if an application requires an equally balanced number of nodes across sites, the same heat template can be used to cover each site with small alterations to only the region name.