Bug 1369597

Summary: [RFE] Separation of Service Accounts and Users for ClusterPolicy
Product: OpenShift Container Platform Reporter: Steven Walter <stwalter>
Component: RFEAssignee: David Eads <deads>
Status: CLOSED WONTFIX QA Contact: Chuan Yu <chuyu>
Severity: high Docs Contact:
Priority: medium    
Version: 3.2.0CC: aos-bugs, ccoleman, erich, haowang, jokerman, mbarrett, mfojtik, mmccomas, stwalter, wsun
Target Milestone: ---   
Target Release: 3.7.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-12-12 16:37:09 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:

Description Steven Walter 2016-08-23 22:35:13 UTC 
1. Proposed title of this feature request
Separation of Service Accounts and Users for ClusterPolicy

3. What is the nature and description of the request?
 
Customer wants to have a role within a namespace (like edit or admin) that has:
- All the privileges of edit
- The ability to create a service account
- The ability to give that service account view/edit privileges
- NOT the ability to modify local role privileges
 
This does not appear possible currently due to the inability to have more granular access to the "add-role-to-user" command. A user with the admin role in a project can do both, a user with the edit role can do neither.

5. How would the customer like to achieve this? (List the functional requirements here)
Essentially, they want the user be able to run:

$ oc policy add-role-to-user view system:serviceaccount:top-secret:robot
but NOT:
$ oc policy add-role-to-user view realUser
 

7. Is there already an existing RFE upstream or in Red Hat bugzilla?
not that I can tell
Comment 2 David Eads 2016-08-24 12:25:13 UTC 
This intersects with the ability to control which subjects can be bound in a
Comment 4 Michal Fojtik 2017-06-09 14:07:14 UTC 
Quoting David on the trello:

I think that this is unreasonable because different permissions are different. If I grant Rebecca edit powers, when I later remove those powers from her, I do not have to inspect the audit trail to see if she granted herself the powers in some other way (different account maybe?).

If I allow the edit role the power to bind a role (and that's what this is, grant powers to someone else), that role becomes admin.

I would say that this use-case could probably be satisfied by using scoped user tokens. Create a scoped for your user that is scoped down view powers and give it away. If I remove user Rebecca, then her scoped tokens die too.

--> Is this enough info for the customer? Does the scoped user tokens satisfy what they want?
Comment 5 Steven Walter 2017-06-09 14:19:08 UTC 
Michal, I do not understand what "scoped user tokens" means. Is this a token (like an sa token) that a user could use to grant roles? Or is it a token that has a view role? or...? Is this a proposed feature change or a name for somethign we can already do?