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:
Be mindful of consistency when utilizing third party clouds to explore authentication options.
For more information OpenStack Security, see the OpenStack Security Guide.
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:
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.
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.
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.
Each cloud implements services differently. Understand the security requirements of every cloud that handles the organization’s data or workloads.
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:
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.
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.
Using remote resources for collection, processing, storage, and retrieval provides potential benefits to businesses. With the rapid growth of data within organizations, businesses need to be proactive about their data storage strategies from a compliance point of view.
Most countries have legislative and regulatory requirements governing the storage and management of data in cloud environments. This is particularly relevant for public, community and hybrid cloud models, to ensure data privacy and protection for organizations using a third party cloud provider.
Common areas of regulation include:
This is an example of such legal frameworks:
Privacy and security are spread over different industry-specific laws and regulations:
Cloud security architecture should recognize the issues that arise with security management, which addresses these issues with security controls. Cloud security controls are put in place to safeguard any weaknesses in the system, and reduce the effect of an attack.
The following security controls are described below.
For more information, see See also NIST Special Publication 800-53.
The many different forms of license agreements for software are often written with the use of dedicated hardware in mind. This model is relevant for the cloud platform itself, including the hypervisor operating system, supporting software for items such as database, RPC, backup, and so on. Consideration must be made when offering Compute service instances and applications to end users of the cloud, since the license terms for that software may need some adjustment to be able to operate economically in the cloud.
Multi-site OpenStack deployments present additional licensing considerations over and above regular OpenStack clouds, particularly where site licenses are in use to provide cost efficient access to software licenses. The licensing for host operating systems, guest operating systems, OpenStack distributions (if applicable), software-defined infrastructure including network controllers and storage systems, and even individual applications need to be evaluated.
Topics to consider include: