Open Stack

2016-04-26 10:33 GMT-05:00 Daniel P. Berrange <berrange at redhat.com>:

> On Tue, Apr 26, 2016 at 04:24:52PM +0200, Jordan Pittier wrote:
> > 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.
>
> Permissions on disk is only one of many problems with storing passwords
> in config files. When people report bugs to upstream or vendors they
> frequently have to provide their configuration files as attachments to
> the bug. This easily compromises their passwords unless they remember
> to scrub them before attaching to the bug, which experiance shows most
> people forgot todo.  We've had countless issues with code inside openstack
> logging variables which contain passwords, causing us to come up with
> stupid hacks to try to scrub passwords before logging.  If you want to
> change your database password, you now forced to update the config
> files on 100's or 1000's of nodes. Sure mgmt tools can automate this
> but it would be better if the problem didn't exist in the first place
>
> > > > > 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.
>
> There is already barbican which could potentially fill that role:
>
>   "Barbican is a REST API designed for the secure storage, provisioning
>    and management of secrets such as passwords, encryption keys and X.509
>    Certificates." [1]
>
> On startup a process, such as nova, could contact barbican to retrieve
> the credentials it should use for authenticating with each other service
> that requires a password.
>

Barbican is designed for tenancy, right? And it must configure the
keystone_authtoken related options to work with keystone, and this will
have a dependency problem as Doug mentioned.


> > > > >
> > > > > 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).
>
> As explained earlier, passwords in text files is awful for both security
> and managability at a large scale. File permissions alone cannot solve
> that problem.
>
> Regards,
> Daniel
>
> [1] https://wiki.openstack.org/wiki/Barbican
> --
> |: 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/23db8fa9/attachment.html>