Re: [openstack-dev] [keystone] Token providers and Fernet as the default
On Tue, May 3, 2016 at 3:46 PM, Clint Byrum wrote: > Excerpts from Morgan Fainberg's message of 2016-05-03 11:13:38 -0700: > > On Tue, May 3, 2016 at 10:28 AM, Monty Taylor > wrote: > > > > > On 05/03/2016 11:47 AM, Clint Byrum wrote: > > > > > >> Excerpts from Monty Taylor's message of 2016-05-03 07:59:21 -0700: > > >> > > >>> On 05/03/2016 08:55 AM, Clint Byrum wrote: > > >>> > > > > 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) > > >>> > > >>> > > >> Sure, one should definitely not be expecting everything to always work > > >> without errors. On this we agree for sure. However, when we do decide > to > > >> intentionally induce errors for reasons we have not done so before, we > > >> should weigh the cost of avoiding that with the cost of having it > > >> happen. Consider this strawman: > > >> > > >> - User gets token, it says "expires_at Now+4 hours" > > >> - User starts a brief set of automation tasks in their system > > >>that does not use python and has not failed with invalid tokens > thus > > >>far. > > >> - Keystone nodes are all updated at one time (AMAZING cloud ops team) > > >> - User's automation jobs fail at next OpenStack REST call > > >> - User begins debugging, wasting hours of time figuring out that > > >>their tokens, which they stored and show should still be valid, > were > > >>rejected. > > >> > > > > > > Ah - I guess this is where we're missing each other, which is good and > > > helpful. > > > > > > I would argue that any user that is _storing_ tokens is doing way too > much > > > work. If they are doing short tasks, they should just treat them as > > > ephemeral. If they are doing longer tasks, they need to deal with > timeouts. > > > SO, this: > > > > > > > > > - User gets token, it says "expires_at Now+4 hours" > > > - User starts a brief set of automation tasks in their system > > >that does not use python and has not failed with invalid tokens thus > > >far. > > > > > > should be: > > > > > > - User starts a brief set of automation tasks in their system > > > that does not use python and has not failed with invalid tokens thus > > > far. > > > > > > "Get a token" should never be an activity that anyone ever consciously > > > performs. > > > > > > > > This is my view. Never, ever, ever assume your token is good until > > expiration. Assume the token might be broken at any request and know how > to > > re-auth. > > > > > And now they have to refactor their app, because this may happen again, > > >> and they have to make sure that invalid token errors can bubble up to > the > > >> layer that has the username/password, or accept rolling back and > > >> retrying the whole thing. > > >> > > >> I'm not saying anybody has this system, I'm suggesting we're putting > > >> undue burden on users with an unknown consequence. Falling back to > UUID > > >> for a while has a known cost of a little bit of code and checking junk > > >> tokens twice. > > >> > > > > > Please do not advocate "falling back" to UUID. I am actually against > making > > fernet the default (very, very strongly), if we have to have this > > "fallback" code. It is the wrong kind of approach, we already have > serious > > issues with complex code paths that produce subtly different results. If > > the options are: > > > > 1) Make Fernet Default and have "fallback" code > > > > or > > > > 2) Leave UUID default and highly recommend fernet (plus gate on fernet > > primarily, default in devstack) > > > > I will jump on my soapbox and be very loudly in favor of the 2nd option. > If > > we communicate this is a change that will happen (hey, maybe throw an > > error/make the config option "none" so it has to be explicit) in Newton, > > and then move to a Fernet default in O - I'd be ok with that. > > > > > > > > Totally. I have no problem with the suggestion that keystone handle > this. > > > But I also think that users should quite honestly stop thinking about > > > tokens at all. Tokens are an implementation detail that if any user > thinks > > > about while writing their app they're setting themselves up to be > screwed - > > > so we should make sure we're not talking about them in a primary way > such > > > as to suggest that people focus a lot of energy on them. > > > > > > (I also frequently see users who are using python libraries even get > > > everything horribly wrong and screw themselves because they think they > need > > > to think about tokens) > > > > > > > Better communication that tokens are ephemeral and should not assume to > > work always (even until thei
Re: [openstack-dev] [keystone] Token providers and Fernet as the default
On Tue, May 3, 2016 at 1:46 PM, Clint Byrum wrote: > Excerpts from Morgan Fainberg's message of 2016-05-03 11:13:38 -0700: > > On Tue, May 3, 2016 at 10:28 AM, Monty Taylor > wrote: > > > > > On 05/03/2016 11:47 AM, Clint Byrum wrote: > > > > > >> Excerpts from Monty Taylor's message of 2016-05-03 07:59:21 -0700: > > >> > > >>> On 05/03/2016 08:55 AM, Clint Byrum wrote: > > >>> > > > > 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) > > >>> > > >>> > > >> Sure, one should definitely not be expecting everything to always work > > >> without errors. On this we agree for sure. However, when we do decide > to > > >> intentionally induce errors for reasons we have not done so before, we > > >> should weigh the cost of avoiding that with the cost of having it > > >> happen. Consider this strawman: > > >> > > >> - User gets token, it says "expires_at Now+4 hours" > > >> - User starts a brief set of automation tasks in their system > > >>that does not use python and has not failed with invalid tokens > thus > > >>far. > > >> - Keystone nodes are all updated at one time (AMAZING cloud ops team) > > >> - User's automation jobs fail at next OpenStack REST call > > >> - User begins debugging, wasting hours of time figuring out that > > >>their tokens, which they stored and show should still be valid, > were > > >>rejected. > > >> > > > > > > Ah - I guess this is where we're missing each other, which is good and > > > helpful. > > > > > > I would argue that any user that is _storing_ tokens is doing way too > much > > > work. If they are doing short tasks, they should just treat them as > > > ephemeral. If they are doing longer tasks, they need to deal with > timeouts. > > > SO, this: > > > > > > > > > - User gets token, it says "expires_at Now+4 hours" > > > - User starts a brief set of automation tasks in their system > > >that does not use python and has not failed with invalid tokens thus > > >far. > > > > > > should be: > > > > > > - User starts a brief set of automation tasks in their system > > > that does not use python and has not failed with invalid tokens thus > > > far. > > > > > > "Get a token" should never be an activity that anyone ever consciously > > > performs. > > > > > > > > This is my view. Never, ever, ever assume your token is good until > > expiration. Assume the token might be broken at any request and know how > to > > re-auth. > > > > > And now they have to refactor their app, because this may happen again, > > >> and they have to make sure that invalid token errors can bubble up to > the > > >> layer that has the username/password, or accept rolling back and > > >> retrying the whole thing. > > >> > > >> I'm not saying anybody has this system, I'm suggesting we're putting > > >> undue burden on users with an unknown consequence. Falling back to > UUID > > >> for a while has a known cost of a little bit of code and checking junk > > >> tokens twice. > > >> > > > > > Please do not advocate "falling back" to UUID. I am actually against > making > > fernet the default (very, very strongly), if we have to have this > > "fallback" code. It is the wrong kind of approach, we already have > serious > > issues with complex code paths that produce subtly different results. If > > the options are: > > > > 1) Make Fernet Default and have "fallback" code > > > > or > > > > 2) Leave UUID default and highly recommend fernet (plus gate on fernet > > primarily, default in devstack) > > > > I will jump on my soapbox and be very loudly in favor of the 2nd option. > If > > we communicate this is a change that will happen (hey, maybe throw an > > error/make the config option "none" so it has to be explicit) in Newton, > > and then move to a Fernet default in O - I'd be ok with that. > > > > > > > > Totally. I have no problem with the suggestion that keystone handle > this. > > > But I also think that users should quite honestly stop thinking about > > > tokens at all. Tokens are an implementation detail that if any user > thinks > > > about while writing their app they're setting themselves up to be > screwed - > > > so we should make sure we're not talking about them in a primary way > such > > > as to suggest that people focus a lot of energy on them. > > > > > > (I also frequently see users who are using python libraries even get > > > everything horribly wrong and screw themselves because they think they > need > > > to think about tokens) > > > > > > > Better communication that tokens are ephemeral and should not assume to > > work always (even until thei
Re: [openstack-dev] [keystone] Token providers and Fernet as the default
Excerpts from Morgan Fainberg's message of 2016-05-03 11:13:38 -0700: > On Tue, May 3, 2016 at 10:28 AM, Monty Taylor wrote: > > > On 05/03/2016 11:47 AM, Clint Byrum wrote: > > > >> Excerpts from Monty Taylor's message of 2016-05-03 07:59:21 -0700: > >> > >>> On 05/03/2016 08:55 AM, Clint Byrum wrote: > >>> > > 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) > >>> > >>> > >> Sure, one should definitely not be expecting everything to always work > >> without errors. On this we agree for sure. However, when we do decide to > >> intentionally induce errors for reasons we have not done so before, we > >> should weigh the cost of avoiding that with the cost of having it > >> happen. Consider this strawman: > >> > >> - User gets token, it says "expires_at Now+4 hours" > >> - User starts a brief set of automation tasks in their system > >>that does not use python and has not failed with invalid tokens thus > >>far. > >> - Keystone nodes are all updated at one time (AMAZING cloud ops team) > >> - User's automation jobs fail at next OpenStack REST call > >> - User begins debugging, wasting hours of time figuring out that > >>their tokens, which they stored and show should still be valid, were > >>rejected. > >> > > > > Ah - I guess this is where we're missing each other, which is good and > > helpful. > > > > I would argue that any user that is _storing_ tokens is doing way too much > > work. If they are doing short tasks, they should just treat them as > > ephemeral. If they are doing longer tasks, they need to deal with timeouts. > > SO, this: > > > > > > - User gets token, it says "expires_at Now+4 hours" > > - User starts a brief set of automation tasks in their system > >that does not use python and has not failed with invalid tokens thus > >far. > > > > should be: > > > > - User starts a brief set of automation tasks in their system > > that does not use python and has not failed with invalid tokens thus > > far. > > > > "Get a token" should never be an activity that anyone ever consciously > > performs. > > > > > This is my view. Never, ever, ever assume your token is good until > expiration. Assume the token might be broken at any request and know how to > re-auth. > > > And now they have to refactor their app, because this may happen again, > >> and they have to make sure that invalid token errors can bubble up to the > >> layer that has the username/password, or accept rolling back and > >> retrying the whole thing. > >> > >> I'm not saying anybody has this system, I'm suggesting we're putting > >> undue burden on users with an unknown consequence. Falling back to UUID > >> for a while has a known cost of a little bit of code and checking junk > >> tokens twice. > >> > > > Please do not advocate "falling back" to UUID. I am actually against making > fernet the default (very, very strongly), if we have to have this > "fallback" code. It is the wrong kind of approach, we already have serious > issues with complex code paths that produce subtly different results. If > the options are: > > 1) Make Fernet Default and have "fallback" code > > or > > 2) Leave UUID default and highly recommend fernet (plus gate on fernet > primarily, default in devstack) > > I will jump on my soapbox and be very loudly in favor of the 2nd option. If > we communicate this is a change that will happen (hey, maybe throw an > error/make the config option "none" so it has to be explicit) in Newton, > and then move to a Fernet default in O - I'd be ok with that. > > > > > Totally. I have no problem with the suggestion that keystone handle this. > > But I also think that users should quite honestly stop thinking about > > tokens at all. Tokens are an implementation detail that if any user thinks > > about while writing their app they're setting themselves up to be screwed - > > so we should make sure we're not talking about them in a primary way such > > as to suggest that people focus a lot of energy on them. > > > > (I also frequently see users who are using python libraries even get > > everything horribly wrong and screw themselves because they think they need > > to think about tokens) > > > > Better communication that tokens are ephemeral and should not assume to > work always (even until their expiry) should be the messaging we use. It's > simple, plan to reauth as needed and handle failures. This is not what the documentation says, so yeah, we need to actually tell users that expires_at is an upper bounds, because right now it says: The date and time when the token expires. The date
Re: [openstack-dev] [keystone] Token providers and Fernet as the default
On Tue, May 3, 2016 at 10:28 AM, Monty Taylor wrote: > On 05/03/2016 11:47 AM, Clint Byrum wrote: > >> Excerpts from Monty Taylor's message of 2016-05-03 07:59:21 -0700: >> >>> On 05/03/2016 08:55 AM, Clint Byrum wrote: >>> 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) >>> >>> >> Sure, one should definitely not be expecting everything to always work >> without errors. On this we agree for sure. However, when we do decide to >> intentionally induce errors for reasons we have not done so before, we >> should weigh the cost of avoiding that with the cost of having it >> happen. Consider this strawman: >> >> - User gets token, it says "expires_at Now+4 hours" >> - User starts a brief set of automation tasks in their system >>that does not use python and has not failed with invalid tokens thus >>far. >> - Keystone nodes are all updated at one time (AMAZING cloud ops team) >> - User's automation jobs fail at next OpenStack REST call >> - User begins debugging, wasting hours of time figuring out that >>their tokens, which they stored and show should still be valid, were >>rejected. >> > > Ah - I guess this is where we're missing each other, which is good and > helpful. > > I would argue that any user that is _storing_ tokens is doing way too much > work. If they are doing short tasks, they should just treat them as > ephemeral. If they are doing longer tasks, they need to deal with timeouts. > SO, this: > > > - User gets token, it says "expires_at Now+4 hours" > - User starts a brief set of automation tasks in their system >that does not use python and has not failed with invalid tokens thus >far. > > should be: > > - User starts a brief set of automation tasks in their system > that does not use python and has not failed with invalid tokens thus > far. > > "Get a token" should never be an activity that anyone ever consciously > performs. > > This is my view. Never, ever, ever assume your token is good until expiration. Assume the token might be broken at any request and know how to re-auth. > And now they have to refactor their app, because this may happen again, >> and they have to make sure that invalid token errors can bubble up to the >> layer that has the username/password, or accept rolling back and >> retrying the whole thing. >> >> I'm not saying anybody has this system, I'm suggesting we're putting >> undue burden on users with an unknown consequence. Falling back to UUID >> for a while has a known cost of a little bit of code and checking junk >> tokens twice. >> > Please do not advocate "falling back" to UUID. I am actually against making fernet the default (very, very strongly), if we have to have this "fallback" code. It is the wrong kind of approach, we already have serious issues with complex code paths that produce subtly different results. If the options are: 1) Make Fernet Default and have "fallback" code or 2) Leave UUID default and highly recommend fernet (plus gate on fernet primarily, default in devstack) I will jump on my soapbox and be very loudly in favor of the 2nd option. If we communicate this is a change that will happen (hey, maybe throw an error/make the config option "none" so it has to be explicit) in Newton, and then move to a Fernet default in O - I'd be ok with that. > > Totally. I have no problem with the suggestion that keystone handle this. > But I also think that users should quite honestly stop thinking about > tokens at all. Tokens are an implementation detail that if any user thinks > about while writing their app they're setting themselves up to be screwed - > so we should make sure we're not talking about them in a primary way such > as to suggest that people focus a lot of energy on them. > > (I also frequently see users who are using python libraries even get > everything horribly wrong and screw themselves because they think they need > to think about tokens) > Better communication that tokens are ephemeral and should not assume to work always (even until their expiry) should be the messaging we use. It's simple, plan to reauth as needed and handle failures. --Morgan __ 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
Re: [openstack-dev] [keystone] Token providers and Fernet as the default
On 05/03/2016 11:47 AM, Clint Byrum wrote: Excerpts from Monty Taylor's message of 2016-05-03 07:59:21 -0700: On 05/03/2016 08:55 AM, Clint Byrum wrote: 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) Sure, one should definitely not be expecting everything to always work without errors. On this we agree for sure. However, when we do decide to intentionally induce errors for reasons we have not done so before, we should weigh the cost of avoiding that with the cost of having it happen. Consider this strawman: - User gets token, it says "expires_at Now+4 hours" - User starts a brief set of automation tasks in their system that does not use python and has not failed with invalid tokens thus far. - Keystone nodes are all updated at one time (AMAZING cloud ops team) - User's automation jobs fail at next OpenStack REST call - User begins debugging, wasting hours of time figuring out that their tokens, which they stored and show should still be valid, were rejected. Ah - I guess this is where we're missing each other, which is good and helpful. I would argue that any user that is _storing_ tokens is doing way too much work. If they are doing short tasks, they should just treat them as ephemeral. If they are doing longer tasks, they need to deal with timeouts. SO, this: - User gets token, it says "expires_at Now+4 hours" - User starts a brief set of automation tasks in their system that does not use python and has not failed with invalid tokens thus far. should be: - User starts a brief set of automation tasks in their system that does not use python and has not failed with invalid tokens thus far. "Get a token" should never be an activity that anyone ever consciously performs. And now they have to refactor their app, because this may happen again, and they have to make sure that invalid token errors can bubble up to the layer that has the username/password, or accept rolling back and retrying the whole thing. I'm not saying anybody has this system, I'm suggesting we're putting undue burden on users with an unknown consequence. Falling back to UUID for a while has a known cost of a little bit of code and checking junk tokens twice. Totally. I have no problem with the suggestion that keystone handle this. But I also think that users should quite honestly stop thinking about tokens at all. Tokens are an implementation detail that if any user thinks about while writing their app they're setting themselves up to be screwed - so we should make sure we're not talking about them in a primary way such as to suggest that people focus a lot of energy on them. (I also frequently see users who are using python libraries even get everything horribly wrong and screw themselves because they think they need to think about tokens) __ 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
Re: [openstack-dev] [keystone] Token providers and Fernet as the default
Excerpts from Adam Young's message of 2016-05-03 07:21:52 -0700: > On 05/03/2016 09:55 AM, Clint Byrum wrote: > > 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 was actually thinking of a different migration strategy, exactly the > opposite: for a while, run with the uuid tokens, but store the Fernet > body. After while, switch from validating the uuid token body to the > stored Fernet. Finally, switch to validating the Fernet token from the > request. That way, we always have only one token provider, and the > migration can happen step by step. > > It will not help someone that migrates from Icehouse to Ocata. Then > again, the dual plan you laid out above will not either; at some point, > people will have to dump the token table to make major migrations. > Your plan has a nice aspect that it allows validating Fernet tokens on UUID-configured nodes too, which means operators don't have to be careful to update all nodes at one time. So I think what you describe above is an even better plan. Either way, the point is to avoid an immediate mass token invalidation event on change of provider. __ 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
Re: [openstack-dev] [keystone] Token providers and Fernet as the default
Excerpts from Lance Bragstad's message of 2016-05-03 07:42:43 -0700: > If we were to write a uuid/fernet hybrid provider, it would only be > expected to support something like stable/liberty to stable/mitaka, right? > This is something that we could contribute to stackforge, too. > If done the way Adam Young described, with Fernet content as UUIDs, one could in theory update from any UUID-aware provider, since the Fernet-emitting nodes would just be writing their Fernet tokens into the database that the UUID nodes read from, allowing the UUID-only nodes to validate the new tokens. However, we never support jumping more than one release at a time, so that is somewhat moot. Also, stackforge isn't a thing, but I see what you're saying. It could live out of tree, but let's not abandon all hope that we can collaborate on something that works for users who desire to not have a window mass token invalidation on update. __ 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
Re: [openstack-dev] [keystone] Token providers and Fernet as the default
Excerpts from Monty Taylor's message of 2016-05-03 07:59:21 -0700: > On 05/03/2016 08:55 AM, Clint Byrum wrote: > > > > 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) > Sure, one should definitely not be expecting everything to always work without errors. On this we agree for sure. However, when we do decide to intentionally induce errors for reasons we have not done so before, we should weigh the cost of avoiding that with the cost of having it happen. Consider this strawman: - User gets token, it says "expires_at Now+4 hours" - User starts a brief set of automation tasks in their system that does not use python and has not failed with invalid tokens thus far. - Keystone nodes are all updated at one time (AMAZING cloud ops team) - User's automation jobs fail at next OpenStack REST call - User begins debugging, wasting hours of time figuring out that their tokens, which they stored and show should still be valid, were rejected. And now they have to refactor their app, because this may happen again, and they have to make sure that invalid token errors can bubble up to the layer that has the username/password, or accept rolling back and retrying the whole thing. I'm not saying anybody has this system, I'm suggesting we're putting undue burden on users with an unknown consequence. Falling back to UUID for a while has a known cost of a little bit of code and checking junk tokens twice. __ 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
Re: [openstack-dev] [keystone] Token providers and Fernet as the default
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 wrote: On Mon, May 2, 2016 at 5:26 PM, Clint Byrum 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
Re: [openstack-dev] [keystone] Token providers and Fernet as the default
If we were to write a uuid/fernet hybrid provider, it would only be expected to support something like stable/liberty to stable/mitaka, right? This is something that we could contribute to stackforge, too. On Tue, May 3, 2016 at 9:21 AM, Adam Young wrote: > On 05/03/2016 09: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 >>> wrote: >>> >>> On Mon, May 2, 2016 at 5:26 PM, Clint Byrum 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_. >> >> 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. >> >> 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 emitt
Re: [openstack-dev] [keystone] Token providers and Fernet as the default
On 05/03/2016 09: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 wrote: On Mon, May 2, 2016 at 5:26 PM, Clint Byrum 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_. 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. 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 was actually thinking of a different migration strategy, exactly the opposite: for a while, run with the uuid tokens, but store the Fernet body. After while, switch from validating the uuid token body to the stored Fernet. Finally, switch to validating the Fernet token from the
Re: [openstack-dev] [keystone] Token providers and Fernet as the default
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 wrote: > > > On Mon, May 2, 2016 at 5:26 PM, Clint Byrum 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_. > 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. 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
Re: [openstack-dev] [keystone] Token providers and Fernet as the default
On Mon, May 2, 2016 at 6:26 PM, Clint Byrum 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. > > I wonder if one could merge UUID and Fernet into a provider which > handles this transition gracefully: > > if self._fernet_keys: > This would have to check that there's an active fernet key and not just a staging one. You'll want to push out a staging key to all the nodes first to enable fernet validation before pushing out the active key to enable token creation. Maybe there's a trick to getting keystone-manage fernet_setup to only setup a staging key, or you just copy that key around. Also, we could have keystone keep track of if there aren't any uuid tokens since there's no need to query the database everytime we get an invalid token just to see an empty table. - Brant > 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() > > So that while one is rolling out new keystone nodes and syncing fernet > keys, all tokens issued would validated properly, with minimal extra > cost to support both (basically just a number of UUID tokens will need > to be parsed twice, once as Fernet, and once as UUID). > > Thoughts? I think doing this would make changing the default fairly > uncontroversial. > > __ > 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 > -- - 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
Re: [openstack-dev] [keystone] Token providers and Fernet as the default
Excerpts from Matt Fischer's message of 2016-05-02 16:39:02 -0700: > On Mon, May 2, 2016 at 5:26 PM, Clint Byrum 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? > "Production defaults" is something we used to mention a lot. One would hope you can run a very nice Keystone with only the required settings such as database connection details. Agreed that upgrades will be conscious decisions by operators, no doubt! However, the operator is not the one who gets the surprise. It is the user who doesn't expect their tokens to be invalidated until their TTL is up. The cloud changes when the operator decides it changes. And if that is in the middle of something important, the operator has just induced unnecessary complication on the user. __ 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
Re: [openstack-dev] [keystone] Token providers and Fernet as the default
Comments inline... On Mon, May 2, 2016 at 7:39 PM, Matt Fischer wrote: > On Mon, May 2, 2016 at 5:26 PM, Clint Byrum 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). 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 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. > > >> >> 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. So that while one is rolling out new keystone nodes and syncing fernet >> keys, all tokens issued would validated properly, with minimal extra >> cost to support both (basically just a number of UUID tokens will need >> to be parsed twice, once as Fernet, and once as UUID). >> >> Thoughts? I think doing this would make changing the default fairly >> uncontroversial. >> >> __ >> 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 > > __ 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
Re: [openstack-dev] [keystone] Token providers and Fernet as the default
On Mon, May 2, 2016 at 5:26 PM, Clint Byrum 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? > > 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() > > So that while one is rolling out new keystone nodes and syncing fernet > keys, all tokens issued would validated properly, with minimal extra > cost to support both (basically just a number of UUID tokens will need > to be parsed twice, once as Fernet, and once as UUID). > > Thoughts? I think doing this would make changing the default fairly > uncontroversial. > > __ > 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
[openstack-dev] [keystone] Token providers and Fernet as the default
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. 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() So that while one is rolling out new keystone nodes and syncing fernet keys, all tokens issued would validated properly, with minimal extra cost to support both (basically just a number of UUID tokens will need to be parsed twice, once as Fernet, and once as UUID). Thoughts? I think doing this would make changing the default fairly uncontroversial. __ 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