<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 18, 2016 at 5:43 PM, Matt Fischer <span dir="ltr"><<a href="mailto:matt@mattfischer.com" target="_blank">matt@mattfischer.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Apr 18, 2016 at 12:52 PM, Morgan Fainberg <span dir="ltr"><<a href="mailto:morgan.fainberg@gmail.com" target="_blank">morgan.fainberg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Apr 18, 2016 at 7:29 AM, Brant Knudson <span dir="ltr"><<a href="mailto:blk@acm.org" target="_blank">blk@acm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>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></span><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.<span><font color="#888888"><br></font></span></div><span><font color="#888888"><div><br></div></font></span></div></div></div></blockquote><div><br></div></span><div>I am unsure if this is the right path, unless we consider possibly moving the key-DB for fernet into the SQL backend (possible?) notably so we can control a cluster of keystones.</div></div></div></div></blockquote><div><br></div></span><div>-1 this idea. Now we've got to figure out how to lock the DB and where will those keys/passwords go? The current model is apparently painful for devstack,  but it works fine for anyone who has an automated deployment system, or something else simple like rsync/scp can be used. Fernet keys are simpler to update/replicate than PKI certs and we didn't store those in the DB to my knowledge. Let's please not optimize this solution for devstack.</div><span class=""><div><br></div></span></div></div></div></blockquote><div><br></div><div>The DB solution is actually presented as explicitly not AIO install, it would be to solve the "cluster case" as the default value for keystone's config, since keystone can reliably share the data. DB tables can actually be locked (this is separate from select for update) and would be less painful.</div><div><br></div><div>The Devstack solution today (and looking to the future) would absolutely be file-based. No change there. This conversation is revolving around how to reduce the operational overhead of making keystone itself (not in devstack's context) default to fernet and not produce wildly (or potentially wildly) broken states.</div><div><br></div><div>This is a convo that will need to occur at the summit and we can hash out the details of what makes sense more easily. I expect the DB solution would be a bad one in any case, but before we make keystone's config default to Fernet, we need to make the non-devstack case(s) (and existing deployments) not suck.</div><div><br></div><div>--Morgan </div></div></div></div>