Customizing for a more secure cloud

Additional steps are required to configure your topology to make it more safe and meet more stringent rules that might be required in your IT environment.

About this task

The following information provides details about supported options.

Table 1. Summary of support details
Support options Details
Supported hypervisor types? All, except Hyper-V
Support for post-deployment customization? Yes
Supported topologies? All
To elevate the security level, you need to ensure that OpenStack components are configured to communicate with HTTPs. Then, you can set the related attributes in the environment file and deploy the topology.
Note: Most attributes are in the override_attributes section of your environment, while some attributes might be in the default_attributes section, depending on your topology.

Procedure

  1. Create or configure the certificates. For a production environment, obtain the certificates from a trusted CA agency. You can also use the following steps to create the certificates for a non-production environment.
    1. Run the following commands:
      Note: By default, OpenSSL has stored related certificate files in "/etc/ssl/certs".
      $ cd /etc/ssl/certs
      $ openssl genrsa -out server.key 2048
      $ openssl req -new -key server.key -out server.csr
      Note: This command requests that you enter some information. When you are asked for the Common Name, enter the public IP address of the proxy node. In IBM Cloud Manager with OpenStack, the proxy node is typically the controller node, though not always.
      $ openssl x509 -req -sha256 -days 3650 -in server.csr -signkey server.key -out server.crt
    2. Set the following values in the environment file:
      • ibm-openstack.apache-proxy.certfile = /PATH/TO/server.crt
      • ibm-openstack.apache-proxy.certkeyfile = /PATH/TO/server.key
      For example, the updated section of the environment file might look similar to the following:
       "apache-proxy": {
              "enabled": false,
              "certfile": "/etc/ssl/certs/server.crt",
              "certkeyfile": "/etc/ssl/certs/server.key"
            },
    3. Optional: Copy this directory and the certificates to the same directory of the compute nodes. This step is not needed for the Minimal topology.
  2. Complete the Apache proxy setup for each component API service. Set the following values in the environment file:
    • ibm-openstack.apache-proxy.enabled = true. This value is the switch to enable the proxy solution to protect API services and control the security parameters. The default value is false. By setting this value to true, the system attempts to put an Apache proxy outside of each OpenStack API service.
    • openstack.endpoints.host = PUBLIC_IP_ADDR of the controller node. The default value in the environment file is 127.0.0.1.
    • openstack.endpoints.bind-host = PUBLIC_IP_ADDR of the controller node.
    • openstack.endpoints.SERVICE.port = PROXY_PORT_FOR_EACH_SERVICE. This value is the port that each API service listens to, where SERVICE is the OpenStack API services such as identity-admin/identity-api/network-api/compute-api. The default port number for each API service and the related proxy is the same. For example, the proxy for nova-api and the nova-api service itself both listen to the same port number, 8774. You can set different port numbers by changing these attributes. An exception is that the port number for the keystone proxy must not be modified.
  3. Configure how you want the certificate to be verified. You can specify an insecure method or a certificate verification method (options A and B below). The insecure method explicitly allows the client to perform insecure SSL (https) requests, meaning the certificate from the server is not verified against any certificate authorities. Alternatively, the certificate verification method requires the certificates to be verified.
    1. (Option A) For an insecure method of verification, set the insecure values to true. For example, the following values must be set to true:
      • openstack.network.api.auth.insecure = true
      • openstack.network.nova.insecure = true
      • openstack.compute.network.neutron.insecure = true
      • openstack.compute.api.auth.insecure = true
      • openstack.compute.image.glance_insecure = true
      • openstack.compute.block-storage.cinder_insecure = true
      • openstack.block-storage.api.auth.insecure = true
      • openstack.block-storage.image.glance_api_insecure = true
      • openstack.orchestration.api.auth.insecure = true
      • openstack.orchestration.clients.insecure = true
      • openstack.telemetry.api.auth.insecure = true
      • openstack.telemetry.service-credentials.insecure = true
      • openstack.image.api.block-storage.cinder_api_insecure = true
      • openstack.image.api.auth.insecure = true
      • openstack.image.registry.auth.insecure = true
      • openstack.dashboard.ssl_no_verify = "True"
      • ibm-openstack.powervc-driver.http.insecure = true
    2. (Option B) For the certificate verification method, set all of the CA file values to be the certificate file of the certificate authority. See the following examples:
      • openstack.image.registry.auth.cafile = /PATH/TO/server.crt
      • openstack.image.api.block-storage.cinder_ca_certificates_file = /PATH/TO/server.crt
      • openstack.network.api.auth.cafile = /PATH/TO/server.crt
      • openstack.network.nova.cafile = /PATH/TO/server.crt
      • openstack.compute.network.neutron.cafile = /PATH/TO/server.crt
      • openstack.compute.api.auth.cafile = /PATH/TO/server.crt
      • openstack.compute.image.ssl.ca_file = /PATH/TO/server.crt
      • openstack.compute.block-storage.cinder_cafile = /PATH/TO/server.crt
      • openstack.block-storage.api.auth.cafile = /PATH/TO/server.crt
      • openstack.orchestration.api.auth.cafile = /PATH/TO/server.crt
      • openstack.orchestration.clients.ca_file = /PATH/TO/server.crt
      • openstack.telemetry.api.auth.cafile = /PATH/TO/server.crt
      • openstack.telemetry.service-credentials.cafile = /PATH/TO/server.crt
      • openstack.image.api.auth.cafile = /PATH/TO/server.crt
      • openstack.dashboard.ssl_cacert = /PATH/TO/server.crt
      • openstack.dashboard.ssl_no_verify = "False"
      • openstack.block-storage.image.glance_ca_certificates_file = /PATH/TO/server.crt
      • ibm-openstack.powervc-driver.http.insecure = false
      • ibm-openstack.powervc-driver.http.cacert = /PATH/TO/server.crt
      • openstack.image.ssl.cert_required = true
  4. Set the related attributes in the environment file.
    1. Set all of the "hash_algorithm" or "hash_algorithms" in the environment file to sha256. The default value for hash_algorithm is md5. For security, a recommended algorithm is sha256. See the following examples:
      • openstack.identity.token.hash_algorithm = sha256
      • openstack.image.api.auth.hash_algorithms = sha256
      To retrieve all the openstack.xxx.xxx.hash_algorithm[s] attribute names, see the override_attributes section in /opt/ibm/cmwo/chef-repo/environments/example-ibm-os-allinone.rb, and ensure the attribute names match the preceding examples.
    2. If auth_token is configured to use memcached (in other words, memcached_servers and memcache_security_strategy are set) and the deployer wants to protect the data, set the memcache_secret_key to a value that is at least 112 bits. You can generate a random 112+ bit string by reading from the following path: /dev/random: head -c 15 /dev/random | base64. For example, memcached_servers = localhost:11211 and memcache_security_strategy are set to either MAC or ENCRYPT.
    3. Set the openstack.dashboard.ssl.protocol and openstack.dashboard.ssl.ciphers parameters.
      The default value for openstack.dashboard.ssl.protocol is All -SSLv2 -SSLv3. For security, the recommended SSL protocol is TLSv1.2. By default, the value for the openstack.dashboard.ssl.ciphers parameter does not set. It uses the system default cipher suites. You could consider setting this value to TLSv1.2 to avoid some weak cipher suites attack.

      Add openstack.dashboard.ssl section with protocol and ciphers parameters if it does not exist in the environment file.

      openstack.dashboard.ssl.protocol = TLSv1.2
      openstack.dashboard.ssl.ciphers = TLSv1.2
  5. Before you enable the proxy, stop all OpenStack services and httpd services on the IBM Cloud Manager with OpenStack controller node.
    For example, initiate an action to stop all OpenStack services and httpd services:
    service httpd stop
    
    Stop OpenStack related services, like /etc/init.d/openstack-* and /etc/init.d/neutron-* as well.
    Tip: For the proxy environment, it is suggested to have the Chef server and controller node on different nodes. Redeployment from IBM Cloud Manager with OpenStack without proxy to a IBM Cloud Manager with OpenStack with proxy is supported only when the Chef-server node and controller node are on different nodes
  6. When complete, return to the relevant topology deployment or update process and complete the remaining steps.

What to do next

You can use the following examples after the installation to verify if the proxy connection works properly.
  • Insecure method: add --insecure in the command. For example:
    • nova --insecure list
    • nova --insecure image-list
  • Certificate verification method: the certificates need to be provided. For example:
    • neutron --os-cacert /var/lib/neutron/keystone-signing/cacert.pem agent-list
    • heat --os-cacert /var/cache/heat/cacert.pem stack-list
Note: Those services like message queue (RabbitMQ), database (DB2®), IBM Cloud Manager - Deployer, and the new IBM Cloud Manager - Self Service are already protected with TLS1.2, by default, since version 4.3.