Open Stack

On Tue, Apr 26, 2016 at 3:32 PM, Daniel P. Berrange <berrange at redhat.com>
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.
>
It's not a security problem if your config files have the proper
permissions.


> > >
> > > 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.
>
The issue here is to find a "well secured place". We should not only move
the problem somewhere else.


> > >
> > > 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.
>
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).


>
> Regards,
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org              -o-             http://virt-manager.org
> :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc
> :|
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160426/d8027c96/attachment.html>