RBAC-Manager could augment `resourceName` behavior in `Role` and `ClusterRole`

[ejether]

Problem: The resourceNames property in RBAC Role and ClusterRole is limited in usefulness because it is not currently possible to scope dynamically to pods created by a Deployment, Daemonset, StatefulSet, etc, because the value in resourceNames is an exact match and not a pattern match. Therefore, using a pod controller name to define a set of Pods in the Role or ClusterRole is not possible.

There is some more discussion here: https://github.com/kubernetes/kubernetes/issues/56582

Idea: It would be rad if you could define a pod controller instance name, {Deployment: webapp} for example, and have the Role or ClusterRole dynamically recognize the child Pods of that controller and grant access.

Proposal: Add new feature of RBAC-Manager to edit roles in place to grant this access. In both of two ways:

• define a pod controller instance to grant access to the pod owned by it
• define a pattern match and a object type (say for all pods that start with dev)

Value: @rbren brought up the basic ideas but the current RBAC segmentation capability is limited if the workload architecture is not hyper-segmented in namespaces. For example, if you wanted to grant front end devs access to get the logs from only the front end related pods in a shared production namespace you would not be able to do that effectively. This could also apply to dev/test infra.

Possible Implementations (not exhaustive):

1. User creates and annotates an empty role for RBAC-Manager to interact with. The annotations define what patterns or pod controller to reference. RBAC-Manager infers the resources and adds them to the role dynamically For example:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: dynamic-webapp-devs
  annotations:
    rbac-manager.dynamic_resource_names: true
    rbac-manager.pod_controller_types: [Deployment, StatefuleSet]
    #rbac-manager.pod_controller_name: webapp
    rbac-manager.pod_controller_match: ^webapp-.*
rules:
  resources: ["pods"]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "update"]

1. User defines in an RBAC Configuration what roles and matches should be found (as above but in a new CRD schema). This means any existing role could be mutated.
2. User defines in a Configmap what roles and matches should be found (as above but in a new Config)
3. RBAC-Manager ventures into the world of creating roles and we work that into the RBAC-Manager CRD

[ejether]

@sudermanjr asked in another thread: "Does this encourage people to disregard our advice of segmenting namespaces logically?"

I don't think it "encourages" it but I do think this enables that to a certain extent. I can see this feature being useful to add segmentation in finer-grained way in addition to the logical segmentation. It also adds a type of functionality that could be very useful to dev teams in the dev workflow and/or when you want to grant read-only access to certain resources in production.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ejether]

I still believe in you!

[rramadoss4]

We are also looking for this feature..Any plans in implementing this solution in future?

[lucasreed]

I want to move forward with this feature, and currently thinking over the implementation options. I think I like the idea of annotating Roles/ClusterRoles which would signify to rbac-manager that it's ok to mutate them. Any thoughts on whether we:

a. pattern match using regex b. use label matching

The issue I see with pattern matching is the same that's brought up in the above linked kubernetes thread (https://github.com/kubernetes/kubernetes/issues/56582) where you match pods with webapp-* and then someone launches another Deployment/Statefulset to the namespace called webapp-new that maybe the initial role was not intended for.

If we match purely to a Deployment name, then we could use the matchLabels of that deployment as our mechanism for access to the underlying pods. But maybe there are some other considerations I am not thinking of with that method.

Thoughts on these?

CC: @ejether