-
Story
-
Resolution: Unresolved
-
Critical
-
None
-
rhos-17.1.4
-
None
The Bank of Italy needs to rotate the integrated Keystone administrator user password without affecting the passwords for all other services.
Today, RHOSP 17.1 offers a certified procedure for rotating all service account passwords, as outlined in reference [1].
Accordingly, KCS 2748511 has been updated to direct users to the official documentation [1].
As indicated in the customer comment below, rotating all service passwords has a significant impact and, given the size of the RHOSP cluster, it may also take several hours to complete the full procedure.
This means that performing such a rotation will cause a significant control plane downtime (each overcloud deploy takes hours in our main production environment) and might even cause IHA to fence the compute nodes when the pacemaker system user credentials are rotated.
Should we need to perform such rotation when IHA is enabled, do we need to disarm fencing beforehand via pcs (and obviously in fencing.yaml in the overcloud templates), rotate the service passwords and then re-enable fencing? This could mean performing two rounds of openstack overcloud deploy (the first one to rotate the passwords and the second one to re-enable fencing).
Due to the urgency of this request, might it be permissible to proceed using the previous procedures outlined in [3] (steps derived from revision -1 of KCS 2748511), including manually updating the overcloud-passwords.yaml file accordingly ?
In the earlier version of KCS 2748511 [3], the overcloudrc was synchronized with the new password following the completion of the administrator password rotation; however, no modifications were planned for the overcloud-passwords.yaml file at that time.
Could you help to identify the right procedure to manually update the admin password and align all required files (yaml and not) ?
I am not in favor of a partial password rotation; however, implementing a targeted approach to update passwords that are relevant to external access could provide a practical solution, enabling the customer to implement swift remediation if necessary.
[2] https://access.redhat.com/node/2748511
[3] https://access.redhat.com/node/2748511/revisions/23763211/view
For OSP16 and later use --domain option as well
[stack@undercloud-1 ~]$ openstack user set -h
usage: openstack user set [-h] [--name <name>] [--domain <domain>]
[--project <project>]
[--project-domain <project-domain>]
[--password <password>] [--password-prompt]
[--email <email-address>]
[--description <description>] [--enable | --disable]
<user>
[stack@undercloud-1 ~]$ openstack user set --domain default --password zpH4xMAvVFFTMwzu4cnqmERAg admin
Change the OS_PASSWORD in overcloudrc, e.g. with vim overcloudrc
OS_NO_CACHE=True
export OS_CLOUDNAME=overcloud
export OS_AUTH_URL=http://10.0.0.4:5000/v2.0
export NOVA_VERSION=1.1
export COMPUTE_API_VERSION=1.1
export OS_USERNAME=admin
export no_proxy=,10.0.0.4,192.0.2.15
export OS_PASSWORD=test
export PYTHONWARNINGS="ignore:Certificate has no, ignore:A true SSLContext object is not available"
export OS_TENANT_NAME=admin
Note that it is mandatory so source overcloudrc once more
overcloudrc
