Skip to content

team-soteria/rback

Repository files navigation

rback

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:

EKS cluster

Another example would be a local K3S cluster:

K3S cluster

Here in action in the Katacoda Kubernetes playground:

Katacoda

See for more details the examples/ directory …

Install

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

Using rback directly

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.

Render online

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.

Render locally

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

Using rback as a kubectl plugin

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.

More usage examples

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

How it works

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.