Bug 1256869 - Deleting Users and Identity does not remove Authorization Settings
Deleting Users and Identity does not remove Authorization Settings
Status: CLOSED ERRATA
Product: OpenShift Container Platform
Classification: Red Hat
Component: Auth (Show other bugs)
3.0.0
Unspecified Unspecified
medium Severity low
: ---
: ---
Assigned To: Jordan Liggitt
Ma xiaoqiang
: NeedsTestCase
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-25 11:50 EDT by Ryan Howe
Modified: 2016-07-03 20:46 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-26 14:16:20 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ryan Howe 2015-08-25 11:50:08 EDT
Description of problem:

-Deleting Users and Identity does not remove Authorization Settings  
-After deleting users and changing Authentication, users still show as having Authorization 

Version-Release number of selected component (if applicable):
v3.0.1.0

How reproducible:
Every time 

Steps to Reproduce:
1. oc delete user 
2. oc delete identity 
3. oc describe policyBindings :default
4. users are still showing 

Actual results:

users still show with authorization after being deleted   

Expected results:

all remnants of the user gets removed when deleted. 


Additional info:

Would be nice to have documentation on how to properly remove users fully
Comment 2 Jordan Liggitt 2015-08-25 12:44:01 EDT
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)
Comment 5 Nick Lane 2015-10-15 15:50:31 EDT
I've encountered the same issueon OSE 3.0.2. This is a concern for our customer. Can we raise the severity?
Comment 7 Jordan Liggitt 2015-10-15 22:05:22 EDT
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.
Comment 8 Eric Rich 2015-10-16 10:02:46 EDT
(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)?
Comment 9 Jordan Liggitt 2015-10-16 10:44:59 EDT
> 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.
Comment 10 David Eads 2015-11-30 10:06:20 EST
>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.
Comment 11 Jordan Liggitt 2015-12-09 17:37:03 EST
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`
Comment 12 David Eads 2015-12-10 08:20:04 EST
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?
Comment 13 Jordan Liggitt 2015-12-10 08:31:23 EST
That would have prevented it (and still could, with --cascade=false), but a better way is to delete the useridentitymapping for the identity
Comment 14 David Eads 2015-12-10 09:05:20 EST
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.
Comment 15 Jordan Liggitt 2015-12-10 11:50:32 EST
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
Comment 16 Jordan Liggitt 2015-12-15 16:40:54 EST
Merged to origin in https://github.com/openshift/origin/pull/6252
Comment 17 weiwei jiang 2016-01-14 03:30:36 EST
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
Comment 19 errata-xmlrpc 2016-01-26 14:16:20 EST
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

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