Rotate user credentials

Create and update usernames or passwords to secure system access. Rotate credentials regularly to prevent unauthorized entry and ensure compliance with your security standards.

Rotate the following user credentials without causing service disruption:

  • To rotate the user credentials of the MariaDB database account of an OpenStack service.
  • To rotate the password of the root database account of a Galera database.
  • To rotate the user credentials of a dedicated RabbitMQ user.

Rotate OpenStack service database credentials
Copy link

Rotate MariaDB database account credentials for OpenStack services to prevent unauthorized entry and ensure security compliance. Create a new database account and maintain two credential sets to prevent service outages during rotation.

About this task
Copy link

In Red Hat OpenStack Services on OpenShift every OpenStack service that requires database access has a unique MariaDB database account managed by a MariaDBAccount custom resource (CR), which provides the user credentials. This database account targets a specific database, which by default is the openstack database. Use the following command to list all the available database accounts:

$ oc get mariadbaccount

The OpenStackControlPlane CR uses the name specified by the databaseAccount: parameter of a service to create the database account for this service and the associated MariaDBAccount CR. To rotate the database account user credentials for an OpenStack service, edit the OpenStackControlPlane CR to specify a new name for the databaseAccount: parameter of this service and apply this change.

After the new database account has been successfully created, the old database account remains until the resources are updated to use the new database account.

The following procedure rotates the user credentials of the default database account for the OpenStack Identity service (keystone) in the control plane, which is called keystone.

Procedure
Copy link

  1. Set the default RHOSO namespace: 
    $ oc project <namespace>

    where:

    <namespace> is the namespace of the required RHOSO environment, for example, openstack.

  2. Edit your OpenStackControlPlane CR on your workstation: 
    $ oc edit openstackcontrolplane <name>

    where:

    <name> is 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. Do not use the underscore _ 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. Verify that the new database account has been successfully created for your OpenStack service: 
    $ oc get mariadbaccount
  8. (Optional) You can delete the old database account for this OpenStack service if it is displayed in this list: 
    $ oc delete mariadbaccounts <database-account-name>

    where:

    <database-account-name> is the name of the old database account, such as keystone.

Rotate the root database account password with a secret you create
Copy link

You must use this procedure to rotate the root database account when the spec of the associated MariaDB Galera cluster in the OpenStackControlPlane CR contains the secret: osp-secret field. Otherwise you use this method to specify your own secret instead of having Galera generate one for you.

About this task
Copy link

You must create a new secret containing the new password and then you must update the MariaDB root database account with this secret.

Note
Never modify the existing secret, always create a new secret when rotating the password for the root database account.

If you edit the spec of the associated MariaDB Galera cluster in the OpenStackControlPlane CR to remove the secret: osp-secret field then Galera can generate a new secret for you. For more information, see Rotate the root database account password.

Procedure
Copy link

  1. Set the default RHOSO namespace: 
    $ oc project <namespace>

    where:

    <namespace>
    Specifies the namespace of the required RHOSO environment, for example, openstack.
  2. Retrieve the name of the root database account and the name of the root database secret from the Galera CR that manages the associated MariaDB Galera Cluster. In the following example, the Galera CR is named openstack: 
    oc describe galera openstack
Name:         openstack
...
Status:
...
  Root Database Account:  openstack-mariadb-root
  Root Database Secret:   openstack-mariadb-root-db-secret
...
  3. 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

    where:

    <new-secret-name>
    Specifies the new secret name, for example, openstack-mariadb-root-db-secret-2026-08. Note
    Separate each word in the secret name with a dash.
    <your-new-password>
    Specifies 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.
  4. Apply the new secret CR: 
    $ oc apply -f new-password-secret.yaml
  5. Edit the MariaDBAccount CR of the root database account that you retrieved in step 2, which in this example is openstack-mariadb-root: 
    $ oc edit mariadbaccount openstack-mariadb-root
  6. Specify the name of the new secret in the MariaDBAccount CR: 
    apiVersion: mariadb.openstack.org/v1beta1
