Bug 907084 - [RFE][keystone]: Default role privileges "is admin" , that role can view/modify/delete items of different tenants
[RFE][keystone]: Default role privileges "is admin" , that role can view/modi...
Status: CLOSED NOTABUG
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-keystone (Show other bugs)
2.0 (Folsom)
Unspecified Unspecified
high Severity high
: ga
: 6.0 (Juno)
Assigned To: Adam Young
Udi
: FutureFeature, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-03 03:46 EST by Ofer Blaut
Modified: 2016-04-26 15:59 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-10-08 18:33:12 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
delete VMs of other tenants (7.57 KB, text/plain)
2013-02-03 03:46 EST, Ofer Blaut
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 968696 None None None Never

  None (edit)
Description Ofer Blaut 2013-02-03 03:46:59 EST
Created attachment 692219 [details]
delete VMs of other tenants

Description of problem:

1. When customer create new user with admin role and attach it to specific tenant  , that user  can view/modify/delete items of different tenants ( including network/VMs ..... ).
2.When customer create new user with new role, the default role privileges are of admin of that tenant. 
This user modify/delete including network/VMs ...


( Attached example per item 1 
Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:

ITEM 1 
1. create few tenants with VMs and networks
2. create new user "TEST" with admin role per one of the tenants
3. login using that user 
4. list networks and VMs  ( of other tenents as well - nova list --all-tenants 1
 )
5. delete VMs/Networks belong to other tenants  
  

ITEM 2
1. create few tenants with VMs and networks
2. create new user "TEST" with "BLANK" role per one of the tenants
3. login using that user 
4. list networks and VMs  
5. delete VMs/Networks belong to that tenant 


Actual results:


1. Admin role should be per its tenant.
2. The default role privileges must be none to any operation.

Expected results:


Additional info:
Comment 2 Adam Young 2013-02-04 13:57:49 EST
Keysteon just checks "is_admin" and grants that role to a user if they have admin in any tenant.  This needs RBAC support.
Comment 3 Adam Young 2013-02-04 19:43:14 EST
This is a known issue.  Although the admin role is assigned per tenant, it is a defacto global role.

https://lists.launchpad.net/openstack/msg09332.html


Works as designed, but I do not like the design.  We will fix this in grizzley.
Comment 4 Adam Young 2013-02-04 19:43:49 EST
Correction, we will fix in Havana, as we are too close to the Grizzly deadline to address it.
Comment 5 Omri Hochman 2013-08-04 09:49:42 EDT
Looking to write a test-plans for this feature request, in order to do it I'll need more information about the new design and the expected behavior. 

Current behavior: 
------------------
1) The admin role is 'global' (*Not* per tenant) .  When creating user with admin role - that user will be able to control objects from all different tenants.

* Other regular users (which are not with admin-role) are limited to perform actions only on the objects from their tenant. 

2) Using 'keystone bootstrap' without specifying '--role-name' - this command will create a user with default admin-role (default="admin").  


What the new behavior will be like?
Comment 9 Udi 2014-02-02 09:32:54 EST
Is there a way to specify, in the policy.json file, that admin_required requires the admin role AND a belonging to the tenant? For example:

    "admin_required": [["role:admin], [project_id:%(project_id)s"]],

The problem is, that a rule such as the above will provide you the admin priviliges if you have the admin role OR you are a member of the tenant, which is not the desired functionality. Can you make rules with AND as well as OR in the policy.json file, and how?
Comment 10 Adam Young 2014-02-11 17:04:36 EST
The upstream policy file has a better alternative that you can see here:

https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json

This should be the default policy file in the future.
Comment 11 Nathan Kinder 2014-02-11 17:08:36 EST
(In reply to Adam Young from comment #10)
> The upstream policy file has a better alternative that you can see here:
> 
> https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.
> json
> 
> This should be the default policy file in the future.

Will you be filing an upstream launchpad bug or blueprint for this for Icehouse?  Once that is done, We should link this bug to the blueprint.
Comment 12 Adam Young 2014-02-24 10:18:07 EST
Test plan looks good as far as it goes.  I would like to see some addtional testing done on updates, with specific methods for disable separate from updating descriptions for domains and projects.
Comment 14 Udi 2014-02-26 02:37:44 EST
Adam, I refactored the test plan as you proposed and added tests for update. The last 2 steps in the test plan are still just placeholders, but please review it here:

https://tcms.engineering.redhat.com/plan/12516/openstackkeystonecorerbac-in-multiple-domains#reviewcases
Comment 15 Nathan Kinder 2014-10-08 18:33:12 EDT
The policy.v3cloudsample file should be included in future RHEL OSP versions, though I don't think it will be the default since it's designed for multi-domain deployments.  We are planning to add this policy file in an OSP 5 async update as mentioned in bug 1149425.  We can eventually move towards using this policy file by default if we start setting up domains by default (though we will possibly need more v3 adoption before that can happen).

This specific bug is about using a role named 'admin', which is global as has been previously described.  This is the way that role works in the old policy, and I don't think we can just change that without breaking things for existing deployments.  Policy can of course be customized if a different behavior is desired.

Closing this as NOTABUG.

Note You need to log in before you can comment on or make changes to this bug.