Charms and admin passwords

[Cory Johns]

Hi all,

I was wondering about the right way to handle admin passwords for
user-facing apps in a charm?

Obviously, we don't want to have static default admin passwords, as that
leads to insecure default setups.  However, I haven't seen an easy, secure
way for the charm to communicate a password up to the admin, nor an easy,
secure way for the admin to communicate a desired password down to the
charm.

At first, having a config option for the admin password comes to mind, but
since those values are stored in plain-text and easily retrieved, this
seems insecure.  It also has the problem of a default value for the option
and what to do if the juju user doesn't change it.

The option that I am going with for my charm is to generate a random
password and include a script in the charm that can be called via `juju
run` to set the password to something known, at a later point.  This is
secure, and relatively easy to use from the command-line (if properly
documented in the README), but doesn't work at all with the GUI.

A password type for config values could make the config option route a
possibility.  However, even with a password type, there's still some
difficulty in that the config-changed hook would need to be able to read
the field at least once, and probably more than once, since the charm might
not be in a state in which it can reasonably do anything with the password
value when the option is first set (e.g., it might need to wait for a
database to be related and set up), yet we would still want to restrict the
value from being read and stored in plain-text.

Alternatively, the proposals for charm "actions" as first-order constructs
would make the erstwhile `juju run` method viable and work well from the
GUI.  This seems like the better approach, to me, but "actions" is also a
larger change to support, and there's something to be said for the ease of
the use case of just giving a password along with other config values when
adding a charm via the GUI.

So, how are passwords handled in a secure fashion currently, and is there
an approach I'm not thinking of here?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20140519/11a75837/attachment.html>