Re: [openstack-dev] [keystone][nova] "admin" role and "rule:admin_or_owner" confusion

[rezroo]

I am still confused how the "cloud admin" role is fulfilled in Liberty 
release. For example, I used "nova --debug delete" to see how the 
project:admin/user:admin deletes an instance of the demo project. 
Basically, we use the project:admin/user:admin token to get a list of 
instances for all tenants and then reference the instance of demo using 
the admin project tenant-id in the:


curl -g -i -X DELETE 
http://172.31.5.216:8774/v2.1/85b0992a5845455083db84d909c218ab/servers/6c876149-ecc4-4467-b727-9dff7b059390


So 85b0992a5845455083db84d909c218ab is admin tenant id, and 
6c876149-ecc4-4467-b727-9dff7b059390 is owned by demo project.


I am able to reproduce this using curl commands - but what's confusing 
me is that the token I get from keystone clearly shows is_admin is 0:


"user": {"username": "admin", "roles_links": [], "id": 
"9b29c721bc3844a784dcffbb8c8a47f8", "roles": [{"name": "admin"}], 
"name": "admin"}, "metadata": {"is_admin": 0, "roles": 
["6a6893ea36394a2ab0b93d225ab01e25"]}}}


And the rules for compute:delete seem to require is_admin to be true. 
nova/policy.json has two rules for "compute:delete":


/Line  81 "compute:delete": "rule:admin_or_owner",
Line  88 "compute:delete": "",/

First question - why is line 88 needed?

Second, on line  3 admin_or_owner definition requires is_admin to be true:

/"admin_or_owner": "is_admin:True or project_id:%(project_id)s",/

which if my understanding is correct, is never true unless the keystone 
admin_token is used, and is certainly not true the token I got using 
curl. So why is my curl request using this token able to delete the 
instance?


Thanks,

Reza


On 9/2/2016 12:51 PM, Morgan Fainberg wrote:


On Sep 2, 2016 09:39, "rezroo" > wrote:

>
> Hello - I'm using Liberty release devstack for the below scenario. I 
have created project "abcd" with "john" as Member. I've launched one 
instance, I can use curl to list the instance. No problem.

>
> I then modify /etc/nova/policy.json and redefine "admin_or_owner" as 
follows:

>
> "admin_or_owner":  "role:admin or is_admin:True or 
project_id:%(project_id)s",

>
> My expectation was that I would be able to list the instance in abcd 
using a token of admin. However, when I use the token of user "admin" 
in project "admin" to list the instances I get the following error:

