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

Adam Young ayoung at redhat.com
Wed Mar 9 14:19:41 UTC 2016


On 03/09/2016 01:11 AM, Tim Bell wrote:
>
> 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

So, Fernet does not persist, UUID does.  I would guess that a transition 
plan would involve being able to fall back to a persisted UUID if the 
Fernet validation does not work.


>
>     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
>
>
>
>
> __________________________________________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160309/a645dc83/attachment.html>


More information about the OpenStack-dev mailing list