×

You can install OKD on OpenStack. OKD version 4.22 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.

For more information about installer-provisioned and user-provisioned installation processes, see "Installation process".

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. For other customization options, see "Postinstallation cluster tasks".

  • 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 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.

Scanning OpenStack endpoints for legacy HTTPS certificates

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

OKD does not check the underlying OpenStack infrastructure for legacy certificates before installation or updates. Use the provided script to check for these certificates yourself. Failing to update legacy certificates before installing or updating a cluster might result in issues for your cluster.

Prerequisites
Procedure
  1. Save the following script to your machine:

    #!/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[] | select(.interface=="public") | [$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.

    You must replace all legacy HTTPS certificates before you install OKD 4.10 or update a cluster to that version. Legacy certificates will be rejected with the following message:

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

Scanning OpenStack endpoints for legacy HTTPS certificates manually

Starting in OKD 4.10, HTTPS certificates require subject alternative name (SAN) fields. If you do not have access to the prerequisite tools that are listed in "Scanning OpenStack endpoints for legacy HTTPS certificates", you can perform certain steps.

These steps scan each HTTPS endpoint in a OpenStack catalog for legacy certificates that only contain the CommonName field.

OKD does not check the underlying OpenStack infrastructure for legacy certificates before installation or updates. Use the procedure steps to check for these certificates yourself. Failing to update legacy certificates before installing or updating a cluster might result in issues for your cluster.

Procedure
  1. On a command line, run the following command to view the URL of OpenStack public endpoints:

    $ openstack catalog list

    Record the URL for each HTTPS endpoint that the command returns.

  2. For each public endpoint, note the host and the port.

    Determine the host of an endpoint by removing the scheme, the port, and the path.

  3. For each endpoint, run the following commands to extract the SAN field of the certificate:

    1. Set a host variable:

      $ host=<host_name>
    2. Set a port variable:

      $ port=<port_number>

      If the URL of the endpoint does not have a port, use the value 443.

    3. Retrieve the SAN field of the certificate:

      $ openssl s_client -showcerts -servername "$host" -connect "$host:$port" </dev/null 2>/dev/null \
          | openssl x509 -noout -ext subjectAltName
      Example output
      X509v3 Subject Alternative Name:
          DNS:your.host.example.net

      For each endpoint, look for output that resembles the previous example. If there is no output for an endpoint, the certificate of that endpoint is invalid and must be re-issued.

      You must replace all legacy HTTPS certificates before you install OKD 4.10 or update a cluster to that version. Legacy certificates are rejected with the following message:

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