Open Stack

On Tue, Apr 26, 2016 at 10:57 AM, Joshua Harlow <harlowja at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160426/d820988e/attachment.html>