Open Stack

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.

> > > >
> > > > 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 :|