The reduction in configuration only gets more significant as more users, namespaces, or clusters are added to the picture. Of course there’s a lot more to RBAC than this example shows. RBAC Manager supports binding users, groups, or service accounts to any combination of roles or cluster roles, at either a namespace or cluster level.
This ability to assign multiple role bindings with a single custom resource has been quite powerful in our experience. No longer do you have to look for role bindings across multiple namespaces to understand the current state of your RBAC configuration, instead it’s neatly summarized in a single RBAC Definition.
A Path to Automation
RBAC Manager was built with the idea that we wanted to automate RBAC management in Kubernetes. Making these kind of changes manually was error prone and simply did not scale well. Unfortunately the existing Kubernetes resources here did not lend themselves to automated updates in the same way that something like a Deployment would.
With that in mind, a RBAC Definition functions much more like a Deployment than a Role Binding. Just like a Deployment simplifies updating pods, a RBAC Definition is intended to simplify updating Role Bindings and Cluster Role Bindings. Changes to a RBAC Definition trigger changes in resources it owns, in this case Role Bindings and Cluster Role bindings. If a role binding is no longer referenced in a RBAC Definition, RBAC Manager deletes it. Similarly, if a requested role in a RBAC Definition changes, RBAC Manager will delete and recreate the appropriate Role Bindings. And finally, if an RBAC Definition is deleted, all the associated Role Bindings and Cluster Role Bindings will also automatically be deleted.
This new approach opens the doors to automation, and allows you to manage RBAC Configuration with a CI workflow. Similar to how Deployments simplify updating Pods in a CI workflow, a RBAC Definition can simplify updating Role Bindings and Cluster Role Bindings.