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 provides security enhancement for RHOSP by providing access controls that require each process to have explicit permissions for every action.
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. Security zones

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.

Define your own security zones to be as granular as needed based on the unique architecture of your cloud, the level of acceptable trust in your environment, and standardized requirements. The zones and their trust requirements can vary depending upon whether the cloud instance is public, private, or hybrid.

The minimum zones required to deploy a security-hardened OpenStack cloud, from the least to most trusted, are as follows:

  • Public zone: The public zone hosts public-facing APIs and neutron external networks like floating IP and SNAT for the external connectivity of instances. This zone is an untrusted area of the cloud infrastructure. It refers either to cloud access by the public or to networks outside of your area or responsibility that are external to your Red Hat OpenStack Platform deployment.

    Any data with confidentiality or integrity requirements that traverses this zone should be protected using compensating controls.

  • Guest zone: The guest zone hosts project networks, whether VXLAN or GENEVE. It is untrusted for public and private cloud providers that do not have stringent controls on instance use or allow unrestricted internet access to instances.

    If you are a private cloud provider, you can consider this network as internal and trusted if controls are implemented to assert that the instances and associated projects, to include the underlying hardware and physical networks, can be trusted.

  • Storage access zone: The storage access zone is for storage management, monitoring and clustering, as well as storage traffic itself.

    Data transmitted across this network requires a high level of integrity and confidentiality. There can also be strong availability requirements.

    With the exception of replication requirements, do not make this network accessible from outside the cloud, other than by storage appliances Components deployed into this zone are sensitive from a security perspective.

  • Control zone: The control zone includes the undercloud, host operating system, server hardware, physical networking, and the Red Hat OpenStack Platform director control plane.
  • Administration zone: The adminstration zone hosts traffic for system administration, monitoring, or backup. but is a place where no OpenStack APIs or control interfaces are hosted.

    The management network is used for system administration, monitoring, or backup. Do not host OpenStack APIs or control interfaces on this zone.

1.3. Connecting security zones

Any component that spans across multiple security zones with varying trust levels or authentication requirements must be carefully configured. These connections are often the weak points in network architecture, and should always be configured 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 should be a primary concern due to the likelihood of attack. The points where zones meet do present an additional attack service, 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.4. 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:

  • Security updates - You must consider the end-to-end security posture of your underlying physical infrastructure, including networking, storage, and server hardware. These systems will require their own security hardening practices. For your Red Hat OpenStack Platform deployment, you should have a plan to regularly test and deploy security updates.
  • Access management - When granting system access to individuals, you should apply the principle of least privilege, and only grant them the granular system privileges they actually need. You can help enforce this policy using the practice of AAA (access, authorization, and accounting). This approach can also help mitigate the risks of both malicious actors and typographical errors from system administrators.
  • Manage insiders - You can help mitigate the threat of malicious insiders by applying careful assignment of role-based access control (minimum required access), using encryption on internal interfaces, and using authentication/authorization security (such as centralized identity management). You can also consider additional non-technical options, such as separation of duties and irregular job role rotation.

Careful consideration should be given to potential outbound abuse from a cloud deployment. Cloud deployments tend to have lots of resources available; an attacker who has established a point of presence within the cloud, either through hacking or entitled access, such as rogue employee, can use these resources for malicious purposes. Clouds with Compute services make for ideal DDoS and brute force engines. The issue is especially pressing for public clouds as their users are largely unaccountable, and can quickly spin up numerous disposable instances for outbound attacks. Methods of prevention include egress security groups, traffic inspection, intrusion detection systems, customer education and awareness, and fraud and abuse mitigation strategies. For deployments accessible by or with access to public networks, such as the Internet, processes and infrastructure should be in place to ideally detect, and also address outbound abuse.

1.5. Supporting software

Underpinning the whole of the Red Hat solution stack is the secure software supply chain. A cornerstone of Red Hat’s security strategy, the goal of this strategically important set of practices and procedures is to deliver solutions that have security built-in upfront and supported over time. Specific steps which Red Hat take include:

  • Maintaining upstream relationships and community involvement to help focus on security from the start.
  • Selecting and configuring packages based on their security and performance track records.
  • Building binaries from associated source code (instead of simply accepting upstream builds).
  • Applying a suite of inspection and quality assurance tools to prevent an extensive array of potential security issues and regressions.
  • Digitally signing all released packages and distributing them through cryptographically authenticated distribution channels.
  • Providing a single, unified mechanism for distributing patches and updates. The Red Hat Enterprise Linux and KVM components which underlie OpenStack are also Common Criteria certified. This involves a third party auditor performing physical site visits, and interviewing staff about adhering to good practices, for example, about the supply chain or development.

In addition, Red Hat maintains a dedicated security team that analyzes threats and vulnerabilities against our products, and provides relevant advice and updates through the Customer Portal. This team determines which issues are important, as opposed to those that are mostly theoretical problems. The Red Hat Product Security team maintains expertise in, and makes extensive contributions to the upstream communities associated with our subscription products. A key part of the process, Red Hat Security Advisories, deliver proactive notification of security flaws affecting Red Hat solutions – along with patches that are frequently distributed on the same day the vulnerability is first published.