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. 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: The admin user can create an internal-network in any project by using the --project parameter: 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 : Run openstack subnet list to match the assigned ip networks to their associated zones: Run openstack server list to list the physical servers in your infrastructure: Use the ctlplane address from the openstack server list command to query the configuration of a physical node: 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. Additional resources Implementing TLS-e with Ansible Integrating OpenStack Identity (keystone) with Red Hat Identity Manager (IdM) Keeping Red Hat OpenStack Platform Updated

Commands:
openstack network create internal-network
openstack network create internal-network --project testing
source /home/stack/stackrc
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 | +---------------------+------------------+
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 | +-------------------------+-------------------------+
ssh heat-admin@192.168.101.15 ip addr