RBAC Migration Followup #25: Deprecate policy commands in favor of RBAC equivalents

[enj]

Add cobra.Command.Deprecated to the following commands:

1. oc adm policy {add|remove}-{cluster-}role-{to|from}-{user|group} ---> oc {create|edit} {cluster}role{binding}
2. oc adm policy reconcile-cluster-role-{bindings} ---> oc auth reconcile
3. oc policy can-i ---> oc auth can-i
4. oc adm policy remove-{user|group} ---> oc {delete|edit} rolebinding
5. Update docs https://docs.openshift.org/latest/admin_guide/manage_rbac.html#managing-role-bindings
6. Update ansible playbooks to use RBAC commands instead

Deprecated should contain a pointer to the RBAC equivalent command. The CLI completions will have to be regenerated since we do not include completions for deprecated commands.

@liggitt @deads2k any others come to mind?

cc @bparees @openshift/sig-security @juanvallejo @fabianofranz

[bparees]

oc adm policy {add|remove|-{cluster-}role-{to|from}-{user|group} ---> oc create {cluster}role{binding}

I still think this is a bad user experience.

1. I now need to come up w/ unique names every time i want to give a user a new rolebinding (and remember/determine that name when i want to remove it)
2. it explodes the number of etcd objects (one binding object per role assignment per user)

[bparees]

(my comments only apply to (1) obviously. I have no opinion on (2) and (3))

[enj]

I still think this is a bad user experience.

I do agree that it is less convenient, but I find it significantly easier to understand what is actually happening when you run these commands. For example, add-role-to-user, by default, creates or edits a role binding to a cluster role. This is hard to reason about, especially when you run a bunch of these commands together.

I now need to come up w/ unique names every time i want to give a user a new rolebinding (and remember/determine that name when i want to remove it)

Yeah, it forces you to take ownership of the objects you are creating. It is explicit, and also less convenient. You can also edit an existing object, which requires you to understand the objects.

it explodes the number of etcd objects (one binding object per role assignment per user)

Kube seems to survive with this. The whole behavior of these commands was built around etcd2's poor scaling with a large number of objects. Let's hope etcd3 is beyond that.

[bparees]

Kube seems to survive with this.

Kube also survives w/ the secrets problem. They don't run the scale we do as I understand it.

[simo5]

@bparees I think this is mitigated by the fact that we do not force the creation of objects as we do for secrets. Asmins that end up creating large amount of objects unnnecessarily can be coached and helped to consolidate those, so at least the size problem is manageable where it makes sense.
This is to say I do not think size matters should influence this issue.

[simo5]

@enj on point 1, should we instead point to some other command to eidt groups ?
I am not confortable pointing at a create command from a modify command, some people know what they are doing and they deserve to be pointed at how to modify objects, telling them to create new ones is not helpful or appropriate in all cases.

[enj]

Kube also survives w/ the secrets problem. They don't run the scale we do as I understand it.

Sure but secrets are large (because of the embedded cert) and we have controllers auto create (and recreate if deleted) a bunch of them per namespace. RBAC objects are small, and we only auto create a few for the SAs and admin user when the project is created. Any extra objects are purely user driven.

[simo5]

Point n. 4 doesn't really have equivalents. While the other commands can reasonably transitioned to oc edit rolebindings as generally you are going to edit a specific role/binding, the command in 4 is more complex and removes a user from all namepace roles (even though it doesn't touch cluster rolebindings). I'll leave that one out as I think it falls off the "equivalent" charter for this issue.