This is a simple project that allows you to easily find Kubernetes roles and cluster roles bound to any user, service account, or group name. Binaries are generated with goreleaser for each release for simple installation.
brew install reactiveops/tap/rbac-lookup
kubectl krew install rbac-lookup
In the simplest use case, rbac-lookup will return any matching user, service account, or group along with the roles it has been given.
rbac-lookup rob
SUBJECT SCOPE ROLE
[email protected] cluster-wide ClusterRole/view
[email protected] nginx-ingress ClusterRole/edit
The wide output option includes the kind of subject (user, service account, or group), along with the source role binding.
rbac-lookup rob -owide
SUBJECT SCOPE ROLE SOURCE
User/[email protected] cluster-wide ClusterRole/view ClusterRoleBinding/rob-cluster-view
User/[email protected] nginx-ingress ClusterRole/edit RoleBinding/rob-edit
With a more generic query, we can see that a variety of users and service accounts can be returned, as long as they match the query.
rbac-lookup ro -owide
SUBJECT SCOPE ROLE SOURCE
User/[email protected] cluster-wide ClusterRole/view ClusterRoleBinding/rob-cluster-view
User/[email protected] nginx-ingress ClusterRole/edit RoleBinding/rob-edit
User/[email protected] web ClusterRole/edit RoleBinding/ron-edit
ServiceAccount/rops infra ClusterRole/admin RoleBinding/rops-admin
Of course a query is an optional parameter for rbac-lookup. You could simply run rbac-lookup to get a full picture of authorization in your cluster, and then pipe that output to something like grep for your own more advanced filtering.
rbac-lookup | grep rob
User/[email protected] cluster-wide ClusterRole/view ClusterRoleBinding/rob-cluster-view
User/[email protected] nginx-ingress ClusterRole/edit RoleBinding/rob-edit
If you're connected to a GKE cluster, RBAC is only half the story here. Google Cloud IAM roles can grant cluster access. Cluster access is effectively determined by a union of IAM and RBAC roles. To see the relevant IAM roles along with RBAC roles, use the --gke flag.
rbac-lookup rob --gke
SUBJECT SCOPE ROLE
[email protected] cluster-wide ClusterRole/view
[email protected] nginx-ingress ClusterRole/edit
[email protected] project-wide IAM/gke-developer
[email protected] project-wide IAM/viewer
Of course this GKE integration also supports wide output, in this case referencing the specific IAM roles that are assigned to a user.
rbac-lookup rob --gke -owide
SUBJECT SCOPE ROLE SOURCE
User/[email protected] cluster-wide ClusterRole/view ClusterRoleBinding/rob-cluster-view
User/[email protected] nginx-ingress ClusterRole/edit RoleBinding/rob-edit
User/[email protected] project-wide IAM/gke-developer IAMRole/container.developer
User/[email protected] project-wide IAM/gcp-viewer IAMRole/viewer
At this point this integration only supports standard IAM roles, and is not advanced enough to include any custom roles. For a full list of supported roles and how they are mapped, view lookup/gke_roles.go.
If a KUBECONFIG environment variable is specified, rbac-lookup will attempt to use the config at that path, otherwise it will default to ~/.kube/config.
While RBAC Lookup helps provide visibility into Kubernetes auth, RBAC Manager helps make auth simpler to manage. This is a Kubernetes operator that enables more concise RBAC configuration that is easier to scale and automate. For more information, see RBAC Manager on GitHub.
Apache License 2.0
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent