Manage TLS encryption and certificates

Configure and manage TLS encryption and certificates to protect data in transit and ensure that your environment complies with your organization’s security policies.

In RHOSO 18.0, TLS everywhere (TLS-e) cannot be disabled after it is enabled. Certificate lifecycle management is handled by the cert-manager Operator, which replaces FreeIPA, certmonger, and tripleo-ipa from Red Hat OpenStack Platform (RHOSP) 17.1. In RHOSO 18.0, there is no undercloud, no novajoin, or no IdM integration to configure. Certificates are issued, renewed, and rotated automatically.

TLS default configuration and custom certificates
Copy link

When you deploy your cloud environment, most API connections are protected by TLS by default. You can customize these settings to apply trusted certificates from your own internal certificate authority (CA) to comply with your organization’s security requirements.

Note
TLS is not currently available for the internal Alert Manager Web UI service endpoint.

You might be required to protect public APIs by using your own internal certificate authority(CA). To replace the automatically generated certificates you must create a secret that contains your additional CA certs, including all certificates in needed chains of trust.

You can apply trusted certificates from your own internal CA to public interfaces on RHOSO. The public interface is where ingress traffic meets the service’s route. Do not attempt to manage encryption on internal pod-level interfaces.

If you decide to apply trusted certificates from your own internal CA, you will need the following information:

DNS names

For each service you apply your own custom certificate to, you will need its DNS hostname for the process of generating the certificate. You can get a list of public hostnames by using the command: oc get -n openstack routes.

Note
To use a single certificate for two or more services, use a wildcard in the DNS name field, or list multiple DNS names in the subject alt names field. If you do not use a wildcard, then you must update the certificate if a route hostname changes.
Duration
To update a service’s certificate in OpenShift, the service must be restarted. The duration for the certificate is the longest amount of time a service can stay live without being restarted, subject to your internal security policies.
Usages
You must include - key encipherment, digital signature, and server auth within the list of usages in your certificate.

Updating TLS to use custom certificates requires edits to both the control plane and the data plane.

The following are the default TLS settings that are used if not annotated and changed:

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: myctlplane
spec:
  tls:
    ingress:
      ca:
        duration: 87600h
      cert:
        duration: 43800h
      enabled: true
    podLevel:
      enabled: true
      internal:
        ca:
          duration: 87600h
        cert:
          duration: 43800h
      libvirt:
        ca:
          duration: 87600h
        cert:
          duration: 43800h
      ovn:
        ca:
          duration: 87600h
        cert:
          duration: 43800h

TLS certificate layers and trust chains
Copy link

Your deployment encrypts traffic at multiple layers. Each layer has its own certificate authority (CA) and certificate chain, all managed by cert-manager.

Ingress TLS (public endpoints)
Public API endpoints are exposed as Red Hat OpenShift Container Platform (RHOCP) Routes. TLS terminates at the HAProxy-based RHOCP Ingress Controller, which re-encrypts traffic to the service pod. The ingress CA and certificates are stored in the rootca-public Secret in the openstack namespace.
Pod-level TLS (internal endpoints)
Internal communication between services is encrypted at the pod level. Each OpenStack service pod receives its own TLS certificate from cert-manager. This covers service-to-service calls, such as nova-api to keystone or neutron to nova, that traverse the InternalAPI network over MetalLB LoadBalancer Services. The internal CA is stored in the rootca-internal Secret.
Service-specific TLS

RHOSO 18.0 issues separate certificate chains for specific infrastructure services that have distinct trust requirements:

  1. libvirt certificates for live migration traffic between compute nodes.
  2. OVN certificates for OVN Southbound and Northbound database connections.

Each of these has its own CA duration and certificate duration configured independently in the OpenStackControlPlane CR.

Data plane TLS
You can also configure data plane nodes, such as RHEL compute hosts, with TLS. Set tlsEnabled: true in the OpenStackDataPlaneNodeSet CR. When enabled, cert-manager provisions certificates for services that run on data plane nodes, and the EDPM Ansible deployment distributes the CA trust bundle to each node.
Note
If your deployment routes traffic through the control plane, enabling or changing TLS on the data plane requires redeployment and causes temporary connectivity loss to RabbitMQ and OVS from the control plane. This does not affect active workloads if floating IP connectivity does not traverse the control plane.