kind: MariaDBAccount
metadata:
  name: openstack-mariadb-root
  namespace: openstack
spec:
  userName: root
  accountType: System
  secret: <new-secret-name>

    where:

    <new-secret-name>
    Specifies the new secret name that you created in step 3, which in this example is: openstack-mariadb-root-db-secret-2025-02.
  7. Save and close this editor to apply this change.
  8. Wait for the MariaDBAccount CR to be updated.
  9. Verify that the password is successfully rotated, by running the following command again to retrieve the current name of the root database secret from the Galera CR that manages the associated MariaDB Galera Cluster. In the following example, the Galera CR is named openstack: 
    $ oc describe galera openstack

    The Root Database Secret field is set to the old secret name while the password rotation process completes, which in this example is: openstack-mariadb-root-db-secret. When the password is successfully rotated the Root Database Secret field is set to the new secret name, which in this example is: openstack-mariadb-root-db-secret-2025-02.

  10. After you have confirmed that the root database password is successfully rotated, delete the old root database account secret: 
    $ oc delete secret <old-secret-name>

    where:

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

Rotate the root database account password with a generated secret
Copy link

Using a secret that Galera generates is the simplest method of rotating the password of the MariaDB database account for the root user. It is also secure because when you rename the MariaDB root database account secret, Galera generates the new secret by using a high entropy string.

Before you begin
Copy link

  • The MariaDB Galera cluster spec in the OpenStackControlPlane CR does not contain the secret: osp-secret field.

About this task
Copy link

Rotating the password of the MariaDB database account for the root user prevents unauthorized access to its MariaDB Galera Cluster and ensures compliance with your security standards. This password rotation process ensures that the root database password is rotated without service disruption. For more information, see Rotate the root database account password.

Procedure
Copy link

  1. Set the default RHOSO namespace: 
    $ oc project <namespace>

    where:

    <namespace>
    Specifies the namespace of the required RHOSO environment, for example, openstack.
  2. Retrieve the name of the root database account and the name of the root database secret from the Galera CR that manages the associated MariaDB Galera Cluster. In the following example, the Galera CR is named openstack: 
    oc describe galera openstack
Name:         openstack
...
Status:
...
  Root Database Account:  openstack-mariadb-root
  Root Database Secret:   openstack-mariadb-root-db-secret
...
  3. Edit the MariaDBAccount CR of the root database account that you retrieved: 
    $ oc edit mariadbaccount openstack-mariadb-root
  4. Specify the name of the new secret in the MariaDBAccount CR: 
    apiVersion: mariadb.openstack.org/v1beta1
kind: MariaDBAccount
metadata:
  name: openstack-mariadb-root
  namespace: openstack
spec:
  userName: root
  accountType: System
  secret: <new-secret-name>

    where:

    <new-secret-name>
    Specifies the name of the new secret, which in this example is: openstack-mariadb-root-db-secret-2025-02. Note
    Separate each word in the secret name with a dash.
  5. Save and close this editor to apply this change.
  6. Wait for the MariaDBAccount CR to be updated.
  7. Verify that the password is successfully rotated, by running the following command again to retrieve the current name of the root database secret from the Galera CR that manages the associated MariaDB Galera Cluster. In the following example, the Galera CR is named openstack: 
    $ oc describe galera openstack

    The Root Database Secret field is set to the old secret name while the password rotation process completes, which in this example is: openstack-mariadb-root-db-secret. When the password is successfully rotated the Root Database Secret field is set to the new secret name, which in this example is: openstack-mariadb-root-db-secret-2025-02.

  8. After you have confirmed that the root database password is successfully rotated, delete the old root database account secret: 
    $ oc delete secret <old-secret-name>

    where:

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

Root database account password
Copy link

If you know the Galera name of the required database then you can use a script to decode the password from the secret of its root database account.

