[openstack-dev] [keystone] [nova]
Adam Young
ayoung at redhat.com
Mon Feb 23 15:27:00 UTC 2015
On 02/16/2015 05:00 AM, Nikolay Makhotkin wrote:
> Well, if we use trust-scoped token for getting server-list from nova
> (simply use nova.servers.list() ),
>
> Novaclient somehow tries to get another token:
> https://github.com/openstack/python-novaclient/blob/master/novaclient/client.py#L690-L724
>
> Actually, novaclient does this request: (found from debug of novaclient)
So this sounds like a bug in Nova client. Jamie Lennox has been working
with the various client teams to get the using the Auth plugin
architecture and session management from Keystone client to try and make
the usage consistent.
>
> 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
> <amakarov at mirantis.com <mailto:amakarov at mirantis.com>> 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 <ayoung at redhat.com
> <mailto: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 <mailto: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 <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 <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
>>
>>
>>
>>
>> --
>> 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: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
>
>
>
>
> --
> 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: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/20150223/645aab3a/attachment.html>
More information about the OpenStack-dev
mailing list