Well, if we use trust-scoped token for getting server-list from nova (simply use nova.servers.list() ),
Novaclient somehow tries to get another token: https://github.com/openstack/python-novaclient/blob/master/novaclient/client.py#L690-L724 Actually, novaclient does this request: (found from debug of novaclient) REQ: curl -i 'http://<my_host>:5000/v2.0/tokens' -X POST -H "Accept: application/json" -H "Content-Type: application/json" -H "User-Agent: python-novaclient" -d '{"auth": {"token": {"id": "78c71fb549244075b3a5d994baa326b3"}, "tenantName": "b0c9bbb541d541b098c3c0a92412720d"}}' I.e., this is the request for another auth token from keystone. Keystone here returns 403 because token in request is trust-scoped. Why I can't do this simple command using trust-scoped token? Note: Doing the keystone --os-token 5483086d91094a3886ccce1442b538a0 --os-endpoint http://<my_host>:5000/v2.0 tenant-list, it returns tenant-list (not 403). Note2: Doing the server-list request directly to api with trust-scoped token, it returns 200, not 403: curl -H "X-Auth-Token: 5483086d91094a3886ccce1442b538a0" http://192.168.0.2:8774/v3/servers { "servers": [ <list_of_servers> ] } How I can use trust-scoped tokrn via client? On Fri, Feb 13, 2015 at 9:16 PM, Alexander Makarov <amaka...@mirantis.com> wrote: > Adam, Nova client does it for some reason during a call to > nova.servers.list() > > > On Thu, Feb 12, 2015 at 10:03 PM, Adam Young <ayo...@redhat.com> wrote: > >> On 02/12/2015 10:40 AM, Alexander Makarov wrote: >> >> A trust token cannot be used to get another token: >> >> https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L154-L156 >> You have to make your Nova client use the very same trust scoped token >> obtained from authentication using trust without trying to authenticate >> with it one more time. >> >> >> >> Actually, there have been some recent changes to allow re-delegation of >> Trusts, but for older deployments, you are correct. I hadn't seen anywhere >> here that he was trying to use a trust token to get another token, though. >> >> >> >> On Wed, Feb 11, 2015 at 9:10 PM, Adam Young <ayo...@redhat.com> wrote: >> >>> On 02/11/2015 12:16 PM, Nikolay Makhotkin wrote: >>> >>> No, I just checked it. Nova receives trust token and raise this error. >>> >>> In my script, I see: >>> >>> http://paste.openstack.org/show/171452/ >>> >>> And as you can see, token from trust differs from direct user's token. >>> >>> >>> The original user needs to have the appropriate role to perform the >>> operation on the specified project. I see the admin role is created on the >>> trust. If the trustor did not have that role, the trustee would not be able >>> to exececute the trust and get a token. It looks like you were able to >>> execute the trust and get a token, but I would like you to confirm that, >>> and not just trust the keystone client: either put debug statements in >>> Keystone or call the POST to tokens from curl with the appropriate options >>> to get a trust token. In short, make sure you have not fooled yourself. >>> You can also look in the token table inside Keystone to see the data for >>> the trust token, or validate the token via curl to see the data in it. In >>> all cases, there should be an OS-TRUST stanza in the token data. >>> >>> >>> If it is still failing, there might be some issue on the Policy side. I >>> have been assuming that you are running with the default policy for Nova. >>> >>> http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json >>> >>> I'm not sure which rule matches for list servers (Nova developer input >>> would be appreciated) but I'm guessing it is executing the rule >>> >>> "admin_or_owner": "is_admin:True or project_id:%(project_id)s", >>> >>> Since that is the default. I am guessing that the project_id in question >>> comes from the token here, as that seems to be common, but if not, it might >>> be that the two values are mismatched. Perhaps there Proejct ID value from >>> the client env var is sent, and matches what the trustor normally works as, >>> not the project in question. If these two values don't match, then, yes, >>> the rule would fail. >>> >>> >>> >>> >>> On Wed, Feb 11, 2015 at 7:55 PM, Adam Young <ayo...@redhat.com> wrote: >>> >>>> On 02/11/2015 10:52 AM, Nikolay Makhotkin wrote: >>>> >>>> Hi ! >>>> >>>> I investigated trust's use cases and encountered the problem: When I >>>> use auth_token obtained from keystoneclient using trust, I get *403* >>>> Forbidden error: *You are not authorized to perform the requested >>>> action.* >>>> >>>> Steps to reproduce: >>>> >>>> - Import v3 keystoneclient (used keystone and keystoneclient from >>>> master, tried also to use stable/icehouse) >>>> - Import v3 novaclient >>>> - initialize the keystoneclient: >>>> keystone = keystoneclient.Client(username=username, >>>> password=password, tenant_name=tenant_name, auth_url=auth_url) >>>> >>>> - create a trust: >>>> trust = keystone.trusts.create( >>>> keystone.user_id, >>>> keystone.user_id, >>>> impersonation=True, >>>> role_names=['admin'], >>>> project=keystone.project_id >>>> ) >>>> >>>> - initialize new keystoneclient: >>>> client_from_trust = keystoneclient.Client( >>>> username=username, password=password, >>>> trust_id=trust.id, auth_url=auth_url, >>>> ) >>>> >>>> - create nova client using new token from new client: >>>> nova = novaclient.Client( >>>> auth_token=client_from_trust.auth_token, >>>> auth_url=auth_url_v2, >>>> project_id=from_trust.project_id, >>>> service_type='compute', >>>> username=None, >>>> api_key=None >>>> ) >>>> >>>> - do simple request to nova: >>>> nova.servers.list() >>>> >>>> - get the error described above. >>>> >>>> >>>> Maybe I misunderstood something but what is wrong? I supposed I just >>>> can work with nova like it was initialized using direct token. >>>> >>>> >>>> From what you wrote here it should work, but since Heat has been >>>> doing stuff like this for a while, I'm pretty sure it is your setup and not >>>> a fundamental problem. >>>> >>>> I'd take a look at what is going back and forth on the wire and make >>>> sure the right token is being sent to Nova. If it is the original users >>>> token and not the trust token, then you would see that error. >>>> >>>> >>>> -- >>>> Best Regards, >>>> Nikolay >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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 >>>> >>> >>> >>> >>> -- >>> Best Regards, >>> Nikolay >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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 >>> >>> >> >> >> -- >> 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:unsubscribehttp://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 >> >> > > > -- > 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 > > -- Best Regards, Nikolay
__________________________________________________________________________ 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