Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150213/b2bd93dc/attachment.html>