Performing security operations

Procedure

1. Set the default RHOSO namespace:

   $ oc project <namespace>

   • Replace <namespace> with the namespace of the required RHOSO environment, for example, openstack.

2. Edit your OpenStackControlPlane CR on your workstation:

   $ oc edit openstackcontrolplane <name>

   • Replace <name> with the name of your YAML OpenStackControlPlane CR, which you can use the following command to retrieve: oc get openstackcontrolplane.

3. Locate the databaseAccount: parameter for the deployed OpenStack service in this CR file.

   Locate this databaseAccount: parameter for the OpenStack Identity service (keystone) in the OpenStackControlPlane CR:

   ...
     keystone:
      ...
      template:
        ...
        databaseAccount: keystone

4. Change the name of the existing database account, in this example keystone, to a new name.

   Note

   If this new name contains multiple words, separate each word with a dash, for example: my-new-keystone-database-account, do not use the _ character.

5. Save and close the editor to apply this change.

6. Wait for the deployment of the control plane to reach the Ready status:

   $ oc wait openstackcontrolplane <name> --for=condition=Ready --timeout=600s

7. You can use the following command to verify that the new database account has been successfully created for your OpenStack service:

   $ oc get mariadbaccount

   In this example, the command output shows the new database account called my-new-keystone-database-account in the list of database accounts.

   If the old database account for this OpenStack service still appears in this list, you can use the following command to delete this account: oc delete mariadbaccounts <database-account-name> by replacing <database-account-name> with the name of the old database account, which in this example is the keystone database account.

Procedure

1. Set the default RHOSO namespace:

   $ oc project <namespace>

   • Replace <namespace> with the namespace of the required RHOSO environment, for example, openstack.

2. Create a new secret CR YAML file containing the new password for the root database account of the openstack database. In this example this file is called: new-password-secret.yaml.

   Note

   Always use the stringData: property when creating your secrets because you can specify the secret data as unencoded, plain-text strings, which are automatically encoded to base64.

   $ cat > new-password-secret.yaml << 'EOF'
   apiVersion: v1
   kind: Secret
   metadata:
     name: <new-secret-name>
     namespace: openstack
   type: Opaque
   stringData:
     DatabasePassword: "<your-new-password>"
   EOF

   • Replace <new-secret-name> with the new secret name, for example, openstack-mariadb-root-db-secret-2025-02.

     Note

     Separate each word in the secret name with a dash.

   • Replace <your-new-password> with the new password that you must generate, according to your organization’s security standards.

     Tip

     Use strong passwords with a minimum of 32 characters that use mixed character types.

3. Apply the new secret CR:

   $ oc apply -f new-password-secret.yaml

4. Edit the openstack-mariadb-root MariaDBAccount CR:

   $ oc edit mariadbaccount openstack-mariadb-root

5. Specify the name of the new secret you created in step 1:

   apiVersion: mariadb.openstack.org/v1beta1
   kind: MariaDBAccount
   metadata:
     name: openstack-mariadb-root
     namespace: openstack
   spec:
     userName: root
     accountType: System
     secret: <new-secret-name>

   • Replace <new-secret-name> with the new secret name that you have created in step 1, which in this example is: openstack-mariadb-root-db-secret-2025-02.
6. Save and close this editor to apply this change.

7. Verify that this password rotation process is successful, by using the following command, which in this example retrieves the current password of the root database account for the openstack database:

   $ oc get galera <galera-database-cr-name> -o jsonpath='{.status.rootDatabaseSecret}'

   • Replace <galera-database-cr-name> with the name of the Galera CR that manages the required database this is openstack in this example.

     This command retrieves the old secret name, which in this example is: openstack-mariadb-root-db-secret until the password rotation process of the root database account is complete. When the password is successfully rotated this command retrieves the new secret name, which in this example is: openstack-mariadb-root-db-secret-2025-02.

8. You can safely delete the old secret for this root database account after you have confirmed that the password is successfully rotated, by using the following command:

   $ oc delete secret <old-secret-name>

   • Replace <old-secret-name> with the name of the previous secret, which in this example is: openstack-mariadb-root-db-secret.

Procedure

1. Set the default RHOSO namespace:

   $ oc project <namespace>

   • Replace <namespace> with the namespace of the required RHOSO environment, for example, openstack.

2. Edit your OpenStackControlPlane CR on your workstation:

   $ oc edit openstackcontrolplane <name>

   • Replace <name> with the name of your YAML OpenStackControlPlane CR, which you can use the following command to retrieve: oc get openstackcontrolplane.

3. Add the user parameter to the spec.cinder.template.messagingBus section and provide the user name. In this example, this is cinder-user1:

   Note

   Do not specify the _ character when creating new names because this character is unsupported.

     spec:
      ...
       cinder:
         ...
         template:
           messagingBus:
             user: cinder-user1