Create a custom cert-manager issuer
Copy link

Create a custom cert-manager issuer so that TLS certificates for your ingress or internal endpoints comply with your organization’s security policies or integrate with your existing PKI infrastructure.

About this task
Copy link

To manage your own certificates for internal endpoints, you must create a custom internal issuer. TLS-e uses the following issuers by default:

  • rootca-internal
  • rootca-libvirt
  • rootca-ovn
  • rootca-public

Procedure
Copy link

  1. Create a custom issuer in a file named rootca-custom.yaml: 
    apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: <issuer_name>
spec:
  ca:
    secretName: <secret_name>

    where:

    <issuer_name>
    Specifies the name of your custom issuer, for example, rootca-ingress-custom.
    <secret_name>
    Specifies the name of the Secret CR used by the certificate for your custom issuer. If you do not include a secret, one is created automatically.
  2. Create a certificate in a file named ca-issuer-certificate.yaml: 
    apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: <issuer_name>
spec:
  commonName: <issuer_name>
  isCA: true
  duration: <hours>
  privateKey:
    algorithm: RSA
    size: 3072
  issuerRef:
    name: selfsigned-issuer
    kind: Issuer
  secretName: <secret-name>

    where:

    <issuer_name>
    Specifies the name of your custom issuer. This matches the issuer created in the first step.
    <hours>
    Specifies the duration in hours, for example, a value of 87600h is equivalent to 3650 days, or about 10 years.
    <secret_name>
    Specifies the name of the Secret CR used by the certificate for your custom issuer. If you do not include a secret, one is created automatically.
  3. Create the issuer and certificate: 
    $ oc create -f rootca-custom.yaml
$ oc create -f ca-issuer-certificate.yaml
  4. Add the custom issuer to the TLS service definition in the control plane CR file.
    1. If your custom issuer is an ingress issuer, the customer issuer is defined under the ingress attribute as shown below: 
      apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack-control-plane
spec:
  tls:
     ingress:
       enabled: true
       ca:
         customIssuer: <issuer_name>
   ...

      where:

      <issuer_name>
      Specifies the name of your custom issuer. This matches the issuer created in the first step.
    2. If your custom issuer is an internal issuer, the custom issuer is defined at the pod level under the internal attribute as shown below: 
      apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: myctlplane
spec:
  tls:
     ingress:
       enabled: true
     podLevel:
       enabled: true
       internal:
         ca:
           customIssuer: <issuer_name>

      where:

      <issuer_name>
      Specifies the name of your custom issuer. This matches the issuer created in the first step.

Add custom CA certificates to the control plane
Copy link

Add custom certificate authority (CA) certificates to the control plane so that OpenStack services can validate certificates from your internal CA or third-party providers.

About this task
Copy link

To validate custom CA certificates on your control plane, you must add your custom CA certificate into a bundle that includes all certificates that OpenStack services can verify against.

Note
If TLS is not enabled on each node set, then it must be enabled, which requires deploying the data plane.

Procedure
Copy link

  1. Create a PEM-formatted bundle, for example, mybundle.pem. Include all the CA certificates that you want OpenStack to trust.
  2. Create a manifest file called cacerts.yaml that includes the mybundle.pem created in the previous step. Include all the certificates in chains of trust if applicable: 
    apiVersion: v1
kind: Secret
metadata:
  name: cacerts
  namespace: openstack
type: Opaque
data:
  myBundleExample: <cat mybundle.pem | base64 -w0>
  CACertExample: <cat cacert.pem | base64 -w0>

    where:

    mybundle.pem
    Specifies the name of your certificate or certificate bundle. The results are pasted as the value of the myBundleExample field.
    cacert.pem
    Specifies the name of your CA certificate.
  3. Create the secret from the manifest file: 
    $ oc apply -f cacerts.yaml
  4. Edit the openstack_control_plane.yaml custom resource (CR) file and add your bundle as the parameter for caBundleSecretName: 
    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: myctlplane
