RBAC inheritance

[alechenninger]

Context

• RBAC currently (as I understand it) is managed per Workspace and NS (just as in a cluster and NS)
• This provides great isolation, but little/no reuse (I believe there may be some functionality to reuse common [Cluster]Roles? but not sure where this stands)
• A common problem in managing access is reducing the amount of places where an access rule has to be expressed. Due to lack of reuse or inheritance of ClusterRole[Binding]s across Workspaces, it may have a few undesirable systemic effects:
  1. Incentive not to subdivide a large Workspace into many sub-Workspaces, due to avoiding maintenance of per-Workspace RBAC
  2. Broad access given, or, a similar problem, lingering access given (e.g. not ever taken away), instead of giving and maintaining least privilege to avoid maintenance overhead
  3. Or for users who do attempt both least privilege and division into many Workspaces (itself probably necessary for least privilege), frustration out of the required overhead and steps, or effort towards automation and abstracts on top to do this

Suggestion

Therefore, I suggest there should be some way to reuse Cluster RBAC across Workspaces to solve for these use cases.

One approach is to take advantage of the hierarchy and "inherit" ClusterRoles and/or *Bindings. This hierarchical inheritance is one of the motivations behind GCP's resource hierarchy, for example: https://cloud.google.com/iam/docs/resource-hierarchy-access-control

Another might be to take a label-based (or in more general terms, attribute-based) approach, where somehow policies can be associated with Workspaces or NS of different attributes and matched accordingly.

I'm curious what the kcp team thinks about this idea and what approaches, with what tradeoffs, might work to solve this.

Thanks!

Note

Disclaimer: possible rabbit hole. I can't help but point out one interesting technology which is possibly relevant. It's by no means the first thing I would reach for, but the recent buzz around "relationship based access control (ReBAC)" (i.e. from the popular Zanzibar whitepaper) is partly explained by it being a general solution for this kind of common problem. It is a system for defining access based on relationships (e.g. nodes in a graph), therefore you can very easily express and check for something like "I have this permission in this nested object (e.g. workspace) because I have that permission in a parent object." I only mention because if we find it very challenging to engineer for RBAC inheritance starting from the existing authorizer implementation, maybe this is something to consider.

[ncdc]

Quick comment: it might prove difficult/impossible to aggregate RBAC data across shards, which would be required for RBAC inheritance because multiple workspaces in a sub-hierarchy can have their content hosted on different shards.

[alechenninger]

/cc @sttts

The difficulty here sounds like it stems from read-time lookups through parents in the hierarchy, which may span shards.

But what if this was optimized to be write expensive instead of read expensive? That is, make the read-time lookups use the same Workspace, and instead denormalize the RBAC data across workspaces. I know of two precedents for this approach:

• hierarchical namespaces, use a controller to sync [Cluster]Role[Binding]s to child workspaces.
• Red Hat COP's own namespace config operator which is a similar idea except uses label selectors instead of a built in hierarchy

WDYT?

[andybraren]

Sharing one data point from a high-level conversation with an interested party (link here for those with access).

They "loved" the notion of a hierarchical model for Kube-base RBAC, and seemed to assume that KCP would enable it. Unfortunately I don't have more details, but something similar to hierarchical namespaces may have been what they were imagining.

[andybraren]

@sttts would the RBAC Policy Workspace solution you mentioned recently (comment thread) enable users to define policies in 1 spot and have them apply to every sub-workspace of e.g. Aspian's Finance Department? Maybe a new team member joins and an org admin/owner wants to give them view-only access to everything in the Org Workspace at root:aspian:finance - is that how that could be configured?

Minimizing the number of places where access rules have to be managed and expressed seems like a good way to reduce the risk of users making costly mistakes in general, so that high-level problem seems worth solving for.