After running change-user-password, when using password authentication from accounts.yaml, auth is changed to cookies
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
juju-core |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
We recently had a juju admin user password change on a controller with "juju change-
In our juju installs, we store the password in ~/.local/
I'd like to request that if the current cloud access mechanism is via password entry in accounts.yaml, that change-
To Reproduce:
juju change-
<enter new password such as 'foobar'>
<again>
vi ~/.local/
Added "password: foobar" under the controllers-
Remove any relevant macaroon from ~/.local/
run 'juju status'
you should now have 'null' within the cookie .json file and should have authed via the password in accounts.yaml.
Now, if you "juju change-
It would be useful for continuity sake for "george" to be stored in the accounts.yaml file if "foobar" was in there previously, instead of dropping a new cookie.
This is by design. When you first bootstrap the admin user hasn't provided any password details. If a password is set it should not be recorded where it could be reached. It's now a "something you know" part of security and so it's like other services when you submit a username and a password it's not documented and must be something that you know.
Best practice would be to create new user accounts for different users and grant them superuser access so that they behave as admin users but have unique accounts that can be audited individually.