spec:
  tls:
    podLevel:
      enabled: true
    caBundleSecretName: cacerts
  5. Apply the control plane changes: 
    $ oc apply -f openstack_control_plane.yaml
  6. Determine if TLS is enabled on each node set, by running the following command, which returns true if TLS is enabled on the specified node set: 
    $ oc get openstackdataplanenodeset <node_set_name> -n <namespace> -o json | jq .items[0].spec.tlsEnabled

    where:

    <node_set_name>
    Specifies the name of the OpenStackDataPlaneNodeSet CR that the node belongs to.
    <namespace>
    Specifies the namespace of the required Red Hat OpenStack Services on OpenShift (RHOSO) environment, for example, openstack.
  7. If TLS is not enabled, you must enable it:
    1. Open the OpenStackDataPlaneNodeSet CR file for each node on the data plane, and enable TLS in each: 
      apiVersion: dataplane.openstack.org/v1beta1
kind: OpenStackDataPlaneNodeSet
metadata:
  name: <node_set_name>
  namespace: openstack
spec:
  tlsEnabled: true
    2. Save the updated OpenStackDataPlaneNodeSet CR files and apply the updates: 
      $ oc apply -f openstack_data_plane.yaml -n <namespace>
  8. Create a separate file on your workstation to define the OpenStackDataPlaneDeployment CR: 
    apiVersion: dataplane.openstack.org/v1beta1
kind: OpenStackDataPlaneDeployment
metadata:
  name: <node_set_deployment_name>

    where:

    <node_set_deployment_name>
    Specifies the name of the OpenStackDataPlaneDeployment CR. This name must be unique, must consist of lower case alphanumeric characters, - (hyphen) or . (period), and must start and end with an alphanumeric character.
  9. Add the OpenStackDataPlaneNodeSet CRs to the OpenStackDataPlaneDeployment CR file: 
    spec:
  ...
  nodeSets:
    - <node_set_name>
  10. Save the OpenStackDataPlaneDeployment CR deployment file.
  11. Deploy the modified OpenStackDataPlaneNodeSet CRs: 
    $ oc create -f openstack_data_plane_deploy.yaml -n <namespace>

    You can view the Ansible logs while the deployment executes:

    $ oc get pod -l app=openstackansibleee -w
$ oc logs -l app=openstackansibleee -f --max-log-requests 10

    If the oc logs command returns an error similar to the following error, increase the --max-log-requests value:

    error: you are attempting to follow 19 log streams, but maximum allowed concurrency is 10, use --max-log-requests to increase the limit
  12. Verify that the modified OpenStackDataPlaneNodeSet CRs are deployed: 
    $ oc get openstackdataplanedeployment -n <namespace>
NAME             	STATUS   MESSAGE
openstack-data-plane   True     Setup Complete


$ oc get openstackdataplanenodeset -n <namespace>
NAME             	STATUS   MESSAGE
openstack-data-plane   True     NodeSet Ready

    For information about the meaning of the returned status, see Data plane conditions and states .

    If the status indicates that the data plane has not been deployed, then troubleshoot the deployment. For information, see Troubleshoot data plane creation and deployment .

Apply custom certificates to public service endpoints
Copy link

Apply signed certificates from your own certificate authority (CA) to public service endpoints to replace automatically generated route certificates and meet your organization’s security requirements.

Before you begin
Copy link

  • You have a list of each of the public services for which to apply your custom service certificates. You can get this list using the oc route list -n openstack command. Use this information for the number of certificates you must create, the DNS names for those certificates, and finding the relevant services to edit in the openstack_control_plane.yaml custom resource (CR).
  • You have a service certificate for the public services.

Procedure
Copy link

  1. Create a manifest file called cacerts.yaml that includes all CA certificates. Include all certificates in chains of trust if applicable: 
    apiVersion: v1
kind: Secret
metadata:
  name: cacerts
  namespace: openstack
type: Opaque
data:
  myBundleExample: <cat mybundle.pem | base64 -w0>
  CACertExample: <cat cacert.pem | base64 -w0>

    where:

    mybundle.pem
    Specifies the name of your certificate or certificate bundle. The results are pasted as the value of the myBundleExample field.
    cacert.pem
    Specifies the name of your CA certificate.
  2. Create the secret from the manifest file: 
    $ oc apply -f cacerts.yaml
  3. Create a manifest file for each secret named api_certificate_<service>_secret.yaml: 
    apiVersion: v1
kind: Secret
metadata:
  name: api_certificate_<service>_secret
  namespace: openstack
