Open Stack

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 
> <mailto: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 <http://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:unsubscribe  <mailto:OpenStack-dev-request at 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 at lists.openstack.org?subject:unsubscribe
>     <http://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 at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150211/8da253d5/attachment.html>