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
- 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.
- 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
- 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"
},
- Optional: Copy this directory and the certificates
to the same directory of the compute nodes. This step is not needed
for the Minimal topology.
- 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.
- 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.
- (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
- (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
- Set the related attributes in the environment file.
- 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.
- 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.
- 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
- 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
- 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.