Open Stack

----- Original Message -----
> From: "Alexander Makarov" <amakarov at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> 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 < amakarov at mirantis.com >
> 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 < 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
> 

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