settingsLogin | Registersettings

[openstack-dev] [keystone] [trusts] [all] How trusts should work by design?

0 votes

Hello,

Decided to start a new thread due to too much technical details in old
thread.
(You can see thread [openstack-dev] [keystone] [nova] )

The problem: Trusts can not be used to retrieve a token for further work
with python-client.

I made some research for trust's use cases. The main goal of trusts is
clear to me: delegation of privileges of one user to another on specific
time (or limitless). But if I get a trust and then get a token from it, it
can not be used in any python-client. The reason why it happens so - is
'authenticate' method in almost all python-clients. This method request a
keystone for authentication and get a new auth token. But in case of
trust-scoped token it can't be true - this method always return '403
Forbidden' [1]

The question: Is there a way to create a trust and use it for requests to
any other service? E.g., We can get a token from trust and use it (but
actually, we are not).

Or am I misunderstanding trust's purpose? How are trusts should worked?

[1]
https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L154-L156

Best Regards,
Nikolay Makhotkin
@Mirantis


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Feb 16, 2015 in openstack-dev by Nikolay_Makhotkin (2,300 points)   4 7
retagged Mar 6, 2015 by admin

21 Responses

0 votes

Yeah, clarification from keystone folks would be really helpful.

If Nikolay’s info is correct (I believe it is) then I actually don’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 didn’t checked that yet myself.

So please help us understand which one of my following assumptions is correct?

We don’t understand what trusts are.
We use them in a wrong way. (If yes, then what’s the correct usage?)
Trust mechanism itself is in development and can’t be used at this point.
OpenStack clients need to be changed in some way to somehow bypass this keystone limitation?

Thanks

Renat Akhmerov
@ Mirantis Inc.

On 16 Feb 2015, at 19:10, Nikolay Makhotkin nmakhotkin@mirantis.com wrote:

Hello,

Decided to start a new thread due to too much technical details in old thread.
(You can see thread [openstack-dev] [keystone] [nova] )

The problem: Trusts can not be used to retrieve a token for further work with python-client.

I made some research for trust's use cases. The main goal of trusts is clear to me: delegation of privileges of one user to another on specific time (or limitless). But if I get a trust and then get a token from it, it can not be used in any python-client. The reason why it happens so - is 'authenticate' method in almost all python-clients. This method request a keystone for authentication and get a new auth token. But in case of trust-scoped token it can't be true - this method always return '403 Forbidden' [1]

The question: Is there a way to create a trust and use it for requests to any other service? E.g., We can get a token from trust and use it (but actually, we are not).

Or am I misunderstanding trust's purpose? How are trusts should worked?

[1] https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L154-L156 https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L154-L156


Best Regards,
Nikolay Makhotkin
@Mirantis


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 16, 2015 by Renat_Akhmerov (12,320 points)   2 4 7
0 votes

On Mon, Feb 16, 2015 at 09:02:01PM +0600, Renat Akhmerov wrote:
Yeah, clarification from keystone folks would be really helpful.
If Nikolayas info is correct (I believe it is) then I actually donat
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 didnat 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 --os-no-client-auth
--heat-url http://192.168.0.4:8004/v1/ 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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 16, 2015 by Steven_Hardy (16,900 points)   2 7 11
0 votes

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@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 Nikolayas 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 didnat 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 --os-no-client-auth
--heat-url http://192.168.0.4:8004/v1/ 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@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


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 16, 2015 by Alexander_V_Makarov (900 points)   1 2
0 votes

https://blueprints.launchpad.net/keystone/+spec/trust-scoped-re-authentication

On Mon, Feb 16, 2015 at 7:57 PM, Alexander Makarov amakarov@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@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 Nikolayas 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 didnat 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 --os-no-client-auth
--heat-url http://192.168.0.4:8004/v1/ 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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 16, 2015 by Alexander_V_Makarov (900 points)   1 2
0 votes

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@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 Nikolayas info is correct (I believe it is) then I actually donat
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 didnat 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

  1. 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.

  1. 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 --os-no-client-auth
--heat-url http://192.168.0.4:8004/v1/ 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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 16, 2015 by Renat_Akhmerov (12,320 points)   2 4 7
0 votes

