Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?
@Renat, They are conceptually different: - regular tokens are created for the owner of addressed resource - trust scoped tokens are for trustees and have some security restrictions. The case is about disallowing a trustee to aquire a regular token allowing him anything the trustor is allowed. It'd be an exploit. On Thu, Feb 19, 2015 at 9:01 AM, Renat Akhmerov rakhme...@mirantis.com wrote: Hi, On 18 Feb 2015, at 23:54, Nikolay Makhotkin nmakhot...@mirantis.com wrote: 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! 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?
@Renat, I like the idea. For now we have a spec: https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-trust-ext.rst It's consiedered to be enough but as for me it lacks TL;DR section :) On Thu, Feb 19, 2015 at 8:15 PM, Renat Akhmerov rakhme...@mirantis.com wrote: On 19 Feb 2015, at 18:32, Alexander Makarov amaka...@mirantis.com wrote: @Renat, They are conceptually different: - regular tokens are created for the owner of addressed resource - trust scoped tokens are for trustees and have some security restrictions. The case is about disallowing a trustee to aquire a regular token allowing him anything the trustor is allowed. It'd be an exploit. Alexander, Thanks for explanations. I kind of get the general idea, yes. What is best source where we could go and read in details about that? The only page I was able to find is https://wiki.openstack.org/wiki/Keystone/Trusts but it would be nice if something more tutorial-like existed. Renat Akhmerov @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?
On 19 Feb 2015, at 18:32, Alexander Makarov amaka...@mirantis.com wrote: @Renat, They are conceptually different: - regular tokens are created for the owner of addressed resource - trust scoped tokens are for trustees and have some security restrictions. The case is about disallowing a trustee to aquire a regular token allowing him anything the trustor is allowed. It'd be an exploit. Alexander, Thanks for explanations. I kind of get the general idea, yes. What is best source where we could go and read in details about that? The only page I was able to find is https://wiki.openstack.org/wiki/Keystone/Trusts https://wiki.openstack.org/wiki/Keystone/Trusts but it would be nice if something more tutorial-like existed. Renat Akhmerov @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?
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 jamielen...@redhat.com wrote: - Original Message - From: Alexander Makarov amaka...@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 amaka...@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 sha...@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
Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?
Hi, On 18 Feb 2015, at 23:54, Nikolay Makhotkin nmakhot...@mirantis.com wrote: 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! 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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?
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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?
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 sha...@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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 amaka...@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 sha...@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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?
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 sha...@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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?
- Original Message - From: Alexander Makarov amaka...@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 amaka...@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 sha...@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
Re: [openstack-dev] [keystone] [trusts] [all] How trusts should work by design?
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 nmakhot...@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-projectclient. 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
