Open Stack

Excerpts from Fox, Kevin M's message of 2017-03-15 00:10:24 +0000:
> +1 for having the option. I think in general it is a great idea.
> 
> I think there are some devils in the implementation. How do you prevent
> a service from getting way more secrets then it strictly needs? Maybe
> this is the start of an activity thought to split out all secrets from
> config, which would be an awesome thing to do. Having secrets commingled
> with config has always rubbed me the wrong way.
> 

You'll always have at least one secret around that grants access to
the others.  Whether it is the root SSH key, or the TLS private key that
grants etcd.

This is where we might diverge into the key management discussion so we
can at least have audit trails. With config only in files, you could
use something like CloudKeep (defunct?) that would effectively make
config-not-secrets into templates that would be filled with secrets when
read from a fifo backed by a daemon that fetched secrets from Barbican.

But, we could, instead, have less moving parts by having oslo.config
provide the option to just use castellan (or oslo.keymanager if we do
rename it) to handle key management of a TLS private key for etcd auth,
and maybe an additional private key for decryption of secrets like db
passwords and such. If you don't have Barbican, you can either a) write
a castellan driver for your existing key manager, b) help finish the
Hashicorp Vault castellan driver that Robert Clark was hacking on in
ATL, or c) use the insecure on-disk one that basically makes it work
just like your httpd /etc/httpd/ssl.key dir.

Whatever is done, there's a lot of operator-unfriendliness if it's not
accompanied by nice tools to read the effective configuration. Something
like `/opt/openstack/bin/keystone-manage show-config`.

> The other issue I can think of is overridability. the current
> separate file per instantiated service has some flexibility that a
> simple implementation of just looking in etcd for the keys may not work
> for. Some, look here first, then look for overrides over here thing
> would work though.
> 

That was addressed in the original I think. This would work:

/opt/openstack/bin/nova-conductor --config=/etc/nova/nova.conf --etcd-url=http://foo:94895/common --etcd-url=https://foo:94895/my-hostname

As with current oslo.config behavior, later urls would override earlier
ones. I don't think anybody's suggesting doing away with configs. Just
that having them in some central micro service means having less mutable
things to worry about in your images, which is why Kolla's asking so
nicely. :)