Bug 1326395

Summary: [RFE] Implement Secure RBAC Project Scoped Personas within heat
Product: Red Hat OpenStack Reporter: Jaison Raju <jraju>
Component: openstack-heatAssignee: OSP Team <rhos-maint>
Status: CLOSED WONTFIX QA Contact: David Rosenfeld <drosenfe>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 17.0 (Wallaby)CC: broose, cylopez, djuran, dpeacock, hrybacki, igarciam, jjung, jraju, mburns, michele, molasaga, morazi, nkinder, nsatsia, pveiga, sbaker, shardy, srevivo, zbitter
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-01-10 15:31:58 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:
Bug Depends On: 1228474, 1801416    
Bug Blocks: 1381612    

Description Jaison Raju 2016-04-12 15:02:06 UTC
1. Proposed title of this feature request  
Need heat policy to be configured to include a read-only role .
  
3. What is the nature and description of the request?  
Customer has requirement of read-only admin role for all core services .

4. Why does the customer need this? (List the business requirements here)  
  A read-only admin user is necessary for customer environment .
  
Additional info:
The following bug is raised for keystone to add role .
This role can be configured in policy file .
Bug 1228474 - [RFE] Read only role for tenant access (edit) 
https://blueprints.launchpad.net/keystone/+spec/admin-readonly-role

Comment 3 Zane Bitter 2016-04-12 15:47:05 UTC
Unfortunately this is a big can of worms.

The problem with Keystone is that you cannot (securely) create a role with *less* privileges than the default. (This is because there are various ways for users to create a token that drops a role.) You can only reduce the default privileges and then create a role that has more privileges.

So making a change like this to the default policy (either upstream or in RHOS) would break existing deployments (since users previously created with write access would lose it). This is not impossible, but it would have to be done upstream, with a lot of notice, to have a migration strategy, and preferably to be done in concert with all other OpenStack projects. That's unlikely to happen in the near term.

The default policy is just that - a default. Customers can and should customise it to their particular requirements, and that is the approach that I would recommend here.

Comment 5 Zane Bitter 2016-05-10 13:49:48 UTC
The upstream change that I described above as unlikely to happen in the near term was actually discussed at the OpenStack Design Summit and there was general agreement that it should take place, though not until at least the Ocata or P time frame (OSP 11/12).

Just to be clear, we can and should make it possible for users to deploy customised policy files through Director. We can't make adding a read-only role the default without a comprehensive migration plan, which is now being co-ordinated upstream.