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/bin
To 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/bin
You can also build it from source, with Go 1.12 like so:
$ git clone https://github.com/team-soteria/rback.git && cd rback
$ go build
Run 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.dot
Now 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.png
There 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 rback
This 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-namespace2
If you're particularly interested in a single ServiceAccount
, you can run:
$ kubectl rback serviceaccount my-service-account
or
$ kubectl rback sa my-service-account
This 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-binding
You 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-binding
If you'd like to inspect more than one resource, you can specify multiple resource names:
$ kubectl rback r my-role1 my-role2
In 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 pods
This 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=false
When 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 pods
To 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.