Sharing environments - a proposal

[William Reade]

On Thu, May 29, 2014 at 7:46 AM, Tim Penhey <tim.penhey at canonical.com>wrote:
>
> In the future we will have servers that we can connect to over the API
> where the connections are over SSL with signed certificates, and so the
> client will not need a client-cert for authenticated connections.
>
> So in that world, we would have similar behaviour:
>
>   $ juju connect eric at awesome.ninja fb5a2570-e6f2-11e3-ac10-0800200c9a66
>   password:
>   local environment name [foo-production]:
>
> and the result would be a file
>    $JUJU_HOME/environments/foo-production.jenv
> being written out with Eric's credentials.
>

I'm +1 on pretty much all of this, but remember that in a world of
multi-environment state servers you don't need, and probably don't want, a
local .jenv at all. You need to be able to connect to and authenticate with
a state server, sure; and so we'd need to store an address (and possibly a
cert); but once you're connected you should be able to list your
environments, and the users your identity allows you access to in those
environments.

.jenv distribution will remain necessary in certain circumstances (singular
state servers), but if you and I have identities on the same state server I
don't want to have to do *anything* other than `user add tim --identity
lp:~thumper` (or whatever scheme we're using). I can then just tell you
"hey dude, I gave you access to my environment", and probably don't even
need to tell you the UUID [0].

If you look from far enough away there's no real difference between the
situations, anyway. At the moment, your $JUJU_HOME/environments is an
implicit authentication domain (gated only on your having read access to
that directory); in the future, being able to authenticate as a particular
identity gives you access to a similar domain on a state server. The
user/environment pairs you have access to are determined on the fly
according to what users/environments actually exist in the state server,
rather than with files on disk; and there's no need to store an additional
password there, because you're already verified on that state server and
don't need to prove anything to a different remote machine; but in purpose
and impact it's pretty much the same thing.

Cheers
William

[0]  There may be problems still to be solved re securely *identifying*
that environment (could Alice maliciously give you access to her
environment in the hope that you'll leak sensitive information into it, or
implicate you in that environment's nefarious/embarrassing activity?) but
this is really just another example of the same old tension between
security and usability. We need to consider it and find a happy path, but
it's a derail from this thread, I think.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140529/aa693ef0/attachment.html>