Implement oc adm policy why-can for RBAC scan usecases

[Acedus]

Hi, couldn't find a contribution format so instead I'll be using k8s'.

What would you like to be added?

Add a new admin command why-can that given positional arguments [verb] [resource] [identity] prints a list of RBs/CRBs that grant the specified identity the specified verb on the specified resource.

Why is this needed?

Similarly to the existing who-can, RBAC in large multi-tenant clusters has a tendency to grow out of control, leaving admins to figure out which RBs and CRBs provide certain permissions to users as exercise. The why-can command trivializes that and allows admins to elucidate such concerns with ease.

Implementation wise it should be very similar to the current who-can implementation and I don't mind creating a PR for it.

[Acedus]

Feature already being worked on by another member of the community, closed.

[doronkg]

@Acedus and I began working on this, we'll provide updates on the progress.

[ardaguclu]

I think this is provided by kubectl auth can-i command which also exists in oc?

[ardaguclu]

Thank you for opening this issue. If there isn't any commands in neither kubectl nor oc. I'd recommend first opening issue in kubectl to verify whether it is requested feature or not before investing time and effort. I'm closing this in oc as the primary source of such command should be in kubectl first.

/close

[openshift-ci[bot]]

@ardaguclu: Closing this issue.

In response to [this](https://github.com/openshift/oc/issues/1769#issuecomment-2117496824): >Thank you for opening this issue. If there isn't any commands in neither kubectl nor oc. I'd recommend first opening issue in kubectl to verify whether it is requested feature or not before investing time and effort. I'm closing this in oc as the primary source of such command should be in kubectl first. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.

[Acedus]

Hi there @ardaguclu! Allow me to explain why this feature doesn't fit in kubectl.

The way in which RBAC on user and group subjects work in k8s is by examination of the authenticating user's client certificate which is parsed for its CN (the name of the user) and its organization (group). This means that in vanilla k8s, there is no concept of identity and no records of it, which makes inferring whether a specified user belongs to a certain group (and by extension whether certain role bindings apply to them) impossible.

With that said, OpenShift provides the user API which enables this lookup and consequentially this proposal.

To address your former question, oc auth can-i (even when used with impersonation) yields a boolean response, omitting the information which is sought after by admins (what precisely grants the permissions over the specified verb and resource).

I hope this clarifies things.

[ardaguclu]

/reopen

[openshift-ci[bot]]

@ardaguclu: Reopened this issue.

In response to [this](https://github.com/openshift/oc/issues/1769#issuecomment-2126354660): >/reopen Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.