Hello! Nova client's CLI parameter 'bypass_url' helps me. The client's API also has 'management_url' attribute, if this one is specified - the client doesn't reauthenticate. Also the most of clients have 'endpoint' argument, so client doesn't make extra call to keystone to retrieve new token and service_catalog.
Thank you for clarification! On Mon, Feb 16, 2015 at 11:30 PM, Jamie Lennox <[email protected]> wrote: > > > ----- Original Message ----- > > From: "Alexander Makarov" <[email protected]> > > To: "OpenStack Development Mailing List (not for usage questions)" < > [email protected]> > > Sent: Tuesday, 17 February, 2015 4:00:05 AM > > Subject: Re: [openstack-dev] [keystone] [trusts] [all] How trusts should > work by design? > > > > > https://blueprints.launchpad.net/keystone/+spec/trust-scoped-re-authentication > > > > On Mon, Feb 16, 2015 at 7:57 PM, Alexander Makarov < > [email protected] > > > wrote: > > > > > > > > We could soften this limitation a little by returning token client tries > to > > authenticate with. > > I think we need to discuss it in community. > > > > On Mon, Feb 16, 2015 at 6:47 PM, Steven Hardy < [email protected] > > wrote: > > > > > > On Mon, Feb 16, 2015 at 09:02:01PM +0600, Renat Akhmerov wrote: > > > Yeah, clarification from keystone folks would be really helpful. > > > If Nikolaya**s info is correct (I believe it is) then I actually > dona**t > > > understand why trusts are needed at all, they seem to be useless. My > > > assumption is that they can be used only if we send requests directly > to > > > OpenStack services (w/o using clients) with trust scoped token > included in > > > headers, that might work although I didna**t checked that yet myself. > > > So please help us understand which one of my following assumptions is > > > correct? > > > 1. We dona**t understand what trusts are. > > > 2. We use them in a wrong way. (If yes, then whata**s the correct > usage?) > > > > One or both of these seems likely, possibly combined with bugs in the > > clients where they try to get a new token instead of using the one you > > provide (this is a common pattern in the shell case, as the token is > > re-requested to get a service catalog). > > > > This provides some (heat specific) information which may help somewhat: > > > > > http://hardysteven.blogspot.co.uk/2014/04/heat-auth-model-updates-part-1-trusts.html > > > > > 3. Trust mechanism itself is in development and cana**t be used at this > > > point. > > > > IME trusts work fine, Heat has been using them since Havana with few > > problems. > > > > > 4. OpenStack clients need to be changed in some way to somehow bypass > > > this keystone limitation? > > > > AFAICS it's not a keystone limitation, the behavior you're seeing is > > expected, and the 403 mentioned by Nikolay is just trusts working as > > designed. > > > > The key thing from a client perspective is: > > > > 1. If you pass a trust-scoped token into the client, you must not request > > another token, normally this means you must provide an endpoint as you > > can't run the normal auth code which retrieves the service catalog. > > > > 2. If you could pass a trust ID in, with a non-trust-scoped token, or > > username/password, the above limitation is removed, but AFAIK none of the > > CLI interfaces support a trust ID yet. > > > > 3. If you're using a trust scoped token, you cannot create another trust > > (unless you've enabled chained delegation, which only landed recently in > > keystone). This means, for example, that you can't create a heat stack > > with a trust scoped token (when heat is configured to use trusts), unless > > you use chained delegation, because we create a trust internally. > > > > When you understand these constraints, it's definitely possible to > create a > > trust and use it for requests to other services, for example, here's how > > you could use a trust-scoped token to call heat: > > > > heat --os-auth-token <trust-scoped-token> --os-no-client-auth > > --heat-url http://192.168.0.4:8004/v1/ <project-id> stack-list > > > > The pattern heat uses internally to work with trusts is: > > > > 1. Use a trust_id and service user credentials to get a trust scoped > token > > 2. Pass the trust-scoped token into python clients for other projects, > > using the endpoint obtained during (1) > > > > This works fine, what you can't do is pass the trust scoped token in > > without explicitly defining the endpoint, because this triggers > > reauthentication, which as you've discovered, won't work. > > > > Hope that helps! > > > > Steve > > > > So I think what you are seeing, and what heat has come up against in the > past is a limitation of the various python-*clients and not a problem of > the actual delegation mechanism from the keystone point of view. This is a > result of the basic authentication code being copied around between clients > and then not being kept updated since... probably havana. > > The good news is that if you go with the session based approach then you > can share these tokens amongst clients without the hacks. > > The identity authentication plugins that keystoneclient offers (v2 and v3 > api for Token and Password) both accept a trust_id to be scoped to and then > the plugin can be shared amongst all the clients that support it (AFAIK > that's almost everyone - the big exceptions being glance and swift). > > Here's an example (untested - off the top of my head): > > from keystoneclient import session > from keystoneclient.auth.identity import v3 > from cinderclient.v2 import client as c_client > from keystoneclient.v3 import client as k_client > from novaclient.v1_1 import client as n_client > > a = v3.Password(auth_url='http://keystone.test:5000/v3', username='user', > password='pass', user_domain_id='dom', trust_id='abcd1234') > s = session.Session(auth=a) > > k = k_client.Client(s) > c = c_client.Client(s) > n = n_client.Client(s) > > You now have a keystone, cinder and nova client that will all use the same > trust scoped token and correctly share a service catalog between them. > > Whilst i've gotten most of the client libraries to support sessions in > this way, i really haven't been going after the CLIs so i've no idea to > what level trusts are supported in those. I know that the same pattern as > above would be supported via openstackclient with: > > openstack --os-auth-type v3password --os-auth-url ... --os-username ... > --os-password .. --os-user-domain-id.., --os-trust-id ... command > > and so if OSC has enough coverage for you then you can use trusts from the > CLI in that way. > > Is that sufficient for what you need? > > Jamie > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > -- > > Kind Regards, > > Alexander Makarov, > > Senoir Software Developer, > > > > Mirantis, Inc. > > 35b/3, Vorontsovskaya St., 109147, Moscow, Russia > > > > Tel.: +7 (495) 640-49-04 > > Tel.: +7 (926) 204-50-60 > > > > Skype: MAKAPOB.AJIEKCAHDP > > > > > > > > -- > > Kind Regards, > > Alexander Makarov, > > Senoir Software Developer, > > > > Mirantis, Inc. > > 35b/3, Vorontsovskaya St., 109147, Moscow, Russia > > > > Tel.: +7 (495) 640-49-04 > > Tel.: +7 (926) 204-50-60 > > > > Skype: MAKAPOB.AJIEKCAHDP > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best Regards, Nikolay
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
