[openstack-dev] [Keystone] State of Fernet Token deployment
Adam Young
ayoung at redhat.com
Mon Apr 18 22:14:58 UTC 2016
On 04/18/2016 10:29 AM, Brant Knudson wrote:
>
>
> On Fri, Apr 15, 2016 at 9:04 PM, Adam Young <ayoung at redhat.com
> <mailto:ayoung at redhat.com>> wrote:
>
> 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.
>
> Trusts for V2 tokens were not working correctly. Relatively easy
> fix. https://review.openstack.org/#/c/278693/ 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.
>
> 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.
>
> 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.
>
>
> 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.
>
> 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.
>
> 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.
>
>
> There's a review to change devstack to default to fernet:
> https://review.openstack.org/#/c/195780/ . 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.
>
> 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.
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.
>
> - Brant
>
>
>
> __________________________________________________________________________
> 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/20160418/b2885243/attachment.html>
More information about the OpenStack-dev
mailing list