>
> stack@vlab:~/token$ curl 
http://localhost:8774/v2.1/378a4b9e0b594c24a8a753cfa40ecc14/servers/detail 
-H "User-Agent: python-novaclient" -H "Accept: application/json" -H 
"X-OpenStack-Nova-API-Version: 2.6" -H "X-Auth-Token: 
f221164cd9b44da6beec70d6e1f3382f"
> {"badRequest": {"message": "Malformed request URL: URL's project_id 
'378a4b9e0b594c24a8a753cfa40ecc14' doesn't match Context's project_id 
'f73175d9cc8b4fb58ad22021f03bfef5'", "code": 400}}

>
> 378a4b9e0b594c24a8a753cfa40ecc14 is project id of abcd and 
f73175d9cc8b4fb58ad22021f03bfef5 is project id of admin.

>
> I'm confused by this behavior and the reported error, because if the 
project id used to acquire the token is the same as the project id in 
/servers/detail then I would be an "owner". So where is the "admin" in 
"admin_or_owner"? Shouldn't the "role:admin" allow me to do whatever 
functionality "rule:admin_or_owner" allows in policy.json, regardless 
of the project id used to acquire the token?

>
> I do understand that I can use the admin user and project to get all 
instances of all tenants:
> curl 
http://localhost:8774/v2.1/f73175d9cc8b4fb58ad22021f03bfef5/servers/detail?all_tenants=1 
-H "User-Agent: python-novaclient" -H "Accept: application/json" -H 
"X-OpenStack-Nova-API-Version: 2.6" -H "X-Auth-Token: $1"

>
> My question is more centered around why nova has the additional 
check to make sure that the token project id matches the url project 
id - and whether this is a keystone requirement, or only nova/cinder 
and programs that have a project-id in their API choose to do this. In 
other words, is it the developers of each project that decide to only 
expose some APIs for administrative functionality (such all-tenants), 
but restrict everything else to owners, or keystone requires this check?

>
> Thanks,
>
> Reza
>
>
> 
__

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

I believe this is a nova specific extra check. There is (iirc) a way 
to list out the instances for a given tenant but I do not recall the 
specifics.


Keystone does not know anything about the resource ownership in Nova. 
The Nova check is fully self-contained.


--Morgan
Please excuse brevity and typos, sent from a mobile device.



__

Re: [openstack-dev] [keystone][nova] "admin" role and "rule:admin_or_owner" confusion

[Morgan Fainberg]

On Sep 2, 2016 09:39, "rezroo"  wrote:
>
> Hello - I'm using Liberty release devstack for the below scenario. I have
created project "abcd" with "john" as Member. I've launched one instance, I
can use curl to list the instance. No problem.
>
> I then modify /etc/nova/policy.json and redefine "admin_or_owner" as
follows:
>
> "admin_or_owner":  "role:admin or is_admin:True or
project_id:%(project_id)s",
>
> My expectation was that I would be able to list the instance in abcd
using a token of admin. However, when I use the token of user "admin" in
project "admin" to list the instances I get the following error:
>
> stack@vlab:~/token$ curl
http://localhost:8774/v2.1/378a4b9e0b594c24a8a753cfa40ecc14/servers/detail
-H "User-Agent: python-novaclient" -H "Accept: application/json" -H
"X-OpenStack-Nova-API-Version: 2.6" -H "X-Auth-Token:
f221164cd9b44da6beec70d6e1f3382f"
> {"badRequest": {"message": "Malformed request URL: URL's project_id
'378a4b9e0b594c24a8a753cfa40ecc14' doesn't match Context's project_id
'f73175d9cc8b4fb58ad22021f03bfef5'", "code": 400}}
>
> 378a4b9e0b594c24a8a753cfa40ecc14 is project id of abcd and
f73175d9cc8b4fb58ad22021f03bfef5 is project id of admin.
>
> I'm confused by this behavior and the reported error, because if the
project id used to acquire the token is the same as the project id in
/servers/detail then I would be an "owner". So where is the "admin" in
"admin_or_owner"? Shouldn't the "role:admin" allow me to do whatever
functionality "rule:admin_or_owner" allows in policy.json, regardless of
the project id used to acquire the token?
>
> I do understand that I can use the admin user and project to get all
instances of all tenants:
> curl
http://localhost:8774/v2.1/f73175d9cc8b4fb58ad22021f03bfef5/servers/detail?all_tenants=1
-H "User-Agent: python-novaclient" -H "Accept: application/json" -H
"X-OpenStack-Nova-API-Version: 2.6" -H "X-Auth-Token: $1"
>
> My question is more centered around why nova has the additional check to
make sure that the token project id matches the url project id - and
whether this is a keystone requirement, or only nova/cinder and programs
that have a project-id in their API choose to do this. In other words, is
it the developers of each project that decide to only expose some APIs for
administrative functionality (such all-tenants), but restrict everything
else to owners, or keystone requires this check?
>
> Thanks,
>
> Reza
>
>
> __
> 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
>

I believe this is a nova specific extra check. There is (iirc) a way to
list out the instances for a given tenant but I do not recall the
specifics.

Keystone does not know anything about the resource ownership in Nova. The
Nova check is fully self-contained.

--Morgan
Please excuse brevity and typos, sent from a mobile device.
__
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-dev] [keystone][nova] "admin" role and "rule:admin_or_owner" confusion

[rezroo]

Hello - I'm using Liberty release devstack for the below scenario. I 
have created project "abcd" with "john" as Member. I've launched one 
instance, I can use curl to list the instance. No problem.


I then modify /etc/nova/policy.json and redefine "admin_or_owner" as 
follows:


"admin_or_owner":  "role:admin or is_admin:True or 
project_id:%(project_id)s",


My expectation was that I would be able to list the instance in abcd 
using a token of admin. However, when I use the token of user "admin" in 
project "admin" to list the instances I get the following error:


/stack@vlab:~/token$ curl 
http://localhost:8774/v2.1///378a4b9e0b594c24a8a753cfa40ecc14///servers/detail 
-H "User-Agent: python-novaclient" -H "Accept: application/json" -H 
"X-OpenStack-Nova-API-Version: 2.6" -H "X-Auth-Token: 
f221164cd9b44da6beec70d6e1f3382f"//
//{"badRequest": {"message": "Malformed request URL: URL's project_id 
'//378a4b9e0b594c24a8a753cfa40ecc14//' doesn't match Context's 
project_id '//f73175d9cc8b4fb58ad22021f03bfef5//'", "code": 400}}/


378a4b9e0b594c24a8a753cfa40ecc14 is project id of abcd and 
f73175d9cc8b4fb58ad22021f03bfef5 is project id of admin.


I'm confused by this behavior and the reported error, because if the 
project id used to acquire the token is the same as the project id in 
/servers/detail then I would be an "owner". So where is the "admin" in 
"admin_or_owner"? Shouldn't the "role:admin" allow me to do whatever 
functionality "rule:admin_or_owner" allows in policy.json, regardless of 
the project id used to acquire the token?


I do understand that I can use the admin user and project to get all 
instances of all tenants:
/curl 
http://localhost:8774/v2.1/f73175d9cc8b4fb58ad22021f03bfef5/servers/detail?all_tenants=1 
-H "User-Agent: python-novaclient" -H "Accept: application/json" -H 
"X-OpenStack-Nova-API-Version: 2.6" -H "X-Auth-Token: $1"/


My question is more centered around why nova has the additional check to 
make sure that the token project id matches the url project id - and 
whether this is a keystone requirement, or only nova/cinder and programs 
that have a project-id in their API choose to do this. In other words, 
is it the developers of each project that decide to only expose some 
APIs for administrative functionality (such all-tenants), but restrict 
everything else to owners, or keystone requires this check?


Thanks,

Reza

__
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