Bug 1256869

This is a similar issue to https://bugzilla.redhat.com/show_bug.cgi?id=1192310

Etcd is not a relational data store, so there are no links from a user to every rolebinding in every namespace.

(the same issue exists for groups and rolebindings as well)

I've encountered the same issueon OSE 3.0.2. This is a concern for our customer. Can we raise the severity?

Pruning logic is needed to sweep rolebindings and remove any that connect to:
- removed roles
- removed users
- removed groups

That command would need to be built, then it could be invoked via cron like other pruning commands.

Part of what makes pruning role bindings tricky is that users aren't actually represented in the system until they log in, but you can add them to roles via a prospective role binding before they log in. A pruning task would not be able to distinguish between a role granted to a user who has not yet logged in, and one granted to a user that has been deleted.

(In reply to Jordan Liggitt from comment #7)
> Part of what makes pruning role bindings tricky is that users aren't
> actually represented in the system until they log in, but you can add them
> to roles via a prospective role binding before they log in. A pruning task
> would not be able to distinguish between a role granted to a user who has
> not yet logged in, and one granted to a user that has been deleted.

In v2 we had options to 'oo-admin-ctl-user' (the -c option) that would create a user for you prior to them logging in. Is something like this needed for the roll commands as well? 

Should we default to creating users (and providing an option to not create the user)?

> In v2 we had options to 'oo-admin-ctl-user' (the -c option) that would create a user for you prior to them logging in. Is something like this needed for the role commands as well?

We already have an API for users and identities, which cluster admins could use to provision users. However, people with much lower permissions (like project admins) can grant roles to users, but should have no ability to create or list all users.

> Should we default to creating users (and providing an option to not create the user)?

No. In addition to the user, you need to know which identity is going to allow logging in as that user. That information is not available when granting a role, so the user cannot be auto-provisioned in response.

>Pruning logic is needed to sweep rolebindings and remove any that connect to:
- removed roles
- removed users
- removed groups

Even a reaper would be an improvement.  Clearly not perfect, but it would cleanup in the common case of using our cli.

Adding reapers in https://github.com/openshift/origin/pull/6252

`oc delete user X` will:
* remove cluster role bindings for the user
* remove namespaced role bindings for the user
* remove the user from any sccs
* remove identities for the user
* remove the user

`oc delete group X` will:
* remove cluster role bindings for the group
* remove namespaced role bindings for the group
* remove the group from any sccs
* remove identities for the group
* remove the group

The cascade behavior can be opted out of by adding `--cascade=false`

Wasn't deleting a user and not its associated identity a way to blacklist a particular identity and prevent it from authenticating forever regardless of mappingMethod?

That would have prevented it (and still could, with --cascade=false), but a better way is to delete the useridentitymapping for the identity

Deleting the useridentitymapping would have left the rolebindings in place.  I think that a cluster-admin would expect that deleting a user would remove all of its associated permissions, but I don't think they'd expect the user to be recreated simply by having the identity re-authenticate.

Also, we should probably have a followup to remove users from the groups they belong to.

revision:

`oc delete user X` will:
* remove cluster role bindings for the user
* remove namespaced role bindings for the user
* remove the user from any sccs
* remove the user from any groups
* **leave** identities for the user
* remove the user

`oc delete group X` will:
* remove cluster role bindings for the group
* remove namespaced role bindings for the group
* remove the group from any sccs
* remove the group

Merged to origin in https://github.com/openshift/origin/pull/6252

checked with devenv-centos7_3136, and the issue has been fixed. 

For user:
1. $ oadm policy add-cluster-role-to-user view wjiang
$ oc get clusterrolebindings view
NAME      ROLE      USERS     GROUPS    SERVICE ACCOUNTS   SUBJECTS
view      /view     wjiang               
2. $ oadm policy add-role-to-user view wjiang -n default
$ oc get rolebindings view -n !$
oc get rolebindings view -n default
NAME      ROLE      USERS     GROUPS    SERVICE ACCOUNTS   SUBJECTS
view      /view     wjiang    
3. $ oadm policy add-scc-to-user privileged wjiang
$ oc get scc privileged -o yaml 
......
users:
- system:serviceaccount:openshift-infra:build-controller
- system:serviceaccount:default:router
- wjiang
4. $ oc edit group this
groups/this
$ oc get group this -o yaml 
......
users:
- wjiang
5. $ oc delete user wjiang
user "wjiang" deleted
6. $ oc get clusterrolebindings view
NAME      ROLE      USERS     GROUPS    SERVICE ACCOUNTS   SUBJECTS
view      /view            
7. $ oc get rolebindings view -n default
NAME      ROLE      USERS     GROUPS    SERVICE ACCOUNTS   SUBJECTS
view      /view             
8. $ oc get scc privileged -o yaml 
......
users:
- system:serviceaccount:openshift-infra:build-controller
- system:serviceaccount:default:router
9. $ oc get identities
NAME                 IDP NAME      IDP USER NAME   USER NAME   USER UID
anypassword:wjiang   anypassword   wjiang          wjiang      d00382da-ba94-11e5-a579-0ecced385433


For group:
1. $ oadm policy add-cluster-role-to-group view this
$ oc get clusterrolebinding view
NAME      ROLE      USERS     GROUPS    SERVICE ACCOUNTS   SUBJECTS
view      /view               this                
2. $ oadm policy add-role-to-group view this -n default
$ oc get rolebindings view -n default
NAME      ROLE      USERS     GROUPS    SERVICE ACCOUNTS   SUBJECTS
view      /view               this
3. $ oadm policy add-scc-to-group privileged this
$ oc get scc privileged -o yaml 
......
groups:
- system:cluster-admins
- system:nodes
- this
4. $ oc delete group this
group "this" deleted
5. $ oc get clusterrolebinding view
NAME      ROLE      USERS     GROUPS    SERVICE ACCOUNTS   SUBJECTS
view      /view                                            
6. $ oc get rolebindings view -n default
NAME      ROLE      USERS     GROUPS    SERVICE ACCOUNTS   SUBJECTS
view      /view     
7. $ oc get scc privileged -o yaml 
......
groups:
- system:cluster-admins
- system:nodes

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2016:0070