Charms and admin passwords

[Matt Bruzek]

Hey Cory,

I can see a need for "password" type configuration options. To designate
sensitive configuration data that Juju should not display the value of once
the value is set.

The problem is the charms still need to get at the string so the charm code
can do the application specific manipulations with it.

One charm requires some configuration options are base64 encoded and the
charm code decodes the base64 string on the other side but that is not
really secure either.

I agree with you that setting a "random" initial password and using a 'juju
run' command to change it later is probably the safest way right now.

Does anyone else have insight on this topic?

   - Matt Bruzek <matthew.bruzek at canonical.com>


On Mon, May 19, 2014 at 3:12 PM, Cory Johns <cory.johns at canonical.com>wrote:

> 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
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20140521/c7b4d1fd/attachment.html>