[openstack-dev] [oslo.config] Encrypt the sensitive options

Morgan Fainberg morgan.fainberg at gmail.com
Mon May 2 18:41:58 UTC 2016


On Mon, May 2, 2016 at 11:32 AM, Adam Young <ayoung at redhat.com> wrote:

> On 04/26/2016 08:28 AM, Guangyu Suo wrote:
>
> 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.
>
> 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.
>
> Of course, this feature should be default closed. Any ideas?
>
>
> PKI.  Each service gets a client certificate that they use, signed by a
> selfsigned CA on the controller node, and uses the Tokenless/X509 Mapping
> in Keystone to identify itself.
>
> Do not try to build a crypto system around passwords.  None of us are
> qualified to do that.
>
>
++ Rule 1 of crypto - don't roll your own system.


> We should be able to kill explicit service users and use X509 any way.
>
>
++ We should be moving towards token-less auth for service users where
possible. This doesn't mitigate the need to cert/key manage properly (NSS?
devops-y things, etc)


> Kerberos would work, too, for deployments that prefer that form of
> Authentication.  We can document this, but do not need to implement.
>
>
Never hurts to have alternatives.


> Certmonger can manage the certificates for us.
>
> Anchor can act as the CA for deployments that want something more than
> selfsigned, but don't want to go with a full CA.
>
>
I'd be in favor of anchor being the default (devstack? gate? "best
practices") choice for 'service users' over the full CA, but in either case
as long as we have an easy-to-use-low-barrier-to-entry-well-formed-system,
we're on the right path.


>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribehttp://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/a58ddca2/attachment.html>


More information about the OpenStack-dev mailing list