The Galera name depends on your control plane deployment. The name used in the default control plane is openstack for the database referenced by all the deployed OpenStack services that require a database and openstack-cell1 for the database used by the OpenStack Compute service for cell1. You can use the following command to list all of your deployed Galera instances:

$ oc get galera -n <namespace>

where:

<namespace> is the namespace of the required RHOSO environment, for example, openstack.

Use the following script to decode and retrieve the password from the secret of a root database account for the openstack Galera database:

# Set the Galera instance name
GALERA_NAME="openstack"

# Get the secret name
SECRET_NAME=$(oc get galera $GALERA_NAME -n openstack -o jsonpath='{.status.rootDatabaseSecret}')

# Decode the password
oc get secret $SECRET_NAME -n openstack -o jsonpath='{.data.DatabasePassword}' | base64 -d
echo  # Print newline

Create dedicated RabbitMQ users for service isolation
Copy link

By default, all OpenStack services share a single RabbitMQ user. For security and isolation, you can create dedicated RabbitMQ users for your OpenStack services.

About this task
Copy link

Depending upon the RabbitMQ messaging requirements of a RHOSO service, you can create a dedicated RabbitMQ user for the RPC communication of the service, by adding the user: parameter to the template.messagingBus configuration section and specifying the required user name. Similarly you can create a dedicated RabbitMQ user for the notifications of the service, by adding the user: parameter to the template.notificationsBus configuration section and specifying the required user name.

Important
RHOSO manages the passwords for the RabbitMQ user names that you specify.
RabbitMQ user credential creation process
  1. The RHOSO administrator must specify the dedicated RabbitMQ users for the required OpenStack services in the OpenStackControlPlane CR.
  2. The RHOSO administrator must update the OpenStackControlPlane CR.
  3. RHOSO creates RabbitMQ users using the names that you specify. Note
    Do not use the underscore character _ when creating user names.
  4. RHOSO generates a secure random password for each new RabbitMQ user.
  5. RHOSO stores each password in a Kubernetes secret.
  6. RHOSO configures each OpenStack service to use their RabbitMQ user credentials

Routinely change the user name of the dedicated RabbitMQ users of the OpenStack services to rotate their user credentials.

The following procedure creates a dedicated RabbitMQ user named cinder-user1 for the RabbitMQ RPC communication of the Block Storage service (cinder), configured in its template.messagingBus configuration section.

In this example, the OpenStackControlPlane CR uses the global messagingBus RabbitMQ setting to specify rabbitmq as the RabbitMQ cluster for the Block Storage service (cinder).

Procedure
Copy link

  1. Set the default RHOSO namespace: 
    $ oc project <namespace>

    where:

    <namespace> is the namespace of the required RHOSO environment, for example, openstack.

  2. Get the name of your YAML OpenStackControlPlane CR: 
    $ oc get openstackcontrolplane
  3. Edit your OpenStackControlPlane CR on your workstation: 
    $ oc edit openstackcontrolplane <name>

    where:

    <name> is the name of your YAML OpenStackControlPlane CR.

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

Results
Copy link

  • After the deployment of the control plane completes, verify that the dedicated RabbitMQ user is created: 
    $ oc get rabbitmquser
NAME                                  CLUSTER    USERNAME   VHOST   STATUS   MESSAGE
cinder-cinder-transport-cinder-user1-user   rabbitmq   cinder-user1     /       True     Setup complete
    • NAME: is the resource name for this RabbitMQ user, which adheres to the following format: <service>-<component>-<transport-type>-<username>-user

      where:

      <service> is the OpenStack service name. In this example, this is cinder for the Block Storage service.

      <component> is the component of the specified OpenStack service. In this example, this is cinder for the Block Storage service component. All the other Block Storage components, such as the Block Storage API and scheduler share this user.

      <transport-type> is the type of RabbitMQ messaging. In this example, this is transport to indicate RPC messaging. If we were configuring the notification messaging, then this would be the notifications-transport.

      <username> is the name of the user that you specify. In this example, this is cinder-user1.

      user is that this is a RabbitMQUser resource.

    • CLUSTER is the RabbitMQ cluster this user belongs to. In this example, this is rabbitmq.
    • USERNAME is the name of the user that you specify. In this example, this is cinder-user1.
    • VHOST is the RabbitMQ virtual host that this user can access. In this example, this is the default virtual host /.
    • STATUS indicates whether this user was created successfully True or not False.
    • MESSAGE is the message associated with the specified STATUS.

