[openstack-dev] [keystone] Token providers and Fernet as the default
Monty Taylor
mordred at inaugust.com
Tue May 3 14:59:21 UTC 2016
On 05/03/2016 08:55 AM, Clint Byrum wrote:
> Excerpts from Steve Martinelli's message of 2016-05-02 19:56:15 -0700:
>> Comments inline...
>>
>> On Mon, May 2, 2016 at 7:39 PM, Matt Fischer <matt at mattfischer.com> wrote:
>>
>>> On Mon, May 2, 2016 at 5:26 PM, Clint Byrum <clint at fewbar.com> wrote:
>>>
>>>> Hello! I enjoyed very much listening in on the default token provider
>>>> work session last week in Austin, so thanks everyone for participating
>>>> in that. I did not speak up then, because I wasn't really sure of this
>>>> idea that has been bouncing around in my head, but now I think it's the
>>>> case and we should consider this.
>>>>
>>>> Right now, Keystones without fernet keys, are issuing UUID tokens. These
>>>> tokens will be in the database, and valid, for however long the token
>>>> TTL is.
>>>>
>>>> The moment that one changes the configuration, keystone will start
>>>> rejecting these tokens. This will cause disruption, and I don't think
>>>> that is fair to the users who will likely be shown new bugs in their
>>>> code at a very unexpected moment.
>>>>
>>>
>>> This will reduce the interruption and will also as you said possibly catch
>>> bugs. We had bugs in some custom python code that didn't get a new token
>>> when the keystone server returned certain code, but we found all those in
>>> our dev environment.
>>>
>>> From an operational POV, I can't imagine that any operators will go to
>>> work one day and find out that they have a new token provider because of a
>>> new default. Wouldn't the settings in keystone.conf be under some kind of
>>> config management? I don't know what distros do with new defaults however,
>>> maybe that would be the surprise?
>>>
>>
>> With respect to upgrades, assuming we default to Fernet tokens in the
>> Newton release, it's only an issue if the the deployer has no token format
>> specified (since it defaulted to UUID pre-Newton), and relied on the
>> default after the upgrade (since it'll switches to Fernet in Newton).
>>
>
> Assume all users are using defaults.
>
>> I'm glad Matt outlines his reasoning above since that is nearly exactly
>> what Jesse Keating said at the Fernet token work session we had in Austin.
>> The straw man we come up with of a deployer that just upgrades without
>> checking then config files is just that, a straw man. Upgrades are well
>> planned and thought out before being performed. None of the operators in
>> the room saw this as an issue. We opened a bug to prevent keystone from
>> starting if fernet setup had not been run, and Fernet is the
>> selected/defaulted token provider option:
>> https://bugs.launchpad.net/keystone/+bug/1576315
>>
>
>
> Right, I responded there, but just to be clear, this is not about
> _operators_ being inconvenienced, it is about _users_.
I have confusion.
token format isn't really a thing users care about, like, ever. A token
is an opaque blob you get from authenticating, and sometimes it expires
and you have to reauthenticate. That re-auth must be accounted for in
all of your user code, or else you'll have random sads (if you use
keystoneauth it's handled for you, if you don't, it's on you_
If the operator rolls out fernet where it was uuid, the worst thing that
will happen is that a token will "expire" before it needed to. As much
as I'm normally a fountain for user indignation and rage ... I'm not
sure end-users have any issues here.
>> For all new installations, deploying your cloud will now have two extra
>> steps, running "keystone-manage fernet_setup" and "keystone-manage
>> fernet_rotate". We will update the install guide docs accordingly.
>>
>> With all that said, we do intend to default to Fernet tokens for the Newton
>> release.
>>
>
> Great! They are supremely efficient and I love that we're moving
> forward. However, users really do not care about something that just
> makes the operator's life easier if it causes all of their stuff to blow
> up in non-deterministic ways (since their new jobs won't have that fail,
> it will be a really fun day in the debug chair).
>
>>>
>>>
>>>>
>>>> I wonder if one could merge UUID and Fernet into a provider which
>>>> handles this transition gracefully:
>>>>
>>>> if self._fernet_keys:
>>>> return self._issue_fernet_token()
>>>> else:
>>>> return self._issue_uuid_token()
>>>>
>>>> And in the validation, do the same, but also with an eye toward keeping
>>>> the UUID tokens alive:
>>>>
>>>> if self._fernet_keys:
>>>> try:
>>>> self._validate_fernet_token()
>>>> except InvalidFernetFormatting:
>>>> self._validate_uuid_token()
>>>> else:
>>>> self._validate_uuid_token()
>>>>
>>>
>> This just seems sneaky/wrong to me. I'd rather see a failure here than
>> switch token formats on the fly.
>>
>
> You say "on the fly" I say "when the operator has configured things
> fully".
>
> Perhaps we have different perspectives. How is accepting what we
> previously emitted and told the user would be valid sneaky or wrong?
> Sounds like common sense due diligence to me.
I agree - I see no reason we can't validate previously emitted tokens.
But I don't agree strongly, because re-authing on invalid token is a
thing users do hundreds of times a day. (these aren't oauth API Keys or
anything)
> Anyway, the idea could use a few kicks, and I think perhaps a better
> way to state what I'm thinking is this:
>
> When the operator has configured a new token format to emit, they should
> also be able to allow any previously emitted formats to be validated to
> allow users a smooth transition to the new format. We can then make the
> default behavior for one release cycle to emit Fernet, and honor both
> Fernet and UUID.
>
> Perhaps ignore the other bit that I put in there about switching formats
> just because you have fernet keys. Let's say the new pseudo code only
> happens in validation:
>
> try:
> self._validate_fernet_token()
> except NotAFernetToken:
> self._validate_uuid_token()
>
> I fight for the users -- Tron
>
> __________________________________________________________________________
> 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
>
More information about the OpenStack-dev
mailing list