Open Stack

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 <amakarov at 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 <ayoung at 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 <ayoung at 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 <ayoung at 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-request at 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-request at 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 at 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-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
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at 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-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
>
> __________________________________________________________________________
> 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/20150216/23fca7e9/attachment.html>