Splitting cloud credentials out of config.Config

[roger peppe]

On 11 November 2014 03:13, Tim Penhey <tim.penhey at canonical.com> wrote:
> Hi All,
>
> This is a bit of a brain dump and thoughts around this.  Some of this
> may be a bit rambly...
>
> The cloud credentials are not needed by any worker other than the
> provisioner and firewaller (I think).  If they are, the worker should be
> one that is only run on the main state server machines.  It is not
> desirable to share these credentials with other parts of the system
> where they are not needed. In particular keeping the credentials away
> from anything that deploys charms (yes I know that it is possible to
> deploy charms on state server machines, but it doesn't make it good
> secure practice).
>
> These credentials are normally marked as "SecretAttrs" which are
> stripped from the environment's config for the watchers.
>
> If we had account credentials as a separate map, stored separately in
> the DB, and only accessible to those workers that truly needed them,
> then we'd be in a more secure position.

The two approaches above seem to me to be roughly equivalent
in terms of security. The same information is available to agents
in both scenarios, isn't it?

That's not to say that I don't support separating environment
credentials from environment config in some form. If I was to
do that, I might try to split it by concern rather than on whether
the information is "credentials".

ISTM that the information specified in the environment configuration
is actually targeted towards four distinct areas:

1) workers that need to invoke provider methods that require
full credentials, i.e. to create a new EnvironProvider instance.
2) workers that need to know other stuff that's configured
on the environment config without needing a EnvironProvider instance
(for example, logging-config)
3) workers that need to use other provider-specific methods
without requiring provider credentials; for example to find out
a machine's address.
4) clients that need to know other stuff that's configured on an
environment (for example, proxy-ssh)

Of these, 2 and 4 are actually not provider-specific at all.
There's no real need for these to be specified in the
same stanza as the other provider-specific information,
although we have the problem that
"environment configuration" and "environment provider configuration"
are one and the same from the user's point of view.

3) might not exist as a category at all. Are there any places
where we require environment config attributes (other than
the environment type) to do this kind of thing?

Let's say that, for the purposes of backward compatibility, we
keep the same user view of environment configuration,
but when creating an environment, we split it up into
a set of documents that each address one of the concerns above.

1) could still remain as an environment provider configuration,
but would lose the attributes specific to 2), 3) and 4).

2) could be named WorkerConfig, and would contain only
attributes that workers need to see, but not anything provider-specific.

3) (if it's actually needed) could be named WorkerEnvironConfig
and would contain only attributes needed for general workers
to access provider-specific methods. It might go along with
a new interface type in environs that defines those methods.

4) could be named ClientConfig and would contain only
attributes that are needed by the logic in the juju commands.

In order to avoid splitting environs/config into several very
similar pieces, it might be useful to change config.New
so that it takes a set of acceptable attributes, and a way
to derive a subset of a config. That way, we could continue
to share the code for validating and retrieving common attributes,
and split up the initial user-specified environment configuration.

Sorry, I've also brain-dumped here, but I hope that might provide
some useful food for thought.

  cheers,
    rog.