After running change-user-password, when using password authentication from accounts.yaml, auth is changed to cookies

[Drew Freiberger]

We recently had a juju admin user password change on a controller with "juju change-user-password"

In our juju installs, we store the password in ~/.local/share/juju/accounts.yaml as plaintext. When juju change-user-password is called, it removes the password from this accounts.yaml file and creates a macaroon in the ~/.local/share/juju/cookies/ directory, but that cookie expires in ~8 hours. This then leaves an admin returning to use the shared account without access to manage the cloud w/out knowing this password.

I'd like to request that if the current cloud access mechanism is via password entry in accounts.yaml, that change-user-password updates the password in that file rather than removing the password from the file.

To Reproduce:

juju change-user-password
<enter new password such as 'foobar'>
<again>
vi ~/.local/share/juju/accounts.yaml
Added "password: foobar" under the controllers-><controllername> heading at same level as "user: admin".
Remove any relevant macaroon from ~/.local/share/juju/cookies/<controllername>.json
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-user-password" again to something like "george", you'll find that the password: attribute is removed from accounts.yaml and you'll have a new macaroon valid for 8 hours in the cookies directory.

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.

[Richard Harding (rharding)]

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.