Rotate RabbitMQ user credentials
Copy link

Rotate the credentials of the dedicated RabbitMQ users of your OpenStack services to prevent unauthorized access and ensure compliance with your organization’s security standards.

Before you begin
Copy link

  • The OpenStack control plane is deployed with a dedicated RabbitMQ user for the required OpenStack service. In this example, the Block Storage service (cinder).
  • You have verified which RabbitMQ user name is currently specified for the required OpenStack service. In this example, the RabbitMQ user name is cinder-user1.
  • If the required OpenStack service must update Compute nodes and external services in the data plane, ensure that you have the latest OpenStackDataPlaneDeployment CR YAML file, for example, openstack-edpm-deployment.yaml. Note
    You must create a new OpenStackDataPlaneDeployment CR to start another Ansible execution that applies any changes you make to the data plane. This is because when an OpenStackDataPlaneDeployment CR successfully completes execution, it does not automatically run the Ansible again, even if the OpenStackDataPlaneDeployment CR or related OpenStackDataPlaneNodeSet resources are changed.

About this task
Copy link

RHOSO manages the passwords for the RabbitMQ user names that you specify. Having two sets of credentials mitigates a service outage during the process of updating these credentials.

RabbitMQ user credential rotation process
  1. The RHOSO administrator must have created the initial RabbitMQ users for the required OpenStack services in the OpenStackControlPlane custom resource (CR) file.
  2. The RHOSO administrator must change these user names in the OpenStackControlPlane CR to rotate your RabbitMQ user credentials.
  3. The RHOSO administrator must update the OpenStackControlPlane CR.
  4. RHOSO creates new RabbitMQ users with their new names.
  5. RHOSO generates a new secure random password for each new user.
  6. RHOSO stores each password in a Kubernetes secret.
  7. RHOSO updates each service to use the new user credentials.
  8. RHOSO keeps the old user credentials until the RHOSO administrator deletes them manually.

The old RabbitMQ users cannot be automatically deleted because:

  • Services running on Compute nodes in the data plane use the RabbitMQ service.
  • Network agents running on external nodes use the RabbitMQ service.

Therefore automatically deleting the old users could break these services before they update to the new credentials. The RHOSO administrator must therefore verify that all services, including data plane deployments, are using the new credentials before manually removing the old users.

The following procedure rotates the RabbitMQ credentials for the Block Storage service (cinder), by creating a new RabbitMQ user named cinder-user2 for the RabbitMQ RPC communication of the Block Storage service and removing the old user named cinder-user1.

Procedure
Copy link

  1. Set the default RHOSO namespace: 
    $ oc project <namespace>

    where:

    <namespace> is the namespace of the required RHOSO environment, for example, openstack.

  2. Edit your OpenStackControlPlane CR on your workstation: 
    $ oc edit openstackcontrolplane <name>

    where:

    <name> is 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.
     
      spec:
  ...
    cinder:
      ...
      template:
        messagingBus:
          user: cinder-user2
  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
  6. 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

      where:

      <name> is the name of your OpenStackDataPlaneDeployment CR. The name of the CR can be different from the YAML file name. Use the following command to retrieve this CR 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.

  7. 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
  8. Delete the old RabbitMQ user, which in this example is cinder-user1: 
    $ oc edit rabbitmquser <rabbitmq-user-name>

    where:

    <rabbitmq-user-name> is 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.
  9. 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 is absent from the list.