Establish security foundations

Prioritize security in your plans and operations for your deployment to prevent downtime or data breaches.

Default and inherited security controls
Copy link

Your deployment inherits security controls from Red Hat OpenShift Container Platform (RHOCP) for the control plane and from RHEL 9 for the data plane nodes. These controls provide a layered security foundation.

  • Red Hat OpenShift Container Platform (RHOCP) for the control plane
  • RHEL 9 for the data plane nodes.

The combined deployment provides the following default security controls:

SElinux
SELinux is enforced on both the RHOCP cluster nodes and the RHEL 9 data plane nodes. It provides mandatory access controls (MAC) that require each process to have explicit permissions for every action. On the data plane, SELinux confines containerized OpenStack services managed by Podman. On the control plane, SELinux works in conjunction with the OpenShift Security Context Constraints (SCCs) applied to pods.
Container isolation
Control plane services run as pods on RHOCP and data plane services run in Podman-managed containers on RHEL 9 nodes. Neither runtime uses a client/server daemon model that requires persistent root processes.
System access restriction
Control plane access is governed by RHOCP RBAC so you can interact with the OpenShift console or command line with cluster-admin or scoped credentials. As part of RHEL 9 hardening, disable password-based SSH and direct root login so that you can access data plane RHEL nodes with SSH key-based authentication only.
TLS everywhere (TLS-e)
TLS-e is enabled by default in RHOSO 18.0. Certificate lifecycle is handled by the cert-manager Operator on RHOCP, which applies ingress or public encryption and pod-level re-encryption for internal traffic.
OpenStack Key Manager (barbican)
The Key Manager service provides secret storage and encryption key management by default in RHOSO 18.0.

You can configure RHOSO with the following additional security features based on the needs and trust level of your organization:

  • Custom TLS certificates from your own internal CA, applied by custom cert-manager issuers.
  • Hardware security module (HSM) integration with barbican.
  • Signed images and encrypted volumes.
  • Fernet key rotation is automated by default. You can configure frequency and active key count.
  • Kubernetes NetworkPolicies for control plane namespace traffic restriction.
  • LDAP or federated identity provider integration for keystone authentication.
  • Memcached authentication.

Admin role permissions
Copy link

When you assign a user the role of admin, this user has permissions to view, change, create, or delete any resource on any project. 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 named internal-network is created in the development project:

$ openstack network create internal-network

The admin user can create a network named internal-network in a different project by naming the project with the --project option, such as testing in this example:

$ openstack network create internal-network --project testing

In Red Hat OpenStack Services on OpenShift (RHOSO), you use the admin role to access the OpenStack API, not the underlying Red Hat OpenShift Container Platform (RHOCP) cluster. You must use RHOCP roles such as cluster-admin to access control plane infrastructure such as pods, operators, custom resources, secrets. A RHOSO admin cannot view or modify RHOCP resources, and a RHOCP cluster-admin does not automatically have an OpenStack identity. Ensure that you treat both privilege sets with least-privilege discipline.

Security zones
Copy link

Group your cloud resources by trust level and authentication requirements to isolate sensitive workloads. Define your own security zones based on your cloud architecture and the level of acceptable trust in your environment.

For example, you can segment a default installation of your Red Hat OpenStack Services on OpenShift (RHOSO) deployment into the following zones:

Table 1. Security zones
Zone Networks / Boundary Details

Public

External network, Red Hat OpenShift Container Platform (RHOCP) Ingress routes, floating IPs

The public zone hosts public API endpoints that are exposed as RHOCP routes, the OpenStack Dashboard, and floating IP addresses for external instance connectivity. This zone allows access from networks outside your administrative control and is an untrusted area of the cloud infrastructure.

Guest

Tenant project networks

The guest zone hosts project networks that are created by tenants. It is untrusted for public and private cloud providers that allow unrestricted access to instances.

Storage access

Storage, storage management

The storage access zone hosts storage traffic, such as Ceph public and cluster networks, and includes storage management, monitoring, clustering, and data replication traffic.

Control

RHOCP cluster network, internal API, MetalLB VIPs, IPMI/BMC, EDPM management

The control zone hosts the RHOCP cluster that has etcd, Kubernetes API, and OpenShift services, all RHOSO control plane service pods, the internal API endpoints exposed by MetalLB load balancer IPs, and the management interfaces that the OpenStack Operator uses to configure data plane RHEL nodes with Ansible. It also includes the BMC/IPMI networks for bare-metal provisioning.

In Red Hat OpenStack Services on OpenShift (RHOSO) the control zone now spans the following two domains:

  • The RHOCP cluster which has its own network fabric, pod networking with OVN-Kubernetes or OpenShift SDN, and Kubernetes API.
  • The RHEL data plane nodes that are managed over the EDPM management network.

