Open Stack

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 <shardy at redhat.com> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev