<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 18, 2016 at 5:14 PM, 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"><span class="">
<div>On 04/18/2016 10:29 AM, Brant Knudson
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Apr 15, 2016 at 9:04 PM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We all want Fernet to
be a reality. We ain't there yet (Except for mfish who
has no patience) but we are getting closer. The goal is
to get Fernet as the default token provider as soon as
possible. The review to do this has uncovered a few
details that need to be fixed before we can do this.<br>
<br>
Trusts for V2 tokens were not working correctly.
Relatively easy fix. <a href="https://review.openstack.org/#/c/278693/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/278693/</a>
Patch is still failing on Python 3. The tests are kindof
racy due to the revocation event 1 second granularity.
Some of the tests here have A sleep (1) in them still, but
all should be using the time control aspect of the unit
test fixtures.<br>
<br>
Some of the tests also use the same user to validate a
token as that have, for example, a role unassigned. These
expose a problem that the revocation events are catching
too many tokens, some of which should not be treated as
revoked.<br>
<br>
Also, some of the logic for revocation checking has to
change. Before, if a user had two roles, and had one
removed, the token would be revoked. Now, however, the
token will validate successful, but the response will only
have the single assigned role in it.<br>
<br>
<br>
Python 3 tests are failing because the Fernet formatter is
insisting that all project-ids be valid UUIDs, but some of
the old tests have "FOO" and "BAR" as ids. These either
need to be converted to UUIDS, or the formatter needs to
be more forgiving.<br>
<br>
Caching of token validations was messing with revocation
checking. Tokens that were valid once were being reported
as always valid. Thus, the current review removes all
caching on token validations, a change we cannot
maintain. Once all the test are successfully passing, we
will re-introduce the cache, and be far more aggressive
about cache invalidation.<br>
<br>
Tempest tests are currently failing due to Devstack not
properly identifying Fernet as the default token provider,
and creating the Fernet key repository. I'm tempted to
just force devstack to always create the directory, as a
user would need it if they ever switched the token
provider post launch anyway.<br>
<br>
</blockquote>
<div><br>
</div>
<div>There's a review to change devstack to default to
fernet: <a href="https://review.openstack.org/#/c/195780/" target="_blank">https://review.openstack.org/#/c/195780/</a>
. This was mostly to show that tempest still passes with
fernet configured. It uncovered a couple of test issues
(similar in nature to the revocation checking issues
mentioned in the original note) that have since been
fixed.<br>
<br>
</div>
<div>We'd prefer to not have devstack overriding config
options and instead use keystone's defaults. The problem
is if fernet is the default in keystone then it won't work
out of the box since the key database won't exist. One
option that I think we should investigate is to have
keystone create the key database on startup if it doesn't
exist.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br></span>
In some deployment, they should be owned by different users. In
general, a system/daemon user should not be writing to /etc. Key
rotation/etc is likely to be handled by an external Content
management system, so it might not be the right default.<br></div></blockquote><div><br></div><div>+1 Besides race conditions, this is why keystone doesn't try to "automatically" populate /etc/keystone/fernet-keys/ on startup. Fernet keys only need to be readable by the user running keystone.</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">
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>- Brant<br>
<br>
</div>
</div>
</div>
</div><span class="">
<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>
</span></blockquote>
<br>
</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>