Applying NetworkPolicy to restrict control plane traffic

By default, pods in the openstack namespace can communicate with each other. To enforce least-privilege, create NetworkPolicy resources that restrict ingress to only the required ports and source namespaces. The following example shows how to restrict ingress to keystone API pods:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-keystone-ingress
  namespace: openstack
spec:
  podSelector:
    matchLabels:
      service: keystone
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: openstack
      ports:
        - protocol: TCP
          port: 5000

Note

The OVN-Kubernetes CNI supports NetworkPolicy enforcement. Verify your CNI before relying on NetworkPolicy for security boundaries.

Restricting external access to OpenStack APIs

Public OpenStack API endpoints are exposed through RHOCP Routes that are backed by the HAProxy-based RHOCP Ingress Controller, or MetalLB LoadBalancer services. Complete the following steps to restrict which external IPs can reach these endpoints:

• For RHOCP Routes, configure the Ingress Controller with IP allowlists or place an external firewall or load balancer in front of the RHOCP cluster.
• For MetalLB, use spec.loadBalancerSourceRanges on the Service object to restrict source CIDRs.
• For internal APIs, use the internalapi network with Multus or NetworkAttachmentDefinitions, which keeps traffic off the public network entirely.

If you use SNMP monitoring on your data plane nodes, configure the SNMP daemon through edpm-ansible Ansible variables or a custom OpenStackDataPlaneService CR that deploys a ConfigMap with your snmpd.conf overrides.

Set the following SNMP access control settings as Ansible variables or deploy a custom snmpd.conf through a ConfigMap:

• ro_community is an IPv4 read-only community string. Change from the default value of public.
• ro_community6 is an IPv6 read-only community string. Change from the default value of public.
• ro_network is network permitted to query the daemon. The default is 127.0.0.1.
• ro_network6 is an IPv6 network permitted to query the daemon. The default is ::1/128.

The following example shows custom SNMP configured with ConfigMap and DataPlaneService:

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-snmpd-config
  namespace: openstack
data:
  snmpd.conf: |
    com2sec notConfigUser default mysecurestring
    com2sec6 notConfigUser default myv6securestring
    group notConfigGroup v1 notConfigUser
    group notConfigGroup v2c notConfigUser
    view systemview included .1.3.6.1.2.1.1
    access notConfigGroup "" any noauth exact systemview none none

Reference this ConfigMap in a custom OpenStackDataPlaneService CR that deploys it to the data plane nodes.

RBAC on the RHOCP cluster

Limit cluster-admin access to a small number of administrators. Create RHOCP Roles and RoleBindings that are scoped to the openstack and openstack-operators namespaces for day-to-day operations. The OpenStack Operator CRDs can be managed by users with namespace-scoped privileges.

Pod security

RHOCP enforces Pod Security Admission (PSA) by default. The OpenStack Operator pods run with the profiles set by the Operator itself. Do not relax PSA labels on the openstack namespace unless Red Hat guidance explicitly requires it.

etcd encryption

All Kubernetes Secrets, including the osp-secret containing OpenStack service credentials, are stored in etcd. Enable etcd encryption at rest on your RHOCP cluster to protect these credentials.

Image provenance

RHOSO service container images are signed and delivered through the Red Hat container registry. Verify that your RHOCP cluster is configured to enforce image signature verification and that your OpenStackVersion CR references only supported image versions.

TLS on the control plane

The RHOSO OpenStack Operator integrates with the cert-manager Operator to manage TLS certificates for OpenStack service endpoints. TLS is enabled by default for both internal and public endpoints. The cert-manager Operator creates and rotates certificates automatically. If you use a custom CA, configure the issuer accordingly in the cert-manager configuration before deploying the control plane.

Observability and audit

RHOSO 18.0 integrates natively with Prometheus and AlertManager from RHOCP Observability, and Loki and ClusterLogForwarder from the Logging stack. Enable these components to collect metrics and logs from both the control plane pods and the data plane nodes. The Telemetry services ceilometer and prometheus are enabled by default. For security auditing, configure the RHOCP API audit log and forward RHOSO service logs to a centralized SIEM.