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