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
<[email protected] <mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
<[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
<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://[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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
