Bug 907084
| Summary: | [RFE][keystone]: Default role privileges "is admin" , that role can view/modify/delete items of different tenants | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Ofer Blaut <oblaut> | ||||
| Component: | openstack-keystone | Assignee: | Adam Young <ayoung> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Udi Kalifon <ukalifon> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 2.0 (Folsom) | CC: | aberezin, ajeain, apevec, ayoung, dpal, nkinder, ohochman, sgordon | ||||
| Target Milestone: | ga | Keywords: | FutureFeature, Triaged | ||||
| Target Release: | 6.0 (Juno) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Enhancement | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-10-08 22:33:12 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Keysteon just checks "is_admin" and grants that role to a user if they have admin in any tenant. This needs RBAC support. 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. Correction, we will fix in Havana, as we are too close to the Grizzly deadline to address it. 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? 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?
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. (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. 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. 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 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. |
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: