Charms and admin passwords

[Stuart Bishop]

On 22 May 2014 03:27, Matt Bruzek <matthew.bruzek at canonical.com> wrote:

> 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?

>> 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.

For a charm to make use of a password provided by juju, it needs to be
in plain-text (if it was encrypted somehow, there is exactly the same
issue distributing the key). There is also the issue of adding new
units to your service; they will need the password too, so unless the
password persists somewhere accessible in plain-text, you would need
to encrypt it and store it in a shared database (possibly your peer
relation could be this shared database).

I think juju will log your password if you use 'juju run'. You could
avoid this with 'echo password | juju ssh foo/0 newpass', but then you
are stuck doing each unit individually. Any approach using a config
item has this problem too I think.

Hmm... I think we would need to make 'echo payload | juju run
--service foo cmd' work, which also might be an interesting approach
for solving the fat charms/charm payloads issue.



>> 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?

You could make the problem go away if you have a web service that
supports an OpenID identifier or similar for administrative
authentication. If you use our SSO, you could specify a Launchpad team
name in the config who gets administrative access.

-- 
Stuart Bishop <stuart.bishop at canonical.com>