Menu Close
Settings Close

Language and Page Formatting Options

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. Note

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. Identifying security zones in Red Hat OpenStack Platform

Security zones are common resources, applications, networks and servers that share common security concerns. Security zones should share the same authentication and authorization requirements, and users.

For example, a you can segment a default installation of Red Hat OpenStack Platform into the following zones:

Table 1.1. Security zones

ZoneNetworksDetails

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.3. 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

  1. Log on to the undercloud, and source stackrc:

    $ source /home/stack/stackrc
  2. Run openstack subnet list to 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  |
    +---------------------+------------------+
  3. Run openstack server list to 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 |
    +-------------------------+-------------------------+
  4. Use the ctlplane address from the openstack server list command to query the configuration of a physical node:

    ssh heat-admin@192.168.101.15 ip addr

1.4. 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.5. 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.