On 03/09/2016 01:11 AM, Tim Bell wrote:
From: Matt Fischer <m...@mattfischer.com <mailto:m...@mattfischer.com>>
Reply-To: "OpenStack Development Mailing List (not for usage
questions)" <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday 8 March 2016 at 20:35
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org
<mailto:openstack-dev@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 <openst...@roodsari.us
<mailto:openst...@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 <openst...@roodsari.us
<mailto:openst...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://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
<mailto: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://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