Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

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 securtiy

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

You may need to redefine your own security zones to be more granular 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.

  • Management zone: The management zone includes the undercloud, host operating system, server hardware, physical networking, and the Red Hat OpenStack Platform director control plane.

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

  • Admin zone: The admin zone hosts traffic for system administration, monitoring, or backup. but is a place where no OpenStack APIs or control interfaces are hosted.

1.3. Connecting security zones

Any component that spans across multiple security zones with different 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 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 classification, actors, and attack vectors

Most types of cloud deployment, public, private, or hybrid, are exposed to some form of attack. This section categorizes attackers and summarizes potential types of attacks in each security zone.

1.4.1. Threat actors

A threat actor is an abstract way to refer to a class of adversary that you might attempt to defend against. The more capable the actor, the more rigorous the security controls that are required for successful attack mitigation and prevention. Security is a matter of balancing convenience, defense, and cost, based on requirements. In some cases it will not be possible to secure a cloud deployment against all of the threat actors described here. When deploying an OpenStack cloud, you must decide where the balance lies for your deployment and usage.

As part of your risk assessment, you must also consider the type of data you store and any accessible resources, as this will also influence certain actors. However, even if your data is not appealing to threat actors, they could simply be attracted to your computing resources, for example, to participate in a botnet, or to run unauthorized cryptocurrency mining.

  • Nation-State Actors - This is the most capable adversary. Nation-state actors can bring tremendous resources against a target. They have capabilities beyond that of any other actor. It is very difficult to defend against these actors without incredibly stringent controls in place, both human and technical.
  • Serious Organized Crime - This class describes highly capable and financially driven groups of attackers. They are able to fund in-house exploit development and target research. In recent years the rise of organizations such as the Russian Business Network, a massive cyber-criminal enterprise, has demonstrated how cyber attacks have become a commodity. Industrial espionage falls within the serious organized crime group.
  • Highly Capable Groups - This refers to ‘Hacktivist’ type organizations who are not typically commercially funded but can pose a serious threat to service providers and cloud operators.
  • Motivated Individuals Acting alone - these attackers come in many guises, such as rogue or malicious employees, disaffected customers, or small-scale industrial espionage.
  • Script Kiddies - These attackers don’t target a specific organization, but run automated vulnerability scanning and exploitation. They are often only a nuisance, however compromise by one of these actors is a major risk to an organization’s reputation.

The following practices can help mitigate some of the risks identified above:

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

1.4.2. Outbound Attacks and Reputational Risk

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.