<div dir="ltr"><div>Hello!</div><br>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.<br><br>Thank you for clarification!<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 16, 2015 at 11:30 PM, Jamie Lennox <span dir="ltr"><<a href="mailto:jamielennox@redhat.com" target="_blank">jamielennox@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
----- Original Message -----<br>
> From: "Alexander Makarov" <<a href="mailto:amakarov@mirantis.com">amakarov@mirantis.com</a>><br>
</span><span class="">> To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> Sent: Tuesday, 17 February, 2015 4:00:05 AM<br>
> Subject: Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?<br>
><br>
</span><div><div class="h5">> <a href="https://blueprints.launchpad.net/keystone/+spec/trust-scoped-re-authentication" target="_blank">https://blueprints.launchpad.net/keystone/+spec/trust-scoped-re-authentication</a><br>
><br>
> On Mon, Feb 16, 2015 at 7:57 PM, Alexander Makarov < <a href="mailto:amakarov@mirantis.com">amakarov@mirantis.com</a> ><br>
> wrote:<br>
><br>
><br>
><br>
> We could soften this limitation a little by returning token client tries to<br>
> authenticate with.<br>
> I think we need to discuss it in community.<br>
><br>
> On Mon, Feb 16, 2015 at 6:47 PM, Steven Hardy < <a href="mailto:shardy@redhat.com">shardy@redhat.com</a> > wrote:<br>
><br>
><br>
> On Mon, Feb 16, 2015 at 09:02:01PM +0600, Renat Akhmerov wrote:<br>
> > Yeah, clarification from keystone folks would be really helpful.<br>
> > If Nikolaya**s info is correct (I believe it is) then I actually dona**t<br>
> > understand why trusts are needed at all, they seem to be useless. My<br>
> > assumption is that they can be used only if we send requests directly to<br>
> > OpenStack services (w/o using clients) with trust scoped token included in<br>
> > headers, that might work although I didna**t checked that yet myself.<br>
> > So please help us understand which one of my following assumptions is<br>
> > correct?<br>
> > 1. We dona**t understand what trusts are.<br>
> > 2. We use them in a wrong way. (If yes, then whata**s the correct usage?)<br>
><br>
> One or both of these seems likely, possibly combined with bugs in the<br>
> clients where they try to get a new token instead of using the one you<br>
> provide (this is a common pattern in the shell case, as the token is<br>
> re-requested to get a service catalog).<br>
><br>
> This provides some (heat specific) information which may help somewhat:<br>
><br>
> <a href="http://hardysteven.blogspot.co.uk/2014/04/heat-auth-model-updates-part-1-trusts.html" target="_blank">http://hardysteven.blogspot.co.uk/2014/04/heat-auth-model-updates-part-1-trusts.html</a><br>
><br>
> > 3. Trust mechanism itself is in development and cana**t be used at this<br>
> > point.<br>
><br>
> IME trusts work fine, Heat has been using them since Havana with few<br>
> problems.<br>
><br>
> > 4. OpenStack clients need to be changed in some way to somehow bypass<br>
> > this keystone limitation?<br>
><br>
> AFAICS it's not a keystone limitation, the behavior you're seeing is<br>
> expected, and the 403 mentioned by Nikolay is just trusts working as<br>
> designed.<br>
><br>
> The key thing from a client perspective is:<br>
><br>
> 1. If you pass a trust-scoped token into the client, you must not request<br>
> another token, normally this means you must provide an endpoint as you<br>
> can't run the normal auth code which retrieves the service catalog.<br>
><br>
> 2. If you could pass a trust ID in, with a non-trust-scoped token, or<br>
> username/password, the above limitation is removed, but AFAIK none of the<br>
> CLI interfaces support a trust ID yet.<br>
><br>
> 3. If you're using a trust scoped token, you cannot create another trust<br>
> (unless you've enabled chained delegation, which only landed recently in<br>
> keystone). This means, for example, that you can't create a heat stack<br>
> with a trust scoped token (when heat is configured to use trusts), unless<br>
> you use chained delegation, because we create a trust internally.<br>
><br>
> When you understand these constraints, it's definitely possible to create a<br>
> trust and use it for requests to other services, for example, here's how<br>
> you could use a trust-scoped token to call heat:<br>
><br>
> heat --os-auth-token <trust-scoped-token> --os-no-client-auth<br>
> --heat-url <a href="http://192.168.0.4:8004/v1/" target="_blank">http://192.168.0.4:8004/v1/</a> <project-id> stack-list<br>
><br>
> The pattern heat uses internally to work with trusts is:<br>
><br>
> 1. Use a trust_id and service user credentials to get a trust scoped token<br>
> 2. Pass the trust-scoped token into python clients for other projects,<br>
> using the endpoint obtained during (1)<br>
><br>
> This works fine, what you can't do is pass the trust scoped token in<br>
> without explicitly defining the endpoint, because this triggers<br>
> reauthentication, which as you've discovered, won't work.<br>
><br>
> Hope that helps!<br>
><br>
> Steve<br>
><br>
<br>
</div></div>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.<br>
<br>
The good news is that if you go with the session based approach then you can share these tokens amongst clients without the hacks.<br>
<br>
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).<br>
<br>
Here's an example (untested - off the top of my head):<br>
<br>
from keystoneclient import session<br>
from keystoneclient.auth.identity import v3<br>
from cinderclient.v2 import client as c_client<br>
from keystoneclient.v3 import client as k_client<br>
from novaclient.v1_1 import client as n_client<br>
<br>
a = v3.Password(auth_url='<a href="http://keystone.test:5000/v3" target="_blank">http://keystone.test:5000/v3</a>', username='user', password='pass', user_domain_id='dom', trust_id='abcd1234')<br>
s = session.Session(auth=a)<br>
<br>
k = k_client.Client(s)<br>
c = c_client.Client(s)<br>
n = n_client.Client(s)<br>
<br>
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.<br>
<br>
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:<br>
<br>
openstack --os-auth-type v3password --os-auth-url ... --os-username ... --os-password .. --os-user-domain-id.., --os-trust-id ... command<br>
<br>
and so if OSC has enough coverage for you then you can use trusts from the CLI in that way.<br>
<br>
Is that sufficient for what you need?<br>
<span class="HOEnZb"><font color="#888888"><br>
Jamie<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> --<br>
> Kind Regards,<br>
> Alexander Makarov,<br>
> Senoir Software Developer,<br>
><br>
> Mirantis, Inc.<br>
> 35b/3, Vorontsovskaya St., 109147, Moscow, Russia<br>
><br>
> Tel.: +7 (495) 640-49-04<br>
> Tel.: +7 (926) 204-50-60<br>
><br>
> Skype: MAKAPOB.AJIEKCAHDP<br>
><br>
><br>
><br>
> --<br>
> Kind Regards,<br>
> Alexander Makarov,<br>
> Senoir Software Developer,<br>
><br>
> Mirantis, Inc.<br>
> 35b/3, Vorontsovskaya St., 109147, Moscow, Russia<br>
><br>
> Tel.: +7 (495) 640-49-04<br>
> Tel.: +7 (926) 204-50-60<br>
><br>
> Skype: MAKAPOB.AJIEKCAHDP<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><font>Best Regards,</font></div><div><font>Nikolay</font></div></div></div>
</div>