Sharing environments - a proposal

[roger peppe]

On 30 May 2014 10:59, William Reade <william.reade at canonical.com> wrote:
> I don't think there is any reason to drop ca-cert from the .jenv for a
> singular environment; when you're first connecting to any state server you
> certainly need verification that it's really who it says it is. The exact
> source of the trust depends on the scenario, for sure, but in the singular
> state-server case a .jenv is the simple sane way to do it IMO.

If we have a .jenv then a substantial part of Tim's suggestion is no
longer necessary.

How about two new subcommands?

juju export-env [ -o <file.jenv> ] [--provider-keys] environment

   export-env exports information identifying an environment
   to the given file. The exported information does not include
   the client user name or password. The API address information
   may become stale over time.

   The bootstrap configuration (with provider-keys) will not be
   exported unless the --provider-keys flag is given.

juju import-env [-u user] [-p password] file.jenv environment

   import-env imports the given environment file, giving
   it the given local environment name. The environment
   will be contacted to verify the environment information
   and refresh the API endpoint cache. If there is no
   client user name or password, the user will be prompted
   for them.


The main problem I see with this is it's possible to have
two local .jenv files referring to the same environment - if
one is destroyed, the other will still remain.
(Of course, this is actually a potential issue even now).
A better way of structuring things, perhaps, might be
to index local environment information by environment UUID,
keeping names as aliases only.

  cheers,
    rog.

>
>
> On Fri, May 30, 2014 at 9:32 AM, roger peppe <roger.peppe at canonical.com>
> wrote:
>>
>> On 30 May 2014 06:50, John Meinel <john at arbash-meinel.com> wrote:
>> > ...
>> >
>> >>
>> >> > 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)
>> >
>> >
>> > So we could certainly make it safe once you have securely connected 1
>> > time.
>> > In that we can ask what the CA cert is for this environment, and then
>> > make
>> > sure all future connections are validated with that CA.
>>
>> Yes. You have to work out how you're going to connect securely that
>> first time though. How do you propose to do that?
>>
>>   cheers,
>>     rog.
>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>