<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-04-26 10:33 GMT-05:00 Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">On Tue, Apr 26, 2016 at 04:24:52PM +0200, Jordan Pittier wrote:<br>
> On Tue, Apr 26, 2016 at 3:32 PM, Daniel P. Berrange <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>><br>
> wrote:<br>
><br>
> > 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<br>
> > as<br>
> > > > plaintext, anyone who has the priviledge to read the configure file<br>
> > can get<br>
> > > > the real password, this may be a security problem that can't be<br>
> > > > unacceptable for some people.<br>
> ><br>
> It's not a security problem if your config files have the proper<br>
> permissions.<br>
<br>
</span>Permissions on disk is only one of many problems with storing passwords<br>
in config files. When people report bugs to upstream or vendors they<br>
frequently have to provide their configuration files as attachments to<br>
the bug. This easily compromises their passwords unless they remember<br>
to scrub them before attaching to the bug, which experiance shows most<br>
people forgot todo. We've had countless issues with code inside openstack<br>
logging variables which contain passwords, causing us to come up with<br>
stupid hacks to try to scrub passwords before logging. If you want to<br>
change your database password, you now forced to update the config<br>
files on 100's or 1000's of nodes. Sure mgmt tools can automate this<br>
but it would be better if the problem didn't exist in the first place<br>
<span class=""><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.<br>
> > This is<br>
> > > > a bit like apache/openldap did, but the difference is these softwares<br>
> > 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<br>
> > plaintext<br>
> > > > password which will be hashed in keystone to compare with the stored<br>
> > 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<br>
> > place,<br>
> > > > and decrypt them using the same key when reading them.<br>
> ><br>
> The issue here is to find a "well secured place". We should not only move<br>
> the problem somewhere else.<br>
<br>
</span>There is already barbican which could potentially fill that role:<br>
<br>
"Barbican is a REST API designed for the secure storage, provisioning<br>
and management of secrets such as passwords, encryption keys and X.509<br>
Certificates." [1]<br>
<br>
On startup a process, such as nova, could contact barbican to retrieve<br>
the credentials it should use for authenticating with each other service<br>
that requires a password.<br></blockquote><div><br></div><div>Barbican is designed for tenancy, right? And it must configure the keystone_authtoken related options to work with keystone, and this will have a <span style="font-size:14px">dependency problem as Doug mentioned.</span></div><div><span style="font-size:14px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<span class=""><br>
> > > ><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>
> > 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>
><br>
> This looks complicated. I like text files that I can quickly view and edit,<br>
> if I am authorized to (through good old plain Linux permissions).<br>
<br>
</span>As explained earlier, passwords in text files is awful for both security<br>
and managability at a large scale. File permissions alone cannot solve<br>
that problem.<br>
<br>
Regards,<br>
Daniel<br>
<br>
[1] <a href="https://wiki.openstack.org/wiki/Barbican" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Barbican</a><br>
<div class=""><div class="h5">--<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>
<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>