<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 26, 2016 at 10:57 AM, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@fastmail.com" target="_blank">harlowja@fastmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Daniel P. Berrange wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Apr 26, 2016 at 08:19:23AM -0500, Doug Hellmann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Excerpts from Guangyu Suo's message of 2016-04-26 07:28:42 -0500:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello, oslo team<br>
<br>
For now, some sensitive options like password or token are configured as<br>
plaintext, anyone who has the priviledge to read the configure file can get<br>
the real password, this may be a security problem that can't be<br>
unacceptable for some people.<br>
<br>
So the first solution comes to my mind is to encrypt these options when<br>
configuring them and decrypt them when reading them in oslo.config. This is<br>
a bit like apache/openldap did, but the difference is these softwares do a<br>
salt hash to the password, this is a one-way encryption that can't be<br>
decrypted, these softwares can recognize the hashed value. But if we do<br>
this work in oslo.config, for example the admin_password in<br>
keystone_middleware section, we must feed the keystone with the plaintext<br>
password which will be hashed in keystone to compare with the stored hashed<br>
password, thus the encryped value in oslo.config must be decryped to<br>
plaintext. So we should encrypt these options using symmetrical or<br>
unsymmetrical method with a key, and put the key in a well secured place,<br>
and decrypt them using the same key when reading them.<br>
<br>
Of course, this feature should be default closed. Any ideas?<br>
</blockquote>
Managing the encryption keys has always been the issue blocking<br>
implementing this feature when it has come up in the past. We can't have<br>
oslo.config rely on a separate OpenStack service for key management,<br>
because presumably that service would want to use oslo.config and then<br>
we have a dependency cycle.<br>
<br>
So, we need a design that lets us securely manage those encryption keys<br>
before we consider adding encryption. If we solve that, it's then<br>
probably simpler to encrypt an entire config file instead of worrying<br>
about encrypting individual values (something like how ansible vault<br>
works).<br>
</blockquote>
<br>
IMHO encrypting oslo config files is addressing the wrong problem.<br>
Rather than having sensitive passwords stored in the main config<br>
files, we should have them stored completely separately by a secure<br>
password manager of some kind. The config file would then merely<br>
contain the name or uuid of an entry in the password manager. The<br>
service (eg nova-compute) would then query that password manager<br>
to get the actual sensitive password data it requires. At this point<br>
oslo.config does not need to know/care about encryption of its data<br>
as there's no longer sensitive data stored.<br>
</blockquote>
<br></div></div>
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 @ <a href="https://github.com/jaraco/keyring/tree/9.0/keyring/backends" rel="noreferrer" target="_blank">https://github.com/jaraco/keyring/tree/9.0/keyring/backends</a>); 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).<br>
<br>
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).<br>
<br></blockquote><div><br></div><div>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.<br><br></div><div>--Morgan <br></div></div></div></div>