policy-rules | Add Roles and ClusterRoles columns

[Joseph Moukarzel]

What would you like to be added:

When performing a
rbac-tool policy-rules {serviceAccount}
I would like to have 2 columns at the end, where for each action it shows from which (cluster)role it gets the right to do it. For example:

Why is this needed:
If you want to manage (specifically remove for my case) an action that a SA can perform on a resource, it would be neat to see from which (cluster)roles this service account gets its rights.

[gadinaor-r7]

@Joseph94m - thanks for submitting this enhancement request - does the screen shot suggest you've gone through the effort of implementing this additional functionality?

[Joseph Moukarzel]

@gadinaor The screenshot was handcrafted; however, I've worked on this feature a bit today (from the master branch currently tagged at 1.2.1).

Unrelated: I noticed something a bit odd. The results of the lookup command are different in the 1.2.0 and the 1.2.1 .The 1.2.0 labels ClusterRoles as Roles when they are used on a namespaced (i.e. with a Rolebinding).

Is the change from 1.2.0 to 1.2.1 intentional or a regression?

Concerning the feature of adding Roles/ClusterRoles, I have done some work on that and I am happy to say that I got something working although it needs further validations especially to make sure that it doesn't break anything especially in other functions, as I touched subject_permissions.go. I didn't see any test packages I could run from the make file.

I've pushed the branch on my fork under feature/policy-rules-roles if you'd like to view my changes. I will also review the functional aspect with a colleague who will be using this functionality to administrate the cluster.

here is a sample output:

One of the first things you may notice is that there are less lines on the left table than on the right one. This is normal as the results returned by the current rbac-tool policy-rules does have duplicates. In the change I propose, duplicates (defined as having the same permission from multiple (cluster)roles) are compacted.

[Joseph Moukarzel]

In case you were wondering what the roles and bindings are

Roles:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: monitoring
  name: chaching
rules:
- apiGroups: ["","extensions", "apps"]
  resources: ["*"]
  verbs: ["get"]
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: accessor2
rules:
- apiGroups: ["","extensions", "apps"]
  resources: ["*"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["pods", "secrets"]
  verbs: ["get", "watch", "list"]
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: monitoring
  name: chaching2
rules:
- apiGroups: ["","extensions", "apps"]
  resources: ["*"]
  verbs: ["get"]

bindings: we use rbac-manager

apiVersion: rbacmanager.reactiveops.io/v1beta1
kind: RBACDefinition
metadata:
  name: rbac-tester
rbacBindings:
  - name: rbac-tester
    subjects:
      - kind: ServiceAccount
        name: rbac-tester
        namespace: kube-system
    roleBindings:
       - namespace: monitoring
         role: chaching
       - namespace: monitoring
         role: chaching2
       - namespace: default
         role: chaching2
       - clusterRole: accessor2
         namespace: default
       - clusterRole: accessor2
         namespace: monitoring
       - clusterRole: cluster-admin
         namespace: monitoring 
    clusterRoleBindings:
      - clusterRole: cluster-admin
      - clusterRole: accessor2

[gadinaor-r7]

In case you were wondering what the roles and bindings are

Roles:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: monitoring
  name: chaching
rules:
- apiGroups: ["","extensions", "apps"]
  resources: ["*"]
  verbs: ["get"]
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: accessor2
rules:
- apiGroups: ["","extensions", "apps"]
  resources: ["*"]
  verbs: ["get"]
- apiGroups: [""]
  resources: ["pods", "secrets"]
  verbs: ["get", "watch", "list"]
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: monitoring
  name: chaching2
rules:
- apiGroups: ["","extensions", "apps"]
  resources: ["*"]
  verbs: ["get"]

bindings: we use rbac-manager

apiVersion: rbacmanager.reactiveops.io/v1beta1
kind: RBACDefinition
metadata:
  name: rbac-tester
rbacBindings:
  - name: rbac-tester
    subjects:
      - kind: ServiceAccount
        name: rbac-tester
        namespace: kube-system
    roleBindings:
       - namespace: monitoring
         role: chaching
       - namespace: monitoring
         role: chaching2
       - namespace: default
         role: chaching2
       - clusterRole: accessor2
         namespace: default
       - clusterRole: accessor2
         namespace: monitoring
       - clusterRole: cluster-admin
         namespace: monitoring 
    clusterRoleBindings:
      - clusterRole: cluster-admin
      - clusterRole: accessor2

@Joseph94m - yeah v1.2.1 had some slight changes with how ClusterRoles and binidngs are processed (see here)

Output on v1.2.1 looks more consistent with the above rbac-manager CRD (rbac-tester)

[Gadi Naor]

@Joseph94m - with #43 release I closed this issue .
#43 doesn't address collapsing duplicate rules or rules that overlap other rules.

This should probably become an additional CLI flag for policy-rules command (see #44)