When I was first getting started with Kubernetes, RBAC was one of the topics that took me the longest to grok. Not because the resources (Roles, ClusterRoles, etc) are hard to interpret, but learning how to scope your Roles to minimize access takes some practice. That and a lot of reading to understand the various API groups and what they contain.
In a previous post I mentioned access-matrix, which is an incredible tool for visualizing the RBAC permissions an entity (User, SA, Group, etc.) has. One other super useful tool for debugging RBAC is the kubectl auth “can-i” subcommand. When run with your typical kubectl command line, it will tell you if you are authorized to perform the operation.
The following example shows how to check if the webapp ServiceAccount can list pods in the default namespace:
$ kubectl auth can-i get po --as system:serviceaccount:default:webapp
no
This becomes your best friend when you are fine tuning your Roles to avoid getting 401s back from the API server. No one (other than security conscious admins) likes messages similar to the following:
$ kubectl delete po mypod --as=system:serviceaccount:default:webapp
Error from server (Forbidden): pods "mypod" is forbidden: User "system:serviceaccount:default:webapp" cannot delete resource "pods" in API group "" in the namespace "default"
It is definitely worth putting the time into studying RBAC inside and out, and the two tools mentioned above can make this process much more enjoyable.