On 04/18/2016 10:29 AM, Brant Knudson wrote:
On Fri, Apr 15, 2016 at 9:04 PM, Adam Young <ayo...@redhat.com
<mailto:ayo...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
