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. > > > > > > 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. > > > > > > 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). > > Regards, > Daniel > -- > |: 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
