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. :) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev