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?
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
