team-soteria / rback Goto Github PK

Hi,
i've installed rback as kubectl plugin so i've launch :

root@061-ildm ~]# kubectl rback -n gateway
panic: interface conversion: interface {} is nil, not []interface {}

goroutine 1 [running]:
main.toRole(0xc000326f90, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /Users/hausenbl/go/src/github.com/mhausenblas/rback/parse.go:95 +0x51a
main.(*Rback).parseRBAC(0xc00028fec8, 0x53c180, 0xc00000e010, 0xc000046250, 0x1)
        /Users/hausenbl/go/src/github.com/mhausenblas/rback/parse.go:56 +0x46d
main.main()
        /Users/hausenbl/go/src/github.com/mhausenblas/rback/main.go:45 +0xf6

why i've that error?

Hi!

The current go.mod file is not working as intended anymore;

The module declares the path: github.com/mhausenblas/rback
But it should follow the Github path: github.com/team-soteria/rback

Is this intentional?

Users should be able to install kubectl-rback through https://github.com/kubernetes-sigs/krew

The kubect-rback plugin needs a few improvements:

• make it run on OSX
• make it configurable through environment variables (generation of image and what binary to use to open it should both be configurable)

In openshift, rolebindings can have an entry userNames: null

The parsing panics because this is not a string

Using the example RBAC resources from examples/create-example-rbac-rules.sh, as you would expect, if you run

kubectl rback -n namespace1 sa

rback shows three additional (Cluster)RoleBindings that aren't in namespace1, but reference ServiceAccounts in that namespace.

But if you run

kubectl rback -n namespace1

those three additional (Cluster)RoleBindings aren't shown. IMHO, they should be, since they are all directly related to some resources in namespace1. When you don't specify a resource kind, but do specify a namespace, rback should show all RBAC resources from namespace1 plus all directly related resources (from any other namespace or cluster-scope).

It should show:

• all (Cluster)RoleBindings that reference any ServiceAccount from the namespace
• all subjects that are referenced by RoleBindings in the namespace (*rback already does this)
• all ClusterRoles that are referenced by RoleBindings in the namespace (*rback already does this)

Hi,

Nice project!

I was trying to use it into my environment and I'm facing the following error:

/usr/local/bin/kubectl get sa --all-namespaces --output json
/usr/local/bin/kubectl get roles --all-namespaces --output json
/usr/local/bin/kubectl get rolebindings --all-namespaces --output json
/usr/local/bin/kubectl get clusterroles --output json
/usr/local/bin/kubectl get clusterrolebindings --output json
panic: interface conversion: interface {} is nil, not []interface {}

goroutine 1 [running]:
main.lookupRoles(0xc0000a1650, 0x7, 0xc0000a1640, 0x7, 0xc000060150, 0xc000192270, 0xc0000ea400, 0x1c, 0x20, 0xc00023eb40, ...)
	/Users/hausenbl/go/src/github.com/mhausenblas/rback/main.go:199 +0x586
main.genGraph(0xc000060150, 0xc000192270, 0xc0000ea400, 0x1c, 0x20, 0xc00023eb40, 0xc0000eae00, 0x1c, 0x20, 0x0)
	/Users/hausenbl/go/src/github.com/mhausenblas/rback/main.go:310 +0xc01
main.main()
	/Users/hausenbl/go/src/github.com/mhausenblas/rback/main.go:27 +0x141

My env:

OS CentOS 7.6 64 bit
K8S version: 1.13.4

Tks

To follow Unix philosophy, we could remove the code that fetches RBAC resources through kubectl, and instead just read them from STDIN.

It's possible to get all required resources with a single command, so we should be able to run:

kubectl get sa,roles,rolebindings,clusterroles,clusterrolebindings --all-namespaces -o json | rback

Since the plan is to create a kubectl-rback plugin, which will run the above command, most users will never have to type the full command and instead just run kubectl rback.

The added benefit would be that you could also get the RBAC resource list JSON from anywhere (e.g. email?) and still be able to convert it to a graph file. Perhaps we could create an online service where you paste in your RBAC JSON and it renders the graph (ok, maybe not a great idea as far as security goes, but it does demonstrate the benefit nicely).