Steve, I saw a couple of things in what you wrote that we might be doing wrong. We’ll check them when we wake up and let you know what we discovered.
Thanks Renat Akhmerov @ Mirantis Inc. > On 16 Feb 2015, at 21:47, 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 > > __________________________________________________________________________ > 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