RHOCP manages its own node provisioning lifecycle, and the OpenStack Operator drives data plane node configuration remotely.

Map security zones to your network topology
Copy link

Collect information on the physical and logical configuration of your deployment.

Before you begin
Copy link

  • You have a deployed RHOSO environment.
  • You are logged in to the Red Hat OpenShift Container Platform (RHOCP) cluster with cluster-admin privileges.
  • You have a clouds.yaml or credential file configured for the OpenStack CLI, or access to the OpenStackClient pod.

Procedure
Copy link

  1. Identify the RHOCP nodes hosting the RHOSO control plane pods, their IP addresses, and their roles, such as control-plane or worker: 
    $ oc get nodes -o wide
  2. List the RHOSO network isolation configuration by inspecting the NetConfig and NetworkAttachmentDefinition resources in the openstack namespace: 
    $ oc get netconfig -n openstack -o yaml
  3. List the RHOSO network topology including internal API, storage, storage management, tenant, external networks and map to the corresponding VLAN tags and IP subnets. 
    $ oc get network-attachment-definitions -n openstack
  4. List the MetalLB IP address pools to identify the VIP ranges used for internal service endpoints: 
    $ oc get ipaddresspools -n metallb-system
  5. List the data plane node sets and their nodes so you can identify the RHEL compute and storage hosts: 
    $ oc get openstackdataplanenodesets -n openstack
  6. Access the OpenStackClient pod to query OpenStack networking from the tenant perspective: 
    $ oc rsh -n openstack openstackclient

$ openstack network list

$ openstack subnet list
  7. To inspect the network configuration on a specific data plane node, you can SSH to that node using its management IP and then review its interfaces: 
    $ ssh cloud-admin@<data-plane-node-ip> ip addr

Security zone connections
Copy link

A component that spans multiple security zones with varying trust levels or authentication requirements can be a weak point in network architecture. Prioritize and configure these connections to meet the security requirements of the highest trust level of any connected zone.

In Red Hat OpenStack Services on OpenShift (RHOSO), the following are the main zone-bridging points:

Red Hat OpenShift Container Platform (RHOCP) ingress routes
Public API endpoints are exposed as OpenShift routes, bridging the public zone to the control zone, and are TLS-terminated by default. Restrict access using RHOCP route annotations, network policies, or external load balancer ACLs.
MetalLB load balancer IPs
Internal service endpoints use MetalLB VIPs on isolated networks to bridge the control zone internal networks to the data plane. Ensure that you isolate the MetalLB IP pools appropriately.
EDPM management interface
The OpenStack Operator communicates with data plane RHEL nodes over SSH to run Ansible-based configuration. This management path bridges the RHOCP control zone to the data plane host. Restrict which networks can reach the data plane SSH ports.
OVN Southbound / Northbound connections
OVN southbound and northbound control traffic between the control plane and data plane nodes is encrypted with TLS when TLS-e is enabled.
Tenant network gateways
If you use centralized non-DVR routing, the traffic between the guest zone and the external or public zone traverses gateway nodes or control plane OVN gateway pods. With DVR, this traffic is distributed to compute nodes directly.

For all security zones, you can implement Kubernetes NetworkPolicies in the OpenStack namespace, segment the networks at the physical or VLAN level, and enforce firewalld rules on data plane hosts.

Threat mitigation
Copy link

You can mitigate security threats to your deployment in public, private, or hybrid cloud environments with the following best practices:

Apply the principle of least privilege
Use scoped Red Hat OpenShift Container Platform (RHOCP) RBAC roles for infrastructure operators and OpenStack SRBAC roles for cloud users. Do not grant cluster-admin or OpenStack admin privileges broadly.
Use encryption on internal and external interfaces
TLS-e is enabled by default in RHOSO 18.0 with cert-manager. Verify that it remains enabled and that certificates are rotating properly.
Use centralized identity management
Integrate keystone with an external identity provider such as Red Hat Identity Management (IdM) or with Active Directory by using LDAP or federation. RHOSO 18.0.14 supports multi-realm federated SSO for the Dashboard.
Keep RHOSO, RHOCP, and RHEL updated
Apply minor updates to the RHOSO control plane through the OpenStack Operator lifecycle. Apply RHEL errata to data plane nodes. Apply RHOCP updates through the OpenShift update channel. Coordinate updates across all three layers.
Harden data plane nodes with standard RHEL tools
Enable firewalld, audit system events, enforce SELinux, restrict SSH access, and apply CIS or STIG benchmarks as appropriate.
Restrict control plane pod communication
Define Kubernetes NetworkPolicies in the RHOSO namespace to limit pod traffic between pods and API ingress.

You can prevent DDoS and brute force attacks by using egress security groups, traffic inspection, intrusion detection systems, and customer education and awareness. For deployments accessible by public networks, ensure that processes and infrastructure are in place to detect and address outbound abuse.