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

Security requirements

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.

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.