Open Stack

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>