This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1313054 - [RFE] Allow changing passwords for overcloud OpenStack "admin" or service users
[RFE] Allow changing passwords for overcloud OpenStack "admin" or service users
Status: CLOSED DUPLICATE of bug 1337297
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director (Show other bugs)
7.0 (Kilo)
Unspecified Unspecified
medium Severity medium
: Upstream M3
: 12.0 (Pike)
Assigned To: Angus Thomas
Arik Chernetsky
: FutureFeature
Depends On:
Blocks: 1339506
  Show dependency treegraph
 
Reported: 2016-02-29 15:03 EST by Pablo Caruana
Modified: 2017-03-20 14:09 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-03-20 14:09:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pablo Caruana 2016-02-29 15:03:42 EST
What problem/issue/behavior are you having trouble with?  What do you expect to see?

When deploying the Overcloud, passwords for OpenStack services like Neutron or Cinder are generated to be some random value. However, once the Overcloud is deployed there's not established procedure for changing any of these passwords.

A typical use case for this: let's say the password for either the Overcloud "admin" user, or "neutron" or "glance" is compromised. The typical counteraction consists of generating a new, secure password, and reconfiguring the compromised user to use the new password. As far as we can see from the documentation, this procedure is not documented.

Where are you experiencing the behavior?  What environment?


In  the ovecloud OSP7 clusters.

When does the behavior occur? Frequently?  Repeatedly?   At certain times?

Hasn't happened yet, but the probability of this happening in the future is non-zero.
Comment 4 Mike Burns 2016-04-07 17:11:06 EDT
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.
Comment 7 Adam Young 2016-09-02 13:41:24 EDT
Is this possible in Tripleo?  To regenerate the generated passwords when doing a redeploy?  It is not Keystone specific, as the same kind of thing would be needed for Rabbit, and for databases.
Comment 9 Dan Prince 2016-09-26 10:46:05 EDT
Using the CLI most users would get initial passwords generated via python-tripleoclient. These CLI passwords can be overridden by environment variables on the CLI by specifying something like (for glance) OVERCLOUD_GLANCE_PASSWORD.

Python-tripleoclient uses these environment variables to construct a heat environment to set all of these passwords.

If an end user wanted to change a password for one of the services (manually) and have it re-deployed via Heat then one could create a custom Heat environment file and append it onto the 'overcloud deploy' command with a -e. So something like:

parameters_defaults:
  GlancePassword: fooboar

This would set the Glance password to the hard coded value above. All of this works today and should allow changing passwords driven via Heat.

The tricker parts of this are where these passwords apply to keystone and or mysql database settings that also need to be update. In some cases the puppet providers should take care of updating passwords for these services accordingly. In others there may be manual changes required for cluster type password changes and there is probably still feature work to do on this front (Rabbit and Mysql password changes for example).
Comment 10 Chen 2016-11-14 22:37:39 EST
Hi Dan,

It seems that AdminPassword can not be set in this way. 

parameter_defaults:
  AdminPassword: "redhatgss"

The deployment itself succeeded but the endpoints are abnormal: Only the endpoints for nova were created.

MariaDB [keystone]> select interface,url,enabled from endpoint;
+-----------+---------------------------------+---------+
| interface | url                             | enabled |
+-----------+---------------------------------+---------+
| internal  | http://192.168.124.21:5000/v2.0 |       1 |
| public    | http://10.11.48.181:5000/v2.0   |       1 |
| admin     | http://192.0.2.14:35357/v2.0    |       1 |
+-----------+---------------------------------+---------+

Is this a known bug or do I need to file a new one ?

Best Regards,
Chen
Comment 11 Chen 2016-11-15 22:07:19 EST
Sorry not nova endpoints but keystone endpoints...
Comment 12 Dan Prince 2016-12-13 06:58:56 EST
Chen: This might be a new, but related bug. I'm going to try and replicate this myself today.
Comment 18 Rob Crittenden 2017-03-20 14:09:02 EDT
Changing deployed passwords is in the same problem space as rotating passwords, closing as duplicate.

*** This bug has been marked as a duplicate of bug 1337297 ***

Note You need to log in before you can comment on or make changes to this bug.