Bug 1369597 - [RFE] Separation of Service Accounts and Users for ClusterPolicy
Summary: [RFE] Separation of Service Accounts and Users for ClusterPolicy
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: RFE
Version: 3.2.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ---
: 3.7.0
Assignee: David Eads
QA Contact: Chuan Yu
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-23 22:35 UTC by Steven Walter
Modified: 2020-08-13 08:33 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-12 16:37:09 UTC
Target Upstream Version:


Attachments (Terms of Use)

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?


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