modify password of admin or service tenant user
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Dashboard (Horizon) |
Confirmed
|
Wishlist
|
Unassigned | ||
OpenStack Identity (keystone) |
Invalid
|
Wishlist
|
Unassigned |
Bug Description
/* i follow hastexo's blog and install openstack essex and also check devstack's configuration settings */
when i login horizon with admin role, so i can use the *admin* panel, and then modify user information by *edit* user from user list. but there is a problem (i think it is a bug) when modify password of special user *admin* , *nova* and *glance*
configuration file: /etc/glance/
when i modify user's password of nova, glance (if configuration file set to these user, otherwise if set to admin, then modify admin'a password will raise this problem), the corresponding service will no be able to be authenticated and fail to work.
i guess horizon uses keystoneclient's api *update_password* (command line api is user-password-
but i think if there is a feature (like modify user's password) is offerd by horizon, or at least user can notice this feature on horizon pages, then we should make sure this feature works right, if that is out of our control, at least warn the adminitrator by pop up a *NOTICE* or *WARNING* to let admin modify config files on host
/* i have searched the bugs list and answer list for this problem */
if there is a way to put a trigger after keystone update password successfully to run a script to modify password, then this problem can be solved easily but requires some addtional work on install
Changed in keystone: | |
importance: | Undecided → Wishlist |
Changed in keystone: | |
status: | New → Confirmed |
I agree 100% on the problem. Unfortunately for Horizon there is no way to identify the service users or projects other than by name, which is configurable and done by convention, not enforced. That means we can't rationally warn an admin about those accounts because we can't guarantee they are or aren't the right ones. There's also no API to update the config files for the other services, that currently has to be done manually.
When the service accounts were first created I strongly argued for filtering them out of the API calls. I think they should be internal and untouchable, not ever exposed.
At the very least Keystone needs some kind of added identifier on both the users and the accounts before anything meaningful can be done with them.