Preparing to install on OpenStack

You can install OKD on OpenStack. OKD version 4.11 supports OpenStack Train.

Prerequisites

• You reviewed details about the OKD installation and update processes.

• You read the documentation on selecting a cluster installation method and preparing it for users.

Choosing a method to install OKD on OpenStack

You can install OKD on installer-provisioned or user-provisioned infrastructure. The default installation type uses installer-provisioned infrastructure, where the installation program provisions the underlying infrastructure for the cluster. You can also install OKD on infrastructure that you provision. If you do not use infrastructure that the installation program provisions, you must manage and maintain the cluster resources yourself.

See Installation process for more information about installer-provisioned and user-provisioned installation processes.

Installing a cluster on installer-provisioned infrastructure

You can install a cluster on OpenStack infrastructure that is provisioned by the OKD installation program, by using one of the following methods:

• Installing a cluster on OpenStack with customizations: You can install a customized cluster on OpenStack. The installation program allows for some customization to be applied at the installation stage. Many other customization options are available post-installation.

• Installing a cluster on OpenStack with Kuryr: You can install a customized OKD cluster on OpenStack that uses Kuryr SDN. Kuryr and OKD integration is primarily designed for OKD clusters running on OpenStack VMs. Kuryr improves the network performance by plugging OKD pods into OpenStack SDN. In addition, it provides interconnectivity between pods and OpenStack virtual instances.

• Installing a cluster on OpenStack in a restricted network: You can install OKD on OpenStack in a restricted or disconnected network by creating an internal mirror of the installation release content. You can use this method to install a cluster that does not require an active internet connection to obtain the software components. You can also use this installation method to ensure that your clusters only use container images that satisfy your organizational controls on external content.

Installing a cluster on user-provisioned infrastructure

You can install a cluster on OpenStack infrastructure that you provision, by using one of the following methods:

• Installing a cluster on OpenStack on your own infrastructure: You can install OKD on user-provisioned OpenStack infrastructure. By using this installation method, you can integrate your cluster with existing infrastructure and modifications. For installations on user-provisioned infrastructure, you must create all OpenStack resources, like Nova servers, Neutron ports, and security groups. You can use the provided Ansible playbooks to assist with the deployment process.

• Installing a cluster on OpenStack with Kuryr on your own infrastructure: You can install OKD on user-provisioned OpenStack infrastructure that uses Kuryr SDN.

Scanning OpenStack endpoints for legacy HTTPS certificates

Beginning with OKD 4.10, HTTPS certificates must contain subject alternative name (SAN) fields. Run the following script to scan each HTTPS endpoint in a OpenStack catalog for legacy certificates that only contain the CommonName field.

Prerequisites

• On the machine where you run the script, have the following software:

  • Bash version 4.0 or greater

  • grep

  • OpenStack client

  • jq

  • OpenSSL version 1.1.1l or greater

• Populate the machine with OpenStack credentials for the target cloud.

Procedure

1. Save the following script to your machine:

   Details

   #!/usr/bin/env bash
   set -Eeuo pipefail
   declare catalog san
   catalog="$(mktemp)"
   san="$(mktemp)"
   readonly catalog san
   declare invalid=0
   openstack catalog list --format json --column Name --column Endpoints \
       | jq -r '.[] | .Name as $name | .Endpoints[] | [$name, .interface, .url] | join(" ")' \
       | sort \
       > "$catalog"
   while read -r name interface url; do
       # Ignore HTTP
       if [[ ${url#"http://"} != "$url" ]]; then
           continue
       fi
       # Remove the schema from the URL
       noschema=${url#"https://"}
       # If the schema was not HTTPS, error
       if [[ noschema == "$url" ]]; then
           echo "ERROR (unknown schema): $name $interface $url"
           exit 2
       fi
       # Remove the path and only keep host and port
       noschema="${noschema%%/*}"
       host="${noschema%%:*}"
       port="${noschema##*:}"
       # Add the port if was implicit
       if [[ "$port" == "$host" ]]; then
           port='443'
       fi
       # Get the SAN fields
       openssl s_client -showcerts -servername "$host" -connect "$host:$port" </dev/null 2>/dev/null \
           | openssl x509 -noout -ext subjectAltName \
           > "$san"
       # openssl returns the empty string if no SAN is found.
       # If a SAN is found, openssl is expected to return something like:
       #
       #    X509v3 Subject Alternative Name:
       #        DNS:standalone, DNS:osp1, IP Address:192.168.2.1, IP Address:10.254.1.2
       if [[ "$(grep -c "Subject Alternative Name" "$san" || true)" -gt 0 ]]; then
           echo "PASS: $name $interface $url"
       else
           invalid=$((invalid+1))
           echo "INVALID: $name $interface $url"
       fi
   done < "$catalog"
   # clean up temporary files
   rm "$catalog" "$san"
   if [[ $invalid -gt 0 ]]; then
       echo "${invalid} legacy certificates were detected. Update your certificates to include a SAN field."
       exit 1
   else
       echo "All HTTPS certificates for this cloud are valid."
   fi

2. Run the script.

3. Replace any certificates that the script reports as INVALID with certificates that contain SAN fields.

x509: certificate relies on legacy Common Name field, use SANs instead