Sharing environments - a proposal

[roger peppe]

[This discussion originated on juju-dev at lists.ubuntu.com - I'm replying
to juju-dev at lists.canonical.com because it touches on JAAS issues]

On 29 May 2014 06:46, Tim Penhey <tim.penhey at canonical.com> wrote:
> Hi folks,
>
> The onyx team is dealing with sharing environments between multiple
> people.  Currently how this is handled is that often there is a shared
> file system somewhere that contains the environments directory, and
> people use juju from there.
>
> We are in the middle of dealing with simple user management tasks, so we
> can at least have multiple different user identities connecting to an
> environment.  Initially all users that can connect to an environment
> will have admin privileges.
>
> We want to ease the way that we share environments.

I totally agree that this is an important issue, and it's great that you
have been thinking constructively towards possible solutions. This
is an excellent place to start considering this area, thanks.

> The initial work that has been signed off includes the ability for an
> existing admin to create a new user in state server and to create a
> .jenv file that is sufficient for that user to connect to the
> environment.  This is half the problem solved.
>
> What we want to do is make it easy for a beginner user to start using
> someone else's environment.
>
> Let's say that I have an existing environment, and I want to allow Eric
> access to that environment.
>
> I'll run the command:
>   $ juju user add eric "Eric the Viking" --output=foo-eric.jenv
>
> This will create a .jenv file that contains what is needed to allow Eric
> to connect to my environment.  I now email that file to Eric (or pass it
> to him on a USB key).
>
> Now what?
>
> Let's also assume that Eric isn't very familiar with juju, and has just
> installed it.
>
> The proposal:
>
> We add a command [1]
>
>    juju connect
>
> that makes it easy for Eric to connect to the environment.  Now ideally
> where we'd like to get to is the following:
>
>    juju connect eric@<api-endpoint> [<env uuid>]
>
> Where Eric wouldn't need the .jenv file at all, but this would connect
> to the API, prompt for a password, and then look for the environment
> identified by the uuid specified.  For current environments where we
> have only one environment supported by the state server which has the
> api server that is being connected to, the uuid would be optional, but
> if it is specified, the command should fail if the uuids don't match.
>
> PROBLEM: right now all connections to the api server are secured with
> TLS and the client-cert.

As John says, this isn't actually true - connections are secured with
a server cert and a password.

Unfortunately I believe it is impossible to lose either one of these
without rendering juju fundamentally insecure against man-in-the-middle
attacks.

If we take the approach you suggest, that's what we'd end up with. Anyone
that can subvert the network between the "juju connect" command and the
API server could pretend to be the desired environment, forwarding and
changing requests as maliciously as it liked. There's no way that the
client can know that it's talking to the middle-man, and no way for the
server to know that it's not being addressed by the expected client.

There is also the problem that the "endpoint" can change - with HA the
actual API addresses can and will change (and there are many
possible addresses too - we try to connect to all of them; that's
not very convenient for a small piece of information to copy
and paste)

The only reasonable solution that I can see is to use some kind of
environment broker - a third party web site with a well known DNS name
(and a trusted certificate issued to speak for that name) that stores
.jenv files for people.

Then the user can make a secure connection to that site to fetch a .jenv
file that will allow them to make secure connections to their own juju
environment.

I believe that JAAS (or some component of JAAS) could and probably should
potentially fulfil that role, even for environments that it does not
manage itself.

There is definitely a discussion to be had about whether the service
should have plain-text access to the .jenv files (and therefore the
user's provider keys) of every juju environment stored in it. That is
possible to avoid (along the lines of lastpass.com) which would avoid
creating a single point of security failure for every juju environment,
but it's a decision that needs to be thought about. I feel it would
be nice to avoid building a system that gave the NSA easy and automatic
root access to any juju environment.

As a first step, it would be quite feasible to make it possible for juju
to be able to access an external service to fetch and store .jenv files.
FWIW I actually built a prototype that illustrated this some time ago.

With such a service, we could imagine an environment variable or
configuration file setting that points juju towards the service, allowing
any juju operation to work seamlessly in conjunction with remotely created
environments. .jenv files could be cached for correct operation even if
the service is down.

We would probably want to split the .jenv file, splitting out
user credentials from environment id/public key identification;
then some kind of a "juju login" or "juju connect" operation similar to your
description (I prefer the former name FWIW) could bring the two together.

How does that sound?

  cheers,
    rog.