type: kubernetes.io/tls
data:
  tls.crt: <cat tlscrt.pem | base64 -w0>
  tls.key: <cat tlskey.pem | base64 -w0>
  ca.crt: <cat cacrt.pem | base64 -w0>

    where:

    <service>
    Specifies the name of the service that this secret is for.
    tlscrt.pem
    Specifies the name of your signed certificate.
    tlskey.pem
    Specifies the name of your private key.
    cacrt.pem
    Specifies the name of your CA certificate.
  4. Create the secret 
    $ oc apply -f api_certificate_<service>_secret.yaml
  5. Edit the openstack_control_plane.yaml custom resource and add your bundle as the parameter for caBundleSecretName: 
    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: myctlplane
spec:
  tls:
    podLevel:
      enabled: true
    caBundleSecretName: cacerts
  6. Apply the secret service certificates to each of the public services under the apiOverride field. For example enter the following for the Identity service (keystone): 
    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: myctlplane
  namespace: openstack
spec:
  ...
  keystone:
    apiOverride:
      tls:
        secretName: api_certificate_keystone_secret

    The edits for the Compute service (nova) and noVNCProxy appear as the following:

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: myctlplane
  namespace: openstack
spec:
...
  nova:
    apiOverride:
      tls:
        secretName: api_certificate_nova_secret
      route: {}
    cellOverride:
      cell1:
        noVNCProxy:
          tls:
            secretName: api_certificate_novavncproxy_secret

    The edits for the Image service (Glance) appear as the following:

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: myctlplane
  namespace: openstack
spec:
...
  glance:
    apiOverrides:
      defaultAPI1:
        tls:
          secretName: api_certificate_glance_secret
        route: {}
      defaultAPI2:
        tls:
          secretName: api_certificate_glance_secret
        route: {}
    template:
      glanceAPIs:
        defaultAPI1:
          replicas: 3
    ...
        defaultAPI2:
          replicas: 1
    ...
  7. Apply the control plane changes 
    $ oc apply -f openstack_control_plane.yaml

Update the control plane with a single custom certificate
Copy link

Apply a single shared certificate from your own certificate authority (CA) to all public service endpoints to simplify certificate management and replace the automatically generated route certificates.

Before you begin
Copy link

  • You have a list of each of the public services for which to apply your custom service certificate. You can get this list by using the oc route list -n openstack command. Use this information for the DNS names for the certificate, and for finding the relevant services to edit in the openstack_control_plane.yaml custom resource (CR).

Procedure
Copy link

  1. Create a signed certificate that includes the hostname for every service in the alt_names section: 
    [alt_names]
DNS.1 = barbican-public-openstack.apps.ocp.openstack.lab
DNS.2 = cinder-public-openstack.apps.ocp.openstack.lab
DNS.3 = glance-default-public-openstack.apps.ocp.openstack.lab
DNS.4 = horizon-openstack.apps.ocp.openstack.lab
DNS.5 = keystone-public-openstack.apps.ocp.openstack.lab
DNS.6 = manila-public-openstack.apps.ocp.openstack.lab
DNS.7 = neutron-public-openstack.apps.ocp.openstack.lab
DNS.8 = nova-novncproxy-cell1-public-openstack.apps.ocp.openstack.lab
DNS.9 = nova-public-openstack.apps.ocp.openstack.lab
DNS.10 = placement-public-openstack.apps.ocp.openstack.lab
  2. Create a manifest file called cacerts.yaml that includes all CA certificates. Include all certificates in chains of trust if applicable: 
    apiVersion: v1
kind: Secret
metadata:
  name: cacerts
  namespace: openstack
type: Opaque
data:
  myBundleExample: <cat mybundle.pem | base64 -w0>
  CACertExample: <cat cacert.pem | base64 -w0>

    where:

    mybundle.pem
    Specifies the name of your certificate or certificate bundle. The results are pasted as the value of the myBundleExample field.
    cacert.pem
    Specifies the name of your CA certificate.
  3. Create the secret from the manifest file: 
    $ oc apply -f cacerts.yaml
  4. Create a manifest file for a secret named certificate-secret.yaml: 
    apiVersion: v1
kind: Secret
metadata:
  name: certificate-secret
  namespace: openstack
