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 <amaka...@mirantis.com <mailto:amaka...@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 <ayo...@redhat.com
    <mailto:ayo...@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
        <ayo...@redhat.com <mailto:ayo...@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
            <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 
 <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




-- 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-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




-- 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-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

Reply via email to