[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