<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 2, 2016 at 11:32 AM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div><div class="h5">
<div>On 04/26/2016 08:28 AM, Guangyu Suo
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hello, oslo team
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Of course, this feature should be default closed. Any
ideas?</div>
</div>
</blockquote>
<br></div></div>
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.<br>
<br>
Do not try to build a crypto system around passwords. None of us
are qualified to do that.<br>
<br></div></blockquote><div><br></div><div>++ Rule 1 of crypto - don't roll your own system.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
We should be able to kill explicit service users and use X509 any
way.<br>
<br></div></blockquote><div><br></div><div>++ 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)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
Kerberos would work, too, for deployments that prefer that form of
Authentication. We can document this, but do not need to implement.<br>
<br></div></blockquote><div><br></div><div>Never hurts to have alternatives.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
Certmonger can manage the certificates for us.<br>
<br>
Anchor can act as the CA for deployments that want something more
than selfsigned, but don't want to go with a full CA.<span class=""><br>
<br></span></div></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span class="">
<blockquote type="cite">
<div dir="ltr">
</div>
<br>
<fieldset></fieldset>
<br>
<pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>