API endpoint security

Public endpoints

Public endpoints are exposed as Red Hat OpenShift Container Platform (RHOCP) Routes and are the only endpoints accessible outside the RHOCP cluster. Routes end TLS at the RHOCP ingress controller, typically HAProxy Ingress managed by OpenShift, and re-encrypt traffic to the service pod. You cannot override the default public endpoint mechanism, and only Routes are supported for public endpoints.

Internal endpoints

Internal endpoints are exposed as Kubernetes Services of type LoadBalancer, backed by MetalLB. These endpoints are reachable only on the isolated networks such as InternalAPI, Storage, and others. Configure internal endpoints through NetworkAttachmentDefinitions and NMState. Each internal endpoint receives a VIP from the MetalLB IPAddressPool.

The Identity service (keystone) service catalog registers both public and internal URLs. OpenStack services communicate with each other through the internal endpoints by default, keeping inter-service traffic off the public network. In Red Hat OpenStack Platform (RHOSP) 17.1, registration of internal URLs was automated by director. In RHOSO 18.0, the OpenStack Operator automatically registers both public Route-based and internal MetalLB-based endpoints in the keystone catalog during control plane deployment.

TLS operates at two layers, ingress TLS and pod-level TLS:

• Ingress TLS encrypts traffic between external clients and the Red Hat OpenShift Container Platform (RHOCP) Route. The Route terminates TLS and re-encrypts to the pod.
• Pod-level TLS encrypts traffic between pods within the openstack namespace. Each service pod receives its own certificate from cert-manager that covers inter-service communication, such as nova-api calling the Identity service keystone for token validation.

  Certificate configuration

  Certificate lifetimes are configured in the OpenStackControlPlane CR under the tls spec. The default configuration provides separate CA and certificate durations for ingress, internal, libvirt, and OVN:

  spec:
    tls:
      ingress:
        ca:
          duration: 87600h0m0s    # 10 years
        cert:
          duration: 43800h0m0s    # 5 years
        enabled: true
      podLevel:
        enabled: true
        internal:
          ca:
            duration: 87600h0m0s
          cert:
            duration: 43800h0m0s

  Custom certificate authorities

  If you want to sign certificates with your own internal CA instead of the autogenerated cert-manager CA, you can create custom Issuers for both ingress or public, and internal or pod-level endpoints:

  1. Create a Kubernetes Secret containing your CA certificate and private key.
  2. Create a cert-manager Issuer resource referencing that Secret.
  3. Reference the custom Issuer in the OpenStackControlPlane CR using tls.ingress.ca.customIssuer or tls.podLevel.internal.ca.customIssuer. Important
     When using custom CAs, you must distribute the CA certificate to all clients that access the OpenStack API. Extract the CA from the rootca-public Secret and add it to your clouds.yaml using the cacert parameter.

  Replacing the RHOSP 17.1 HAProxy TLS cipher configuration

  In Red Hat OpenStack Platform (RHOSP) 17.1, TLS cipher suites and minimum protocol versions were configured through Hiera tripleo::haproxy::ssl_options and applied to HAProxy on controller nodes. In RHOSO 18.0, this configuration does not exist. TLS termination is handled by Red Hat OpenShift Container Platform (RHOCP) Ingress Controller and cert-manager:

  1. Use RHOCP Ingress Controller for public Routes. Configure Cipher suites and TLS minimum version in the IngressController CR.
  2. Use cert-manager for pod-level TLS. Certificate key algorithms and sizes are determined by the Issuer configuration. Services use the Go TLS stack, which defaults to TLS 1.2 or higher with modern cipher suites. Note
     There is no equivalent to the RHOSP 17.1 tls-ciphers.yaml heat template. To enforce a minimum of TLS 1.3 on public endpoints, configure the RHOCP IngressController with 'spec.tlsSecurityProfile.type: Custom' and set 'minTLSVersion: VersionTLS13'.

Verify that inter-service traffic uses internal endpoints by inspecting the Identity service (keystone) service catalog:

$ oc rsh openstackclient
$ openstack endpoint list --interface internal

If any service is misconfigured to use the public URL for internal communication, traffic routes with the Red Hat OpenShift Container Platform (RHOCP) ingress controller, increasing latency and exposing internal calls to the public network path.

The default metadef prevents the following two risks:

Information disclosure

Metadef namespaces could leak sensitive resource names such as customer names or internal project identifiers to unauthorized users.

Denial of service

There is no built-in limit on the number of metadef resources. An unrestricted user could fill the glance database.

Apply metadef policy overrides through customServiceConfig in the glance section of the OpenStackControlPlane CR:

spec:
  glance:
    template:
      glanceAPIs:
        default:
          customServiceConfig: |
            [oslo_policy]
            policy_file = /etc/glance/policy.yaml

Provide the policy overrides in a ConfigMap mounted into the glance pod. To grant all users read/write access to metadef APIs, set the metadef_default rule to an empty string (""). To grant read-only access, set it to role:reader.

Restricting API ingress

Apply NetworkPolicy resources to restrict which source IPs and pods can reach API service pods, such as the following:

1. Allow ingress to keystone, nova-api, neutron-api, and other service pods only from the Red Hat OpenShift Container Platform (RHOCP) ingress controller pods for public traffic, and from other OpenStack service pods for internal traffic.
2. Deny all other ingress by default using a deny-allNetworkPolicy as a baseline.
3. For MetalLB-exposed internal endpoints, restrict the source IP ranges in the MetalLB IPAddressPool or Service annotations to the InternalAPI CIDR.

Note

Verify that no existing NetworkPolicy on the RHOCP cluster blocks communication between the openstack-operators namespace and the openstack namespace. The OpenStack Operator uses this path for reconciliation.

Combining with external controls

NetworkPolicy operates at L3 or L4. For deeper inspection such as L7 HTTP filtering, or payload inspection, deploy an external web application firewall (WAF) or API gateway in front of the RHOCP ingress controller. You can also use physical network segmentation such as VLANs and firewall rules at the switch or router level.

Audit logging for API access

Every API request that enters through an Red Hat OpenShift Container Platform (RHOCP) Route is logged by the RHOCP ingress controller. Enable access logging on the IngressController CR to capture source IPs, request paths, response codes, and latency. Forward these logs to your SIEM for anomaly detection. Additionally, RHOCP API audit logs capture all oc exec, oc rsh, and CR modification events in the openstack namespace, which are useful for security logging.

Fernet key rotation

The Identity service (keystone) fernet keys are automatically rotated in Red Hat OpenStack Services on OpenShift (RHOSO) 18.0. You can configure the rotation frequency and number of active keys in the OpenStackControlPlane CR. Frequent rotation limits the window of opportunity to exploit a compromised token.

Client certificate distribution

When RHOSO is deployed with default or custom CA certificates that are not signed by a public CA, you must distribute the CA certificate to every client workstation and automation system that accesses the API. Extract it from the rootca-public Secret:

$ oc get secret rootca-public -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt

Add the CA path to your clouds.yaml authentication file:

clouds:
  mycloud:
    cacert: /path/to/ca.crt
    auth:
      auth_url: https://keystone-public-openstack.apps.example.com