Open Stack

Hello!

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.

Thank you for clarification!


On Mon, Feb 16, 2015 at 11:30 PM, Jamie Lennox <jamielennox at redhat.com>
wrote:

>
>
> ----- 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
> >
>
> __________________________________________________________________________
> 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
>



-- 
Best Regards,
Nikolay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150218/fd746c92/attachment.html>