On 22 May 2014 03:27, Matt Bruzek <[email protected]> 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 <[email protected]> -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
