A simple "RBAC in Kubernetes" visualizer. No matter how complex the setup, rback queries all RBAC related information of an Kubernetes cluster in constant time and generates a graph representation of service accounts, (cluster) roles, and the respective access rules in dot format.
For example, here is an Amazon EKS cluster as seen by rback:
Another example would be a local K3S cluster:
Here in action in the Katacoda Kubernetes playground:
See for more details the examples/ directory …
rback depends on you having access to a Kubernetes cluster, either in the cloud (like Amazon EKS)
or locally (k3s, kind, Minikube, Docker for Desktop) as well as kubectl installed and configured, locally.
To install it for macOS, do:
$ curl -sL https://github.com/team-soteria/rback/releases/download/v0.4.0/macos_rback -o rback
$ chmod +x rback && sudo mv rback /usr/local/binTo install it for Linux, do:
$ curl -sL https://github.com/team-soteria/rback/releases/download/v0.4.0/linux_rback -o rback
$ chmod +x rback && sudo mv rback /usr/local/binYou can also build it from source, with Go 1.12 like so:
$ git clone https://github.com/team-soteria/rback.git && cd rback
$ go buildRun rback locally against the target cluster and store its output in a .dot file like shown in the following:
$ kubectl get sa,roles,rolebindings,clusterroles,clusterrolebindings --all-namespaces -o json | rback > result.dotNow that you have result.dot, you can render the graph either online or locally.
There are plenty of Graphviz (dot) online visualization tools available, for example, use magjac.com/graphviz-visual-editor/ for interaction or the simpler dreampuf.github.io/GraphvizOnline. Head over there and paste the output of rback into it.
Install Graphviz, for example, on macOS you can do brew install graphviz. Then you can do the following (on macOS):
$ kubectl get sa,roles,rolebindings,clusterroles,clusterrolebindings --all-namespaces -o json | rback | dot -Tpng > /tmp/rback.png && open /tmp/rback.pngThere is also a very crude first version of a kubectl plugin in https://github.com/team-soteria/rback/blob/master/kubectl-plugin/kubectl-rback. Add the file to your path, ensure it is executable and modify it to suit your environment. Then, you'll be able to simply run:
$ kubectl rbackThis will generate the .dot file, render it using GraphViz (must be installed on your system) and open the rendered image using xgd-open.
We welcome contributions to make the plugin work in other environments.
By default, rback shows all RBAC resources in your cluster, but you can also focus on a single namespace by using the -n switch. The switch supports multiple namespaces as well:
$ kubectl rback -n my-namespace
$ kubectl rback -n my-namespace1,my-namespace2If you're particularly interested in a single ServiceAccount, you can run:
$ kubectl rback serviceaccount my-service-account
or
$ kubectl rback sa my-service-accountThis makes the specified ServiceAccount the focal point of the graph, meaning that only it and directly-related RBAC resources are shown.
Instead of ServiceAccounts, you can also focus on Roles, RoleBindings, ClusterRoles or ClusterRoleBindings:
$ kubectl rback role my-role
$ kubectl rback clusterrole my-cluster-role
$ kubectl rback rolebinding my-role-binding
$ kubectl rback clusterrolebinding my-cluster-role-bindingYou can also use the abbreviated form:
$ kubectl rback r my-role
$ kubectl rback cr my-cluster-role
$ kubectl rback rb my-role-binding
$ kubectl rback crb my-cluster-role-bindingIf you'd like to inspect more than one resource, you can specify multiple resource names:
$ kubectl rback r my-role1 my-role2In addition to focusing on a specific resource, rback can also show you who can perform a particular action. For example, if you'd like to see who can create pods, run:
$ kubectl rback who-can create podsThis renders the matched (Cluster)Roles, all directly-related (Cluster)RoleBindings and subjects (ServiceAccounts, Users and Groups). The matched access rule will be shown in bold font.
Whether using who-can or not, you can turn off the rendering of the (possibly long) list of access rules with:
$ kubectl rback --show-rules=falseWhen using who-can, you can also tell rback to only show matched rules instead of hiding rules completely:
$ kubectl rback --show-matched-rules-only who-can create podsTo follow the "Do One Thing And Do It Well" Unix philosophy, rback does not call out to kubectl to read RBAC resources (although initial versions did do that) and does not actually render the image. All it does is parse a list of RBAC resources passed in through stdin, and then prints out a GraphViz .dot file to stdout using the github.com/emicklei/dot package.