----- Original Message -----
From: "Alexander Makarov" amakarov@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@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@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@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 Nikolayas info is correct (I believe it is) then I actually donat
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 didnat 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

  1. 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.

  1. 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 --os-no-client-auth
--heat-url http://192.168.0.4:8004/v1/ 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 cclient
from keystoneclient.v3 import client as k
client
from novaclient.v11 import client as nclient

a = v3.Password(authurl='http://keystone.test:5000/v3', username='user', password='pass', userdomainid='dom', trustid='abcd1234')
s = session.Session(auth=a)

k = kclient.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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 16, 2015 by Jamie_Lennox (3,460 points)   5 7
0 votes

Hello!

Nova client's CLI parameter 'bypassurl' 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@redhat.com
wrote:

----- Original Message -----

From: "Alexander Makarov" amakarov@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@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@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@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 Nikolayas 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 didnat 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

  1. 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.

  1. 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 --os-no-client-auth
--heat-url http://192.168.0.4:8004/v1/ 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 cclient
from keystoneclient.v3 import client as k
client
from novaclient.v11 import client as nclient

a = v3.Password(authurl='http://keystone.test:5000/v3', username='user',
password='pass', user
domainid='dom', trustid='abcd1234')
s = session.Session(auth=a)

k = kclient.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@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best Regards,
Nikolay


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 18, 2015 by Nikolay_Makhotkin (2,300 points)   4 7
0 votes

Hi,

This is about review:
https://review.openstack.org/#/c/156633/

1 line, can be controversial

Its purpose is to add the possibility not to use libguestfs for data
injection in nova, even when installed.

Not discussing about the fact that libguestfs should be preferred over
fuse mounts for data injection as much as possible because mounts are
more subject to causing security issues (and already have in the past
nova releases).

However, there are a lot of potential cases when libguestfs won't be
usable for data injection

This was the case here (fixed):
https://bugzilla.redhat.com/show_bug.cgi?id=984409

I entcountered a similar case more recently on powerkvm 2.1.0 (defect
with the libguestfs)

So just saying it could be good adding a simple config flag (set to True
by default, to keep the current behaviour untouched) to force nova not
using libguestfs without having to uninstall it and thus prevent other
users on the host from using it.

regards

raphael


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 18, 2015 by Raphael_Glon (300 points)   1
0 votes

Hi,

On 18 Feb 2015, at 23:54, Nikolay Makhotkin nmakhotkin@mirantis.com wrote:

Nova client's CLI parameter 'bypassurl' helps me. The client's API also has 'managementurl' 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!

I want to say an additional “thank you” from me for helping us solve this problem that’s been around for a while.

And just a small conceptual question: in my understanding since trust chaining has already landed this kind of reauthentication doesn’t make a lot of sense to me. Isn’t trust chaining supposed to mean that trust-scoped tokens a regular tokens should be considered equal? Or we should still assume that trust scoped tokens are sort of limited? If yes then how exactly they must be understood?

Thanks!

Renat Akhmerov
@ Mirantis Inc.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 19, 2015 by Renat_Akhmerov (12,320 points)   2 4 7
0 votes

On 18/02/15 18:23, Raphael Glon wrote:
Hi,

This is about review:
https://review.openstack.org/#/c/156633/

1 line, can be controversial

Its purpose is to add the possibility not to use libguestfs for data
injection in nova, even when installed.

Not discussing about the fact that libguestfs should be preferred over
fuse mounts for data injection as much as possible because mounts are
more subject to causing security issues (and already have in the past
nova releases).

However, there are a lot of potential cases when libguestfs won't be
usable for data injection

This was the case here (fixed):
https://bugzilla.redhat.com/show_bug.cgi?id=984409

I entcountered a similar case more recently on powerkvm 2.1.0 (defect
with the libguestfs)

So just saying it could be good adding a simple config flag (set to True
by default, to keep the current behaviour untouched) to force nova not
using libguestfs without having to uninstall it and thus prevent other
users on the host from using it.

A big -1 to this. You seem to be saying that there were bugs in a
library, which were fixed. News at 11. This isn't a realistic way to
manage a large software stack.

Matt
--
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Feb 19, 2015 by Matthew_Booth (4,680 points)   3 6 10
...