2016-04-26 10:33 GMT-05:00 Daniel P. Berrange <berra...@redhat.com>: > On Tue, Apr 26, 2016 at 04:24:52PM +0200, Jordan Pittier wrote: > > On Tue, Apr 26, 2016 at 3:32 PM, Daniel P. Berrange <berra...@redhat.com > > > > wrote: > > > > > On Tue, Apr 26, 2016 at 08:19:23AM -0500, Doug Hellmann wrote: > > > > Excerpts from Guangyu Suo's message of 2016-04-26 07:28:42 -0500: > > > > > Hello, oslo team > > > > > > > > > > For now, some sensitive options like password or token are > configured > > > as > > > > > plaintext, anyone who has the priviledge to read the configure file > > > can get > > > > > the real password, this may be a security problem that can't be > > > > > unacceptable for some people. > > > > > It's not a security problem if your config files have the proper > > permissions. > > Permissions on disk is only one of many problems with storing passwords > in config files. When people report bugs to upstream or vendors they > frequently have to provide their configuration files as attachments to > the bug. This easily compromises their passwords unless they remember > to scrub them before attaching to the bug, which experiance shows most > people forgot todo. We've had countless issues with code inside openstack > logging variables which contain passwords, causing us to come up with > stupid hacks to try to scrub passwords before logging. If you want to > change your database password, you now forced to update the config > files on 100's or 1000's of nodes. Sure mgmt tools can automate this > but it would be better if the problem didn't exist in the first place > > > > > > So the first solution comes to my mind is to encrypt these options > when > > > > > configuring them and decrypt them when reading them in oslo.config. > > > This is > > > > > a bit like apache/openldap did, but the difference is these > softwares > > > do a > > > > > salt hash to the password, this is a one-way encryption that can't > be > > > > > decrypted, these softwares can recognize the hashed value. But if > we do > > > > > this work in oslo.config, for example the admin_password in > > > > > keystone_middleware section, we must feed the keystone with the > > > plaintext > > > > > password which will be hashed in keystone to compare with the > stored > > > hashed > > > > > password, thus the encryped value in oslo.config must be decryped > to > > > > > plaintext. So we should encrypt these options using symmetrical or > > > > > unsymmetrical method with a key, and put the key in a well secured > > > place, > > > > > and decrypt them using the same key when reading them. > > > > > The issue here is to find a "well secured place". We should not only move > > the problem somewhere else. > > There is already barbican which could potentially fill that role: > > "Barbican is a REST API designed for the secure storage, provisioning > and management of secrets such as passwords, encryption keys and X.509 > Certificates." [1] > > On startup a process, such as nova, could contact barbican to retrieve > the credentials it should use for authenticating with each other service > that requires a password. >
Barbican is designed for tenancy, right? And it must configure the keystone_authtoken related options to work with keystone, and this will have a dependency problem as Doug mentioned. > > > > > > > > > > Of course, this feature should be default closed. Any ideas? > > > > > > > > Managing the encryption keys has always been the issue blocking > > > > implementing this feature when it has come up in the past. We can't > have > > > > oslo.config rely on a separate OpenStack service for key management, > > > > because presumably that service would want to use oslo.config and > then > > > > we have a dependency cycle. > > > > > > > > So, we need a design that lets us securely manage those encryption > keys > > > > before we consider adding encryption. If we solve that, it's then > > > > probably simpler to encrypt an entire config file instead of worrying > > > > about encrypting individual values (something like how ansible vault > > > > works). > > > > > > IMHO encrypting oslo config files is addressing the wrong problem. > > > Rather than having sensitive passwords stored in the main config > > > files, we should have them stored completely separately by a secure > > > password manager of some kind. The config file would then merely > > > contain the name or uuid of an entry in the password manager. The > > > service (eg nova-compute) would then query that password manager > > > to get the actual sensitive password data it requires. At this point > > > oslo.config does not need to know/care about encryption of its data > > > as there's no longer sensitive data stored. > > > > This looks complicated. I like text files that I can quickly view and > edit, > > if I am authorized to (through good old plain Linux permissions). > > As explained earlier, passwords in text files is awful for both security > and managability at a large scale. File permissions alone cannot solve > that problem. > > Regards, > Daniel > > [1] https://wiki.openstack.org/wiki/Barbican > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ > :| > |: http://libvirt.org -o- http://virt-manager.org > :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ > :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc > :| > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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