type: kubernetes.io/tls
data:
  tls.crt: <cat tlscrt.pem | base64 -w0>
  tls.key: <cat tlskey.pem | base64 -w0>
  ca.crt: <cat cacrt.pem | base64 -w0>

    where:

    tlscrt.pem
    Specifies the name of your signed certificate.
    tlskey.pem
    Specifies the name of your private key.
    cacrt.pem
    Specifies the name of your CA certificate.
  5. Create the secret 
    $ oc apply -f certificate-secret.yaml
  6. Edit the openstack_control_plane.yaml custom resource and add your bundle as the parameter for caBundleSecretName: 
    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: myctlplane
spec:
  tls:
    podLevel:
      enabled: true
    caBundleSecretName: cacerts
  7. Apply the secret service certificates to each of the public services under the apiOverride field. For example, enter the following for the Identity service (keystone): 
    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: myctlplane
  namespace: openstack
spec:
  ...
  keystone:
    apiOverride:
      tls:
        secretName: certificate-secret

    The edits for the Compute service (nova) and noVNCProxy appear as the following:

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: myctlplane
  namespace: openstack
spec:
...
  nova:
    apiOverride:
      tls:
        secretName: certificate-secret
      route: {}
    cellOverride:
      cell1:
        noVNCProxy:
          tls:
            secretName: certificate-secret

    The edits for the Image service (Glance) appear as the following:

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: myctlplane
  namespace: openstack
spec:
...
  glance:
    apiOverrides:
      defaultAPI1:
        tls:
          secretName: api_certificate_glance_secret
        route: {}
      defaultAPI2:
        tls:
          secretName: api_certificate_glance_secret
        route: {}
    template:
      glanceAPIs:
        defaultAPI1:
          replicas: 3
    ...
        defaultAPI2:
          replicas: 1
    ...
  8. Apply the control plane changes: 
    $ oc apply -f openstack_control_plane.yaml

Use your CA certificates on remote clients
Copy link

Configure remote clients to trust the certificate authority (CA) used by your deployment so that OpenStack CLI commands authenticate securely without SSL verification errors.

Before you begin
Copy link

  • You have deployed RHOSO with default certificates, or have used custom certificates that are not signed by a public certificate authority.

Procedure
Copy link

  1. Log on to OpenShift with global administrative permissions.
  2. Extract the CA certificate ca.crt for the public endpoints from the rootca-public secret. 
    $ oc get secret rootca-public -o json | jq -r '.data."ca.crt"' | base64 -d > ca.crt
  3. Transfer the ca.crt file to the client that accesses the OpenStack API.
  4. Update your authentication file with the path to ca.crt.
    1. If you use a clouds.yml authentication file, add the cacert parameter: 
      clouds:
    secure:
        cacert: </path/to/ca.crt>

      where:

      </path/to/ca.crt>
      Specifies the absolute path and name of the CA cert on your system.
    2. If you use a resource credentials file, update the file with the exported OS_CACERT variable: 
      $ export OS_CACERT=</path/to/ca.crt>

Private key algorithm and size
Copy link

In Red Hat OpenStack Platform (RHOSP) 17.1, the CertificateKeySize heat parameter controlled private key sizes in your deployment. You can configure the key algorithm and size cert-manager Certificate resource.

When creating custom Issuers, you specify the private key parameters in the Certificate CR:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: rootca-ingress-custom
spec:
  isCA: true
  commonName: rootca-ingress-custom
  duration: 87600h0m0s
  privateKey:
    algorithm: RSA
    size: 3072
  issuerRef:
    name: selfsigned-issuer
    kind: Issuer
  secretName: rootca-ingress-custom

The following table outlines the supported algorithms and valid sizes:

Table 1. Supported algorithms and valid sizes
Algorithm Valid key sizes Default

RSA

2048, 3072, 4096, 8192

2048 (NIST minimum)

ECDSA

256 (P-256), 384 (P-384), 521 (P-521)

256

Ed25519

Fixed with no size parameter

N/A
Important
The default autogenerated certificates use RSA 3072-bit keys. If your security policy requires 4096-bit RSA or ECDSA P-384, you must create custom Issuers and Certificate CRs with the required key parameters. The default self-signed Issuer does not expose a key size override.

CAs for public endpoints
Copy link

If your OpenStack API endpoints are accessible from the public internet, use certificates signed by a publicly trusted certificate authority (CA) such as Let’s Encrypt, DigiCert, or your enterprise PKI that chains to a public root.

cert-manager supports ACME Issuers for automated certificate provisioning from Let’s Encrypt or compatible providers.

For internal-only clouds such as private data centers, a self-signed or internal CA is sufficient, when you distribute the CA certificate to all clients.

Verify TLS on public and internal endpoints
Copy link

In Red Hat OpenStack Platform (RHOSP) 17.1, you used the cipherscan tool to scan HAProxy endpoints. You do not manage HAProxy. Use standard TLS inspection tools against the Red Hat OpenShift Container Platform (RHOCP) Route endpoints.

Procedure
Copy link

  1. Check the public endpoint TLS, use openssl s_client or nmap --script ssl-enum-ciphers against the public Route URL: 
    $ openssl s_client -connect keystone-public-openstack.apps.example.com:443 \
    -servername keystone-public-openstack.apps.example.com </dev/null 2>/dev/null \
    | openssl x509 -noout -subject -issuer -dates
  2. List the supported cipher suites and protocol versions: 
    $ nmap --script ssl-enum-ciphers -p 443 \
    keystone-public-openstack.apps.example.com
  3. Check the internal endpoint TLS that are on isolated networks and are not reachable from outside the cluster, access the pod in the openstack namespace: 
    $ oc rsh -n openstack openstackclient
$ openssl s_client -connect keystone-internal.openstack.svc:5000 </dev/null 2>/dev/null \
    | openssl x509 -noout -subject -issuer -dates
  4. List all the certificates that are managed by cert-manager and audit the certificates in the openstack namespace: 
    $ oc get certificates -n openstack -o wide

    Certificates with a Ready condition of True are valid and will be renewed automatically. You must investigate certificates with a Ready condition of False.

    Important
    TLS 1.0 and TLS 1.1 are deprecated. RHOSO 18.0 services use the Go TLS stack, which defaults to TLS 1.2 as the minimum. To enforce TLS 1.3 on public endpoints, configure the RHOCP IngressController with tlsSecurityProfile.type: Custom and set minTLSVersion: VersionTLS13.

Memcached TLS
Copy link

memcached runs as a pod in the openstack namespace, and pod-level TLS covers memcached connections automatically if you set podLevel.enabled: true in the TLS configuration.

RHOSP 17.1 to RHOSO 18.0 TLS comparison
Copy link

Review the TLS differences between Red Hat OpenStack Platform (RHOSP) 17.1 and Red Hat OpenStack Services on OpenShift (RHOSO) 18.0.

Table 2. Comparisons between TLS in RHOSP 17.1 and RHOSO 18.0
RHOSP 17.1 mechanism RHOSO 18.0 equivalent Notes

FreeIPA IdM as certificate authority.

cert-manager Operator with self-signed or custom Issuers.

No IdM server needed and FreeIPA CA can be imported for adoption.

certmonger certificate lifecycle.

cert-manager which has automatic issuance, renewal, and rotation.

No manual keytab or certmonger commands.

tripleo-ipa or novajoin Ansible-based TLS-e.

OpenStack Operator and cert-manager configured in CR.

No Ansible playbooks, and TLS-e is default and mandatory.

enable-internal-tls.yaml or tls-everywhere-endpoints-dns.yaml.

tls.podLevel.enabled: true in OpenStackControlPlane CR.

Single configuration field replaces multiple heat environment files.

CertificateKeySize or RedisCertificateKeySize heat parameters.

privateKey.algorithm and privateKey.size`on `Certificate CR.

Per-certificate control defaults to RSA 3072.

HAProxy ssl_options Hiera with ExtraConfig.

RHOCP IngressController CR tlsSecurityProfile.

Cipher suites and the minimum TLS version is set on the ingress controller.

cipherscan against HAProxy.

openssl s_client or nmap against RHOCP Route URLs.

Scan the Route endpoint, not a controller node.

MemcachedTLS: true and MemcachedPort: 11212 heat parameters.

Automatic on pod-level TLS with no separate configuration.

Memcached runs as a pod and TLS is applied by cert-manager.

IdM server replacement or replica failover.

Update Issuer CR and Secret with new CA which the operator reconciles.

No IPA default.conf or keytab files to edit.

undercloud.conf TLS parameters.

N/A undercloud is absent.

All TLS config is in the OpenStackControlPlane CR.