<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 26, 2016 at 3:32 PM, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.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">On Tue, Apr 26, 2016 at 08:19:23AM -0500, Doug Hellmann wrote:<br>
> Excerpts from Guangyu Suo's message of 2016-04-26 07:28:42 -0500:<br>
> > 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></div></div></blockquote><div>It's not a security problem if your config files have the proper permissions. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
> ><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></div></div></blockquote><div>The issue here is to find a "well secured place". We should not only move the problem somewhere else.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
> ><br>
> > Of course, this feature should be default closed. Any ideas?<br>
><br>
> 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>
<br>
</div></div>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><div>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).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
Daniel<br>
<span class="HOEnZb"><font color="#888888">--<br>
|: <a href="http://berrange.com" rel="noreferrer" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" rel="noreferrer" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" rel="noreferrer" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" rel="noreferrer" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" rel="noreferrer" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" rel="noreferrer" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" rel="noreferrer" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" rel="noreferrer" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>