ReynardSec@reynardsec@infosec.exchange
A grumpy ItSec guy walks through the office #2
devops0: dude, we've got so many roles in this cluster my terminal buffer runs out when I try to list them all.
devops1: bro, if it works, don't touch.
devops0: sure, but neither I nor anyone else on the project knows who can access what...
ItSec (walking by): just use rbac-tool and review this...
devops1: r... rba... what?
devops0: rbac-tool probably or smth
--
It's always a good moment to verify who can do what in your Kubernetes cluster.
For basic checks, use native kubectl:
1) Can "I" read secrets?
kubectl auth can-i get secrets
2) To check another identity's permissions (e.g., a ServiceAccount) run:
kubectl auth can-i get secrets --as=system:serviceaccount:somenamespace:someserviceaccount
However, this approach will not work for complex environments. There's a more effective way to do this with rbac-tool [2]. It gives you cluster-wide visibility with simple commands. Check this:
1) Who can do a specific thing? For example: who in the entire cluster can read Secrets?
rbac-tool who-can get secrets
2) Run an RBAC health check - global analysis with risk hints (wildcards in RBAC, overly broad permissions, cross-namespace binds, etc)
rbac-tool analysis
3) Visualize the mess - produce an interactive map of roles, bindings, etc:
rbac-tool visualize
This command writes a report to rbac.html in the current directory.
Alternatives to rbac-tool like rakkess [3] can offer similar "who can" insights, though it may not be actively maintained.
Stay (more) safe!
[1] https://kubernetes.io/docs/reference/kubectl/generated/kubectl_auth/kubectl_auth_can-i/
[2] https://github.com/alcideio/rbac-tool
[3] https://github.com/corneliusweig/rakkess
#devops #programming #webdev #cybersecurity #infosec #sysadmin #kubernetes #containers
