Bug 1326395 - [RFE] Implement Secure RBAC Project Scoped Personas within heat
Summary: [RFE] Implement Secure RBAC Project Scoped Personas within heat
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-heat
Version: 17.0 (Wallaby)
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
: ---
Assignee: OSP Team
QA Contact: David Rosenfeld
URL:
Whiteboard:
Depends On: 1228474 1801416
Blocks: 1381612
TreeView+ depends on / blocked
 
Reported: 2016-04-12 15:02 UTC by Jaison Raju
Modified: 2023-01-10 15:31 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-01-10 15:31:58 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 767161 0 None NEW Implement secure RBAC 2021-03-01 09:21:32 UTC
Red Hat Issue Tracker OSP-753 0 None None None 2021-12-10 14:49:40 UTC

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.


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