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]> 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]> 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]> 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, 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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [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
