[openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

Tim Bell Tim.Bell at cern.ch
Wed Mar 9 06:11:40 UTC 2016


From: Matt Fischer <matt at mattfischer.com<mailto:matt at mattfischer.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Tuesday 8 March 2016 at 20:35
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [keystone] Using multiple token formats in a one openstack cloud

I don't think your example is right: "PKI will validate that token without going to any keystone server". How would it track revoked tokens? I'm pretty sure that they still get validated, they are stored in the DB even.

I also disagree that there are different use cases. Just switch to fernet and save yourself what's going to be weeks of pain with probably no improvement in anything with this idea.

Is there any details on how to switch to Fernet for a running cloud ? I can see a migration path where the cloud is stopped, the token format changed and the cloud restarted.

It seems more complex (and maybe insane, as Adam would say) to do this for a running cloud without disturbing the users of the cloud.

Tim

On Tue, Mar 8, 2016 at 9:56 AM, rezroo <openstack at roodsari.us<mailto:openstack at roodsari.us>> wrote:
The basic idea is to let the openstack clients decide what sort of token optimization to use - for example, while a normal client uses uuid tokens, some services like heat or magnum may opt for pki tokens for their operations. A service like nova, configured for PKI will validate that token without going to any keystone server, but if it gets a uuid token then validates it with a keystone endpoint. I'm under the impression that the different token formats have different use-cases, so am wondering if there is a conceptual reason why multiple token formats are an either/or scenario.


On 3/8/2016 8:06 AM, Matt Fischer wrote:
This would be complicated to setup. How would the Openstack services validate the token? Which keystone node would they use? A better question is why would you want to do this?

On Tue, Mar 8, 2016 at 8:45 AM, rezroo <openstack at roodsari.us<mailto:openstack at roodsari.us>> wrote:
Keystone supports both tokens and ec2 credentials simultaneously, but as far as I can tell, will only do a single token format (uuid, pki/z, fernet) at a time. Is it possible or advisable to configure keystone to issue multiple token formats? For example, I could configure two keystone servers, each using a different token format, so depending on endpoint used, I could get a uuid or pki token. Each service can use either token format, so is there a conceptual or implementation issue with this setup?
Thanks,
Reza

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe<mailto:OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@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/20160309/efc94448/attachment.html>


More information about the OpenStack-dev mailing list