Chapter 1. Introduction to security
Use the tools provided with Red Hat Openstack Platform (RHOSP) to prioritize security in planning, and in operations, to meet users' expectations of privacy and the security of their data. Failure to implement security standards can lead to downtime or data breaches. Your use case might be subject to laws that require passing audits and compliance processes.
Follow the instructions in this guide to harden the security of your environment. However, these recommendations do not guarantee security or compliance. You must assess security from the unique requirements of your environment.
- For information about hardening Ceph, see Data security and hardening guide.
1.1. Red Hat OpenStack Platform security
By default, Red Hat OpenStack Platform (RHOSP) director creates the overcloud with the following tools and access controls for security:
- SElinux
- SELinux provides security enhancement for RHOSP by providing access controls that require each process to have explicit permissions for every action.
- Podman
- Podman as a container tool is a secure option for RHOSP as it does not use a client/server model that requires processes with root access to function.
- System access restriction
- You can only log into overcloud nodes using either the SSH key that director creates for heat-admin during the overcloud deployment, or a SSH key that you have created on the overcloud. You cannot use SSH with a password to log into overcloud nodes, or log into overcloud nodes using root.
You can configure director with the following additional security features based on the needs and trust level of your organization:
- Public TLS and TLS-everywhere
- Hardware security module integration with OpenStack Key Manager (barbican)
- Signed images and encrypted volumes
- Password and fernet key rotation using workflow executions
1.2. Understanding the Red Hat OpenStack Platform admin role
When you assign a user the role of admin, this user has permissions to view, change, create, or delete any resource on any project. This user can create shared resources that are accessible across projects, such as publicly available glance images, or provider networks. Additionally, a user with the admin role can create or delete users and manage roles.
The project to which you assign a user the admin role is the default project in which openstack commands are executed. For example, if an admin user in a project named development runs the following command, a network called internal-network is created in the development project:
openstack network create internal-network
The admin user can create an internal-network in any project by using the --project parameter:
openstack network create internal-network --project testing
1.3. Identifying security zones in Red Hat OpenStack Platform
Security zones are resources, applications, networks and servers that share common security concerns. Design security zones so to have common authentication and authorization requirements, and users. You can define your own security zones to be as granular as needed based on the architecture of your cloud, the level of acceptable trust in your environment, and your organization’s standardized requirements. The zones and their trust requirements can vary depending upon whether the cloud instance is public, private, or hybrid.
For example, a you can segment a default installation of Red Hat OpenStack Platform into the following zones:
Table 1.1. Security zones
| Zone | Networks | Details |
|---|---|---|
| Public | external | The public zone hosts the external networks, public APIs, and floating IP addresses for the external connectivity of instances. This zone allows access from networks outside of your administrative control and is an untrusted area of the cloud infrastructure. |
| Guest | tenant | The guest zone hosts project networks. It is untrusted for public and private cloud providers that allow unrestricted access to instances. |
| Storage access | storage, storage_mgmt | The storage access zone is for storage management, monitoring and clustering, and storage traffic. |
| Control | ctlplane, internal_api, ipmi | The control zone also includes the undercloud, host operating system, server hardware, physical networking, and the Red Hat OpenStack Platform director control plane. |
1.4. Locating security zones in Red Hat OpenStack Platform
Run the following commands to collect information on the physical configuration of your Red Hat OpenStack Platform deployment:
Procedure
Log on to the undercloud, and source
stackrc:$ source /home/stack/stackrc
Run
openstack subnet listto match the assigned ip networks to their associated zones:openstack subnet list -c Name -c Subnet +---------------------+------------------+ | Name | Subnet | +---------------------+------------------+ | ctlplane-subnet | 192.168.101.0/24 | | storage_mgmt_subnet | 172.16.105.0/24 | | tenant_subnet | 172.16.102.0/24 | | external_subnet | 10.94.81.0/24 | | internal_api_subnet | 172.16.103.0/24 | | storage_subnet | 172.16.104.0/24 | +---------------------+------------------+
Run
openstack server listto list the physical servers in your infrastructure:openstack server list -c Name -c Networks +-------------------------+-------------------------+ | Name | Networks | +-------------------------+-------------------------+ | overcloud-controller-0 | ctlplane=192.168.101.15 | | overcloud-controller-1 | ctlplane=192.168.101.19 | | overcloud-controller-2 | ctlplane=192.168.101.14 | | overcloud-novacompute-0 | ctlplane=192.168.101.18 | | overcloud-novacompute-2 | ctlplane=192.168.101.17 | | overcloud-novacompute-1 | ctlplane=192.168.101.11 | +-------------------------+-------------------------+
Use the
ctlplaneaddress from theopenstack server listcommand to query the configuration of a physical node:ssh heat-admin@192.168.101.15 ip addr
1.5. Connecting security zones
You must carefully configure any component that spans multiple security zones with varying trust levels or authentication requirements. These connections are often the weak points in network architecture. Ensure that you configure these connections to meet the security requirements of the highest trust level of any of the zones being connected. In many cases, the security controls of the connected zones are a primary concern due to the likelihood of attack. The points where zones meet present an additional potential point of attack and adds opportunities for attackers to migrate their attack to more sensitive parts of the deployment.
In some cases, OpenStack operators might want to consider securing the integration point at a higher standard than any of the zones in which it resides. Given the above example of an API endpoint, an adversary could potentially target the Public API endpoint from the public zone, leveraging this foothold in the hopes of compromising or gaining access to the internal or admin API within the management zone if these zones were not completely isolated.
The design of OpenStack is such that separation of security zones is difficult. Because core services will usually span at least two zones, special consideration must be given when applying security controls to them.
1.6. Threat mitigation
Most types of cloud deployment, public, private, or hybrid, are exposed to some form of security threat. The following practices help mitigate security threats:
- Apply the principle of least privilege.
- Use encryption on internal and external interfaces.
- Use centralized identity management.
- Keep Red Hat OpenStack Platform updated.
Compute services can provide malicious actors with a tool for DDoS and brute force attacks. Methods of prevention include egress security groups, traffic inspection, intrusion detection systems, and customer education and awareness. For deployments accessible by public networks or with access to public networks, such as the Internet, ensure that processes and infrastructure are in place to detect and address outbound abuse.
