Open Stack

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