On Tue, Apr 26, 2016 at 10:57 AM, Joshua Harlow <harlo...@fastmail.com> wrote:
> Daniel P. Berrange 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. >>>> >>>> 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. >>>> >>>> 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. >> > > That reminds me of the internals of the keyring library that some of the > openstack clients used to use. It would integrate with mac os keychain, > linux secret services and things like kwallet and windows secret services > via its abstractions (code @ > https://github.com/jaraco/keyring/tree/9.0/keyring/backends); perhaps > oslo.config could integrate with that library (and overcome the issues that > the python-*-client libraries had with using it/ejecting support for it). > > There are probably other similar libraries with similar backends that > could be used also (but that's the one I know about). A pluggable backend > might be nice since then u can integrate with your own secret service (for > example I know yahoo has there own similar service). > > We should not integrate with keyring. It has caused a large number of issues and has very bad dependency changes (that tend to change in weird ways). We should/could use something else. --Morgan
__________________________________________________________________________ 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