Open Stack

On Tue, Apr 26, 2016 at 4:25 PM, Guangyu Suo <yugsuo at gmail.com> wrote:

> I think there is a little misunderstanding over here, the key point about
> this problem is that you store your password as *plaintext* in the
> configuration file, maybe this password is also the password of many other
> systems. You can't stop the right person to do the right thing, if someone
> gets the encryped password, and he can also get into
>

We can engineer things for best practices. If this password is the "same as
many other systems" we need to have more conversations on why that is the
case and how we can encourage people to do the correct/best practice thing
and not share passwords. I know the exposure of a password to your
infrastructure control plane is a big thing, but shared passwords simply is
not something we should be engineering specific solutions for, instead we
should document the best practices and why they are important.


> the box, then he is the right person, just like somebody gets your
> password through "brute force" attack, you can't stop him to do the right
> thing. If someone gets the entryped password, but he can not get into the
> box, he can do nothing, and this is our goal. So I think split the global
> configuration file to "general" and "secure" files, and encrypt the secure
> file is the right way to do this.
>
>
> 2016-04-26 16:05 GMT-05:00 Doug Hellmann <doug at doughellmann.com>:
>
>> Excerpts from Morgan Fainberg's message of 2016-04-26 10:17:30 -0500:
>> > On Tue, Apr 26, 2016 at 9:24 AM, Jordan Pittier <
>> jordan.pittier at scality.com>
>> > 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.
>> > >
>> > >
>> > >> > >
>> > >> > > 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
>> > >>
>> > >
>> > oslo.config already supports multiple configuration files. As long as
>> the
>> > configuration sections are appropriately combined (they should be? if
>> not
>> > there is a gap), we can rely on that feature to handle the split between
>> > "secure" options and "general options". I am strongly against encrypting
>> > the whole file (it doesn't really solve the problem that well). There
>> is a
>>
>> Yes, sorry, I wasn't clear but I assumed this was understood to be how we
>> would do it -- have a secure file and encrypt that. Whether any single
>> deployment decides to split that file or not is up to them. My point
>> was just that we should treat the file, not an individual option within
>> the file.
>>
>> > history of having "secure" files and "generally viewable" config files
>> > (prior art, such as gerrit having a "general" config and a "secure"
>> config)
>> > in many deployments. This also could be handled (decrypting the "secure"
>> > file) by the startup scripts (systemd is *very* good at order of
>> > operations/wait for signals); use of ramdisk and proper POSIX (and
>> SELinux)
>> > attributes can limit concerns about access of the "secure" file (mix in
>> > some ramdisk, and a reboot of the system/systemd stopping the service,
>> can
>> > also clear the "sensitive" data). Expect that the data is ultimately
>> > readable via direct memory access if the standard "best" practices are
>> > insufficient.
>> >
>> > There was already talk of having oslo.config supporting an "external
>> store"
>> > (direct access to hiera or similar?) for certain options. That may be
>> > significantly better (and ultimately more controlled) than trying to
>> wedge
>> > encryption into configuration files.
>>
>> It might. It has the same problem, though, of protecting the information
>> used to access the values. Presumably the config library would need a
>> URL and credentials to access the remote data. If that's visible, the
>> data is as vulnerable as if it was just in the local file, right?
>>
>> Doug
>>
>> __________________________________________________________________________
>> 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
>>
>
>
> __________________________________________________________________________
> 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/20160502/5f7a28fb/attachment.html>