On Wed, Feb 11, 2015 at 9:10 PM, Adam Young <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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:[email protected]?subject:unsubscribe
<mailto:[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Best Regards,
Nikolay
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:[email protected]?subject:unsubscribe
<mailto:[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
