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
<mailto: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 <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-requ...@lists.openstack.org?subject:unsubscribe
<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://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
__________________________________________________________________________
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