4. Save and close the editor to apply this change.

5. Wait for the deployment of the control plane to reach the Ready status:

   $ oc wait openstackcontrolplane <name> --for=condition=Ready --timeout=600s

Procedure

1. Set the default RHOSO namespace:

   $ oc project <namespace>

   • Replace <namespace> with the namespace of the required RHOSO environment, for example, openstack.

2. Edit your OpenStackControlPlane CR on your workstation:

   $ oc edit openstackcontrolplane <name>

   • Replace <name> with the name of your YAML OpenStackControlPlane CR, which you can use the following command to retrieve: oc get openstackcontrolplane.

3. Update the user parameter of the spec.cinder.template.messagingBus section to specify the new user name. In this example, this is cinder-user2:

   Note

   Do not specify the _ character when creating new names because this character is unsupported.

1. Save and close the editor to apply this change.

2. Wait for the deployment of the control plane to reach the Ready status:

   $ oc wait openstackcontrolplane <name> --for=condition=Ready --timeout=600s

3. Optional: If this OpenStack service must update Compute nodes and external services in the data plane with the new RabbitMQ credentials, then you must:

   • Use the latest OpenStackDataPlaneDeployment CR YAML file to update and deploy the data plane, in this example, `openstack-edpm-deployment.yaml’:

     $ oc apply -f openstack-edpm-deployment.yaml

   • Wait for the deployment of the data plane to reach the Ready status:

     $ oc wait openstackdataplanedeployment <name> --for condition=Ready --timeout=1200s

   • Replace <name> with the name of your OpenStackDataPlaneDeployment CR that can be different to the YAML file name therefore use the following command to retrieve this name: oc get openstackdataplanedeployment, which in this example is edpm-deployment.

     In this example, because the Block Storage service (cinder) is not deployed in the data plane, these steps are not required.

4. Verify that both the old and new RabbitMQ users exist, which in this example is cinder-user1 and cinder-user2:

      $ oc get rabbitmquser
      NAME                                     CLUSTER    USERNAME    VHOST   STATUS   MESSAGE
      cinder-cinder-transport-cinder-user1-user      rabbitmq   cinder-user1      /       True     Setup complete
      cinder-cinder-transport-cinder-user2-user   rabbitmq   cinder-user2   /       True     Setup complete

   For a detailed explanation of these columns and their outputs, see Create RabbitMQ users for OpenStack services.

5. Delete the old RabbitMQ user, which in this example is cinder-user1:

   $ oc edit rabbitmquser <rabbitmq-user-name>

   • Replace <rabbitmq-user-name> with the fully qualified NAME of the old RabbitMQ user, specified by the oc get rabbitmquser command, which in this example is cinder-cinder-transport-cinder-user1-user.

   • Locate the metadata.finalizers section in this editor and delete the line containing rabbitmq.openstack.org/cleanup-blocked:

     …
        metadata:
        …
          finalizers
          …
          - rabbitmq.openstack.org/cleanup-blocked

   • Save and exit the editor after deleting the line containing rabbitmq.openstack.org/cleanup-blocked.
   • Wait for the old RabbitMQ user to be automatically deleted.

6. Verify that the old RabbitMQ user has been deleted:

      $ oc get rabbitmquser
      NAME                                     CLUSTER    USERNAME    VHOST   STATUS   MESSAGE
     cinder-cinder-transport-cinder-user2-user   rabbitmq   cinder-user2   /       True     Setup complete

   In this example, the old user cinder-cinder-transport-cinder-user1-user should no longer appear in the list.

Procedure

1. Use syntax similar to the following command to provide a user a role with a project scope:

   $ openstack role add --user user1 --user-domain Default --project demo --project-domain Default <role>

   • Replace <role> with either reader, member, or admin.

2. Use syntax similar to the following command to provide a user a role with a system scope:

   $ openstack role add --user user1 --user-domain Default --system all <role>

Procedure

1. Use the --os-cloud option with each command:

   $ openstack flavor list --os-cloud <cloud_name>

   • Replace <cloud_name> with the name of the cloud detailed in your clouds.yaml file.

2. Optional: If you access more than one cloud, create an environment variable for each cloud name in your bashrc file:

   `export OS_CLOUD1=<cloud_name>`

Procedure

1. Log in to the Dashboard as an admin user.
2. Select Identity > Users.
3. Click Create User.
4. Enter a user name, email, and preliminary password for the user.
5. Select a project from the Primary Project list.
6. Select a role for the user from the Role list. The default role is member.
7. Click Create User.

Procedure

1. Log in to the OpenStack Dashboard as an admin user.
2. Select Identity > Users.
3. In the Actions column, click Edit.
4. In the Update User window, you can update the User Name, Email, and Primary Project.
5. Click Update User.

Procedure

1. As an admin user in the Dashboard, select Identity > Users.
2. In the Actions column, click the arrow, and select Enable User or Disable User. In the Enabled column, the value then updates to either True or False.

Procedure

1. As an admin user in the OpenStack Dashboard, select Identity > Users.
2. Select the users you want to delete.
3. Click Delete Users. The Confirm Delete Users window is displayed.
4. Click Delete Users to confirm the action.

Procedure

1. List the available predefined roles:

   $ openstack role list

2. View details for a specific role:

   $ openstack role show <role>

   • Replace <role> with one of the listed roles, for example, member.

Procedure

1. Use syntax similar to the following command to provide a user a role with a project scope:

   $ openstack role add --user user1 --user-domain Default --project demo --project-domain Default <role>

   • Replace <role> with either reader, member, or admin.

2. Use syntax similar to the following command to provide a user a role with a system scope:

   $ openstack role add --user user1 --user-domain Default --system all <role>

Procedure

1. Connect to the openstackclient pod:

   $ oc rsh -n openstack openstackclient

2. View the roles currently in your environment. You can use the -f {csv,json,table,value,yaml} option to export these results:

   $ openstack role list -c Name -f value
   
   admin
   member
   reader

3. List all users that are members of a particular role. For example, to see all project-scoped users that have the admin role, run the following:

   $ openstack role assignment list --names --role admin

4. To audit system-scoped role assignments, use the --system all flag. For example, to see all users with system-scoped roles, run the following:

   $ openstack role assignment list --names --system all

   Note

   The system reader persona is useful for auditors or members of a support team who need read-only visibility across the entire deployment. For more information, see Secure role based access control in Red Hat OpenStack Services on OpenShift in Performing security operations.

Procedure

1. Create a group

   1. Log in to the dashboard as a user with administrative privileges.
   2. Select Identity > Groups.
   3. Click +Create Group.
   4. Enter a name and description for the group.
   5. Click Create Group.

2. Manage group membership

   1. Log in to the dashboard as a user with administrative privileges.
   2. Select Identity > Groups.
   3. Click Manage Members for the group that you want to edit.
   4. Use Add users to add a user to the group. If you want to remove a user, mark its checkbox and click Remove users.

Procedure

1. Log in to the Dashboard as a user with administrative privileges.
2. Select Identity > Projects.
3. Click Create Project.
4. On the Project Information tab, enter a name and description for the project. The Enabled check box is selected by default.
5. On the Project Members tab, add members to the project from the All Users list.
6. On the Quotas tab, specify resource limits for the project.
7. Click Create Project.

Procedure

1. Log in to the Dashboard as a user with administrative privileges.
2. Select Identity > Projects.
3. In the project Actions column, click the arrow, and click Edit Project.
4. In the Edit Project window, you can update a project to change its name or description, and enable or temporarily disable the project.
5. On the Project Members tab, add members to the project, or remove them as needed.
6. Click Save.

Procedure

1. Log in to the Dashboard as a user with administrative privileges.
2. Select Identity > Projects.
3. Select the project that you want to delete.
4. Click Delete Projects. The Confirm Delete Projects window is displayed.
5. Click Delete Projects to confirm the action.

Procedure

1. Log in to the Dashboard as a user with administrative privileges.
2. Select Identity > Projects.
3. In the project Actions column, click the arrow, and click Modify Quotas.
4. In the Quota tab, modify project quotas as needed.
5. Click Save.

Procedure

1. Log in to the Dashboard as a user with administrative privileges.
2. Select Identity > Projects.
3. In the project Actions column, click the arrow, and click Set as Active Project.
4. Alternatively, as a non-admin user, in the project Actions column, click Set as Active Project which becomes the default action in the column.

Procedure

1. Disable a domain using the --disable option:

   $ openstack domain set TestDomain --disable

2. Confirm that the domain has been disabled:

   $ openstack domain show TestDomain

   For example:

   +-------------+----------------------------------+
   | Field       | Value                            |
   +-------------+----------------------------------+
   | description |                                  |
   | enabled     | False                            |
   | id          | 3abefa6f32c14db9a9703bf5ce6863e1 |
   | name        | TestDomain                       |
   +-------------+----------------------------------+

3. Use the --enable option to re-enable the domain, if required:

   $ openstack domain set TestDomain --enable

Procedure

1. Create a test project, and test user accounts:

   1. Create a project called AppCreds:

      $ openstack project create AppCreds

   2. Create a user called AppCredsUser:

      $ openstack user create --project AppCreds --password-prompt AppCredsUser

   3. Grant AppCredsUser access to the member role for the AppCreds project:

      $ openstack role add --user AppCredsUser --project AppCreds member

2. Log in to the dashboard as AppCredsUser and create an Application Credential:

   Overview → Identity → Application Credentials → +Create Application Credential.

   Note

   Ensure that you download the clouds.yaml file contents, because you cannot access it again after you close the pop-up window titled Your Application Credential.

3. Create a file named /home/stack/.config/openstack/clouds.yaml using the CLI and paste the contents of the clouds.yaml file.

   # This is a clouds.yaml file, which can be used by OpenStack tools as a source
   # of configuration on how to connect to a cloud. If this is your only cloud,
   # just put this file in ~/.config/openstack/clouds.yaml and tools like
   # python-openstackclient will just work with no further config. (You will need
   # to add your password to the auth section)
   # If you have more than one cloud account, add the cloud entry to the clouds
   # section of your existing file and you can refer to them by name with
   # OS_CLOUD=openstack or --os-cloud=openstack
   clouds:
     openstack:
       auth:
         auth_url: http://10.0.0.10:5000/v3
         application_credential_id: "6d141f23732b498e99db8186136c611b"
         application_credential_secret: "<example secret value>"
       region_name: "regionOne"
       interface: "public"
       identity_api_version: 3
       auth_type: "v3applicationcredential"

   Note

   These values will be different for your deployment.

4. Use the Application Credential to generate a token. You must not be sourced as any specific user when using the following command, and you must be in the same directory as your clouds.yaml file.

   $ openstack --os-cloud=openstack token issue
   +------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
   | Field      | Value                                                                                                                                                                                                        |
   +------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
   | expires    | 2018-08-29T05:37:29+0000                                                                                                                                                                                     |
   | id         | gAAAAABbhiMJ4TxxFlTMdsYJpfStsGotPrns0lnpvJq9ILtdi-NKqisWBeNiJlUXwmnoGQDh2CMyK9OeTsuEXnJNmFfKjxiHWmcQVYzAhMKo6_QMUtu_Qm6mtpzYYHBrUGboa_Ay0LBuFDtsjtgtvJ-r8G3TsJMowbKF-yo--O_XLhERU_QQVl3hl8zmMRdmLh_P9Cbhuolt |
   | project_id | 1a74eabbf05c41baadd716179bb9e1da                                                                                                                                                                             |
   | user_id    | ef679eeddfd14f8b86becfd7e1dc84f2                                                                                                                                                                             |
   +------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

   Note

   If you receive an error similar to __init__() got an unexpected keyword argument 'application_credential_secret', then you might still be sourced to the previous credentials. For a fresh environment, run sudo su - stack.

1. Create a new set of Application Credentials.
2. Add the new credentials to the application configuration file, replacing the existing credentials. For more information, see Integrating Application Credentials with applications.
3. Restart the application service to apply the change.
4. Delete the old Application Credential, if appropriate. For more information about the command line options, see Managing Application Credentials.

Procedure

1. Authenticate as the OpenStack user that originally created the Application Credentials that are about to expire. For example, if you used the procedure Using Application Credentials to generate tokens, you must log in again as AppCredsUser.

2. Create an Application Credential called AppCred2. This can be done using the OpenStack Dashboard, or the openstack CLI interface:

   openstack application credential create --description "App Creds 2 - Member" --role member AppCred2

3. Copy the id and secret parameters from the output of the previous command. The secret parameter value cannot be accessed again.
4. Replace the application_credential_id and application_credential_secret parameter values in the ${HOME}/.config/openstack/clouds.yaml file with the secret and id values that you copied.

Procedure

1. Generate a new 256-bit key using order create and store it in the Key Manager service.

   $ openstack secret order create --name swift_key --algorithm aes --mode ctr --bit-length 256 --payload-content-type=application/octet-stream key

   For example:

   +----------------+-----------------------------------------------------------------------------------+
   | Field          | Value                                                                             |
   +----------------+-----------------------------------------------------------------------------------+
   | Order href     | https://192.168.123.173:9311/v1/orders/043383fe-d504-42cf-a9b1-bc328d0b4832       |
   | Type           | Key                                                                               |
   | Container href | N/A                                                                               |
   | Secret href    | None                                                                              |
   | Created        | None                                                                              |
   | Status         | None                                                                              |
   | Error code     | None                                                                              |
   | Error message  | None                                                                              |
   +----------------+-----------------------------------------------------------------------------------+

   You can also use the --mode option to configure generated keys to use a particular mode, such as ctr or cbc. For more information, see NIST SP 800-38A.

2. View the details of the order to identify the location of the generated key, shown here as the Secret href value:

   Example command:

   $ openstack secret order get https://192.168.123.173:9311/v1/orders/043383fe-d504-42cf-a9b1-bc328d0b4832

   For example:

   +----------------+------------------------------------------------------------------------------------+
   | Field          | Value                                                                              |
   +----------------+------------------------------------------------------------------------------------+
   | Order href     | https://192.168.123.173:9311/v1/orders/043383fe-d504-42cf-a9b1-bc328d0b4832        |
   | Type           | Key                                                                                |
   | Container href | N/A                                                                                |
   | Secret href    | https://192.168.123.173:9311/v1/secrets/efcfec49-b9a3-4425-a9b6-5ba69cb18719       |
   | Created        | 2018-01-24T04:24:33+00:00                                                          |
   | Status         | ACTIVE                                                                             |
   | Error code     | None                                                                               |
   | Error message  | None                                                                               |
   +----------------+------------------------------------------------------------------------------------+

3. Retrieve the details of the secret:

   Example command:

   $ openstack secret get https://192.168.123.173:9311/v1/secrets/efcfec49-b9a3-4425-a9b6-5ba69cb18719

   For example:

   +---------------+------------------------------------------------------------------------------------+
   | Field         | Value                                                                              |
   +---------------+------------------------------------------------------------------------------------+
   | Secret href   | https://192.168.123.173:9311/v1/secrets/efcfec49-b9a3-4425-a9b6-5ba69cb18719       |
   | Name          | swift_key                                                                          |
   | Created       | 2018-01-24T04:24:33+00:00                                                          |
   | Status        | ACTIVE                                                                             |
   | Content types | {u'default': u'application/octet-stream'}                                          |
   | Algorithm     | aes                                                                                |
   | Bit length    | 256                                                                                |
   | Secret type   | symmetric                                                                          |
   | Mode          | ctr                                                                                |
   | Expiration    | None                                                                               |
   +---------------+------------------------------------------------------------------------------------+

Procedure

1. Create a Block Storage volume template that uses encryption. When you create new volumes, they can be modeled off the settings you define here:

   $ openstack volume type create --encryption-provider nova.volume.encryptors.luks.LuksEncryptor --encryption-cipher aes-xts-plain64 --encryption-key-size 256 --encryption-control-location front-end LuksEncryptor-Template-256

   For example:

   +-------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
   | Field       | Value                                                                                                                                                                              |
   +-------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
   | description | None                                                                                                                                                                               |
   | encryption  | cipher='aes-xts-plain64', control_location='front-end', encryption_id='9df604d0-8584-4ce8-b450-e13e6316c4d3', key_size='256', provider='nova.volume.encryptors.luks.LuksEncryptor' |
   | id          | 78898a82-8f4c-44b2-a460-40a5da9e4d59                                                                                                                                               |
   | is_public   | True                                                                                                                                                                               |
   | name        | LuksEncryptor-Template-256                                                                                                                                                         |
   +-------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

2. Create a new Block Storage volume and specify that it uses the LuksEncryptor-Template-256 settings:

   $ openstack volume create --size 1 --type LuksEncryptor-Template-256 'Encrypted-Test-Volume'

   For example:

   +---------------------+--------------------------------------+
   | Field               | Value                                |
   +---------------------+--------------------------------------+
   | attachments         | []                                   |
   | availability_zone   | nova                                 |
   | bootable            | false                                |
   | consistencygroup_id | None                                 |
   | created_at          | 2018-01-22T00:19:06.000000           |
   | description         | None                                 |
   | encrypted           | True                                 |
   | id                  | a361fd0b-882a-46cc-a669-c633630b5c93 |
   | migration_status    | None                                 |
   | multiattach         | False                                |
   | name                | Encrypted-Test-Volume                |
   | properties          |                                      |
   | replication_status  | None                                 |
   | size                | 1                                    |
   | snapshot_id         | None                                 |
   | source_volid        | None                                 |
   | status              | creating                             |
   | type                | LuksEncryptor-Template-256           |
   | updated_at          | None                                 |
   | user_id             | 0e73cb3111614365a144e7f8f1a972af     |
   +---------------------+--------------------------------------+

   The resulting secret is automatically uploaded to the Key Manager service back end.

3. Ensure that you can see the Key Manager service secret UUID. This value is displayed in the encryption_key_id field.

   $ cinder --os-volume-api-version 3.64 volume show Encrypted-Test-Volume

   For example:

   +------------------------------+-------------------------------------+
   |Property                      |Value                                |
   +------------------------------+-------------------------------------+
   |attached_servers              |[]                                   |
   |attachment_ids                |[]                                   |
   |availability_zone             |nova                                 |
   |bootable                      |false                                |
   |cluster_name                  |None                                 |
   |consistencygroup_id           |None                                 |
   |created_at                    |2022-07-28T17:35:26.000000           |
   |description                   |None                                 |
   |encrypted                     |True                                 |
   |encryption_key_id             |0944b8a8-de09-4413-b2ed-38f6c4591dd4 |
   |group_id                      |None                                 |
   |id                            |a0b51b97-0392-460a-abfa-093022a120f3 |
   |metadata                      |                                     |
   |migration_status              |None                                 |
   |multiattach                   |False                                |
   |name                          |vol                                  |
   |os-vol-host-attr:host         |hostgroup@tripleo_iscsi#tripleo_iscsi|
   |os-vol-mig-status-attr:migstat|None                                 |
   |os-vol-mig-status-attr:name_id|None                                 |
   |os-vol-tenant-attr:tenant_id  |a2071ece39b3440aa82395ff7707996f     |
   |provider_id                   |None                                 |
   |replication_status            |None                                 |
   |service_uuid                  |471f0805-072e-4256-b447-c7dd10ceb807 |
   |shared_targets                |False                                |
   |size                          |1                                    |
   |snapshot_id                   |None                                 |
   |source_volid                  |None                                 |
   |status                        |available                            |
   |updated_at                    |2022-07-28T17:35:26.000000           |
   |user_id                       |ba311b5c2b8e438c951d1137333669d4     |
   |volume_type                   |LUKS                                 |
   |volume_type_id                |cc188ace-f73d-4af5-bf5a-d70ccc5a401c |
   +------------------------------+-------------------------------------+

   Note

   You must use the --os-volume-api-version 3.64 parameter with the Block Storage service cinder CLI to display the encryption_key_id value. There is no equivalent openstack CLI command.

4. Use the Key Manager service to confirm that the disk encryption key is present. In this example, the timestamp matches the LUKS volume creation time:

   $ openstack secret list

   For example:

   +------------------------------------------------------------------------------------+------+---------------------------+--------+-------------------------------------------+-----------+------------+-------------+------+------------+
   | Secret href                                                                        | Name | Created                   | Status | Content types                             | Algorithm | Bit length | Secret type | Mode | Expiration |
   +------------------------------------------------------------------------------------+------+---------------------------+--------+-------------------------------------------+-----------+------------+-------------+------+------------+
   | https://192.168.123.169:9311/v1/secrets/0944b8a8-de09-4413-b2ed-38f6c4591dd4 | None | 2018-01-22T02:23:15+00:00 | ACTIVE | {u'default': u'application/octet-stream'} | aes       |        256 | symmetric   | None | None       |
   +------------------------------------------------------------------------------------+------+---------------------------+--------+-------------------------------------------+-----------+------------+-------------+------+------------+

5. Attach the new Block Storage volume to an existing instance:

   $ openstack server add volume testInstance Encrypted-Test-Volume

   The Block Storage volume is now available for you to mount to the guest file system.

Procedure

1. Use the openssl command to create the keys and the certificate:

   • Create the private key:

     $ openssl genrsa -out private_key.pem 1024

   • Create the public key:

     $ openssl rsa -pubout -in private_key.pem -out public_key.pem

   • Create the certificate:

     $ openssl req -new -key private_key.pem -out cert_request.csr

   • When prompted, enter details to include in your certificate request:

     $ openssl x509 -req -days 14 -in cert_request.csr -signkey private_key.pem -out new_cert.crt

2. Upload the certificate to the Key Manager service, where it is stored in the secret store:

   $ openstack secret store --name test --algorithm RSA --secret-type certificate \
     --payload-content-type "application/octet-stream" \
     --payload-content-encoding base64 \
     --payload "$(base64 new_cert.crt)"

   For example:

   +---------------+-----------------------------------------------------------------------+
   | Field         | Value                                                                 |
   +---------------+-----------------------------------------------------------------------+
   | Secret href   | http://127.0.0.1:9311/v1/secrets/cd7cc675-e573-419c-8fff-33a72734a243 |
   +---------------+-----------------------------------------------------------------------+

   Note

   Record the certificate’s UUID for use in a later step. In this example, the UUID is cd7cc675-e573-419c-8fff-33a72734a243.

3. Retrieve an image and create a signature:

   • Retrieve an image:

     $ echo <This is my image> > <myimage>

   • Use private_key.pem to sign the image and generate the .signature file. For example:

     $ openssl dgst -sha512 -sign private_key.pem -sigopt rsa_padding_mode:pss -out myimage.signature myimage

   • Convert the .signature file to Base64 format:

     $ base64 -w 0 myimage.signature > myimage.signature.b64

   • Load the Base64 value into a variable to use when you upload the image:

     $ image_signature=$(cat myimage.signature.b64)

4. Upload an image with valid signature properties to the Image service:

   $ openstack image-create \
     --name <my_signed_image> \
     --container-format bare \
     --disk-format qcow2 \
     --property img_signature="$image_signature" \
     --property img_signature_certificate_uuid="$cert_uuid" \
     --property img_signature_hash_method='SHA-512' \
     --property img_signature_key_type='RSA-PSS' < myimage

Procedure

1. Download the snapshot from the Image service:

   $ openstack image save --file <local_file_name> <snapshot_image_name>

   • Replace <local_file_name> with the file name of the downloaded image.
   • Replace <snapshot_image_name> with the name of your snapshot.
2. Generate a signature to validate the snapshot. Use the same process that you use to generate a signature to validate an image. For more information, see Signing Image service (glance) images.

3. Update the snapshot image properties:

   $ openstack image set \
     --property img_signature="$image_signature" \
     --property img_signature_certificate_uuid="<cd7cc675-e573-419c-8fff-33a72734a243>" \
     --property img_signature_hash_method="SHA-512" \
     --property img_signature_key_type="RSA-PSS" \
     <snapshot_image_id>

   • Replace <cd7cc675-e573-419c-8fff-33a72734a243> with the UUID of the certificate for the image.
   • Replace <snapshot_image_id> with the ID of your snapshot.

4. Optional: Remove the downloaded Image service image from the filesystem:

   $ rm <local_file_name>

Procedure

1. Retrieve the base64 decoded BarbicanSimpleCryptoKEK value from osp-secret and save it to a file called kek.txt:

   $ oc get secret osp-secret -o yaml | grep BarbicanSimpleCryptoKEK | awk '{print $2}' | base64 -d > kek.txt

2. Retrieve the Key Manager database root password:

   $ DB_PASS=$(oc get secret osp-secret -o yaml | grep DbRootPassword | awk '{print $2}' | base64 -d)

3. Use the Key Manager database root password to back up the barbican database:

   $ oc exec -it openstack-galera-0 -- mysqldump -u root -p"${DB_PASS}" barbican > barbican_db_backup.sql

4. Check that the database backup is stored in your current working directory:

   $ ll
   total 36
   -rw-rw-r--. 1 tripleo-admin tripleo-admin 36715 Jun 19 18:31 barbican_db_backup.sql

5. Back up the barbican_db_backup.sql and kek.txt files to the security hardened location.

Procedure

1. Encode your BarbicanSimpleCryptoKek key using base64 and write the resulting value into osp-secret:

   $ echo <barbican_key> | base64
   YmFyYmljYW5fc2ltcGxlX2N5cHRvX2tlawo=

   Replace <barbican_key> with the BarbicanSimpleCryptoKek key that you want to restore.

2. Open the osp-secret secret object for editing:

   $ oc edit secret osp-secret

3. Add the value from step 1 and save your changes:

   ....
     BarbicanDatabasePassword: cGFzc3dvcmQK
     BarbicanPassword: cGFzc3dvcmQK
     BarbicanSimpleCryptoKEK: YmFyYmljYW5fc2ltcGxlX2N5cHRvX2tlawo=
     CeilometerPassword: cGFzc3dvcmQK
     CinderDatabasePassword: cGFzc3dvcmQK
     CinderPassword: cGFzc3dvcmQK
     DatabasePassword: cGFzc3dvcmQK
   ....

4. Retrieve the Key Manager database root password:

   DB_PASS=$(oc get secret osp-secret -o yaml | grep DbRootPassword | awk '{print $2}' | base64 -d)

5. Restore the backup file to the Key Manager barbican database:

   $ oc exec openstack-galera-0 --  mysql -u root -p"${DB_PASS}" barbican < <sql_backup>

   • Replace <sql_backup> with the name of your mysql database backup file.

     For example:

     Defaulted container "galera" out of: galera, mysql-bootstrap (init)

Procedure

1. Create a Block Storage volume type that uses encryption:

   $ openstack volume type create \
   --encryption-provider  nova.volume.encryptors.luks.LuksEncryptor \
   --encryption-cipher aes-xts-plain64 \
   --encryption-key-size 256 \
   --encryption-control-location front-end LuksEncryptor-256

   For example:

   +-------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
   | Field       | Value                                                                                                                                                                              |
   +-------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
   | description | None                                                                                                                                                                               |
   | encryption  | cipher='aes-xts-plain64', control_location='front-end', encryption_id='9df604d0-8584-4ce8-b450-e13e6316c4d3', key_size='256', provider='nova.volume.encryptors.luks.LuksEncryptor' |
   | id          | 78898a82-8f4c-44b2-a460-40a5da9e4d59                                                                                                                                               |
   | is_public   | True                                                                                                                                                                               |
   | name        | LuksEncryptor-256                                                                                                                                                                  |
   +-------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

2. Create a new Block Storage volume and specify that it uses the LuksEncryptor-256 volume type:

   $ openstack volume create --size 1 --type LuksEncryptor-256 'Encrypted-Test-Volume'

   For example:

   +---------------------+--------------------------------------+
   | Field               | Value                                |
   +---------------------+--------------------------------------+
   | attachments         | []                                   |
   | availability_zone   | nova                                 |
   | bootable            | false                                |
   | consistencygroup_id | None                                 |
   | created_at          | 2018-01-22T00:19:06.000000           |
   | description         | None                                 |
   | encrypted           | True                                 |
   | id                  | a361fd0b-882a-46cc-a669-c633630b5c93 |
   | migration_status    | None                                 |
   | multiattach         | False                                |
   | name                | Encrypted-Test-Volume                |
   | properties          |                                      |
   | replication_status  | None                                 |
   | size                | 1                                    |
   | snapshot_id         | None                                 |
   | source_volid        | None                                 |
   | status              | creating                             |
   | type                | LuksEncryptor-256                    |
   | updated_at          | None                                 |
   | user_id             | 0e73cb3111614365a144e7f8f1a972af     |
   +---------------------+--------------------------------------+

   The resulting secret is automatically uploaded to the Key Manager back end.

3. Obtain the Key Manager secret UUID. This value is displayed in the encryption_key_id field:

   $ openstack --os-volume-api-version 3.64 volume show Encrypted-Test-Volume

   For example:

   +------------------------------+-------------------------------------+
   |Property                      |Value                                |
   +------------------------------+-------------------------------------+
   |attached_servers              |[]                                   |
   |attachment_ids                |[]                                   |
   |availability_zone             |nova                                 |
   |bootable                      |false                                |
   |cluster_name                  |None                                 |
   |consistencygroup_id           |None                                 |
   |created_at                    |2022-07-28T17:35:26.000000           |
   |description                   |None                                 |
   |encrypted                     |True                                 |
   |encryption_key_id             |0944b8a8-de09-4413-b2ed-38f6c4591dd4 |
   |group_id                      |None                                 |
   |id                            |a0b51b97-0392-460a-abfa-093022a120f3 |
   |metadata                      |                                     |
   |migration_status              |None                                 |
   |multiattach                   |False                                |
   |name                          |vol                                  |
   |os-vol-host-attr:host         |hostgroup@tripleo_iscsi#tripleo_iscsi|
   |os-vol-mig-status-attr:migstat|None                                 |
   |os-vol-mig-status-attr:name_id|None                                 |
   |os-vol-tenant-attr:tenant_id  |a2071ece39b3440aa82395ff7707996f     |
   |provider_id                   |None                                 |
   |replication_status            |None                                 |
   |service_uuid                  |471f0805-072e-4256-b447-c7dd10ceb807 |
   |shared_targets                |False                                |
   |size                          |1                                    |
   |snapshot_id                   |None                                 |
   |source_volid                  |None                                 |
   |status                        |available                            |
   |updated_at                    |2022-07-28T17:35:26.000000           |
   |user_id                       |ba311b5c2b8e438c951d1137333669d4     |
   |volume_type                   |LUKS                                 |
   |volume_type_id                |cc188ace-f73d-4af5-bf5a-d70ccc5a401c |
   +------------------------------+-------------------------------------+

4. Use the Key Manager service to confirm that the disk encryption key is present. In the following example, the Key Manager secret UUID matches the encryption_key_id in the previous example output and the timestamp matches the LUKS volume creation time:

   $ openstack secret list

   For example:

   +------------------------------------------------------------------------------------+------+---------------------------+--------+-------------------------------------------+-----------+------------+-------------+------+------------+
   | Secret href                                                                        | Name | Created                   | Status | Content types                             | Algorithm | Bit length | Secret type | Mode | Expiration |
   +------------------------------------------------------------------------------------+------+---------------------------+--------+-------------------------------------------+-----------+------------+-------------+------+------------+
   | https://192.168.123.169:9311/v1/secrets/0944b8a8-de09-4413-b2ed-38f6c4591dd4 | None | 2018-01-22T02:23:15+00:00 | ACTIVE | {u'default': u'application/octet-stream'} | aes       |        256 | symmetric   | None | None       |
   +------------------------------------------------------------------------------------+------+---------------------------+--------+-------------------------------------------+-----------+------------+-------------+------+------------+

5. Attach the new Block Storage volume to an existing instance:

   $ openstack server add volume testInstance Encrypted-Test-Volume