# rbac-lookup answers who is bound to what in Kubernetes RBAC

> RBAC Lookup is a small Go CLI from Fairwinds that takes a user, service account or group name and tells you which Kubernetes roles and cluster roles are bound to it. It does one lookup well, ships as a prebuilt binary through Homebrew and ASDF, and sits next to an operator called RBAC Manager that changes how that binding is written in the first place.

**FairwindsOps/rbac-lookup** — Easily find roles and cluster roles attached to any user, service account, or group name in your Kubernetes cluster

- Repository: https://github.com/FairwindsOps/rbac-lookup
- Website: https://fairwinds.com
- Stars: 983 · Forks: 48
- Language: Go
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/fairwindsops-rbac-lookup

## One question, answered across every binding

Kubernetes RBAC is easy to get wrong because permissions are scattered. A subject can be named in a RoleBinding, a ClusterRoleBinding, a group that appears in several of them, and a service account that inherits more through its group membership, and no single kubectl get shows the total picture. RBAC Lookup exists to close that gap. It is a CLI that finds the roles and cluster roles bound to any user, service account or group name, so the question you ask is the one an auditor or an on-call engineer actually has, which is what can this identity do, rather than the question the API structure makes easy, which is what is this particular binding. The tool is deliberately narrow, and the project pairs it with a second one: while RBAC Lookup provides visibility into Kubernetes auth, RBAC Manager is a Kubernetes operator that makes auth simpler to manage by enabling more concise RBAC configuration that is easier to scale and automate. Read them together and the design story is a complete one. One tool shows you the mess, the other offers a way out of it.

## Installation is Homebrew or ASDF, nothing to compile

Binaries are generated with goreleaser for each release, and the installation section therefore only covers package managers rather than a build from source. Homebrew is the shortest path, one command and you have the tool:

```bash
brew install FairwindsOps/tap/rbac-lookup
```

ASDF is the alternative, and it pins a version for you, which matters if you run the tool across several machines:

```bash
asdf plugin add rbac-lookup
asdf install rbac-lookup latest
asdf global rbac-lookup latest
```

The asdf global line sets the version for every shell on that machine, so the same binary is used everywhere, and the install line can be pointed at a specific version instead of latest if you want reproducibility. There is also a release badge pointing at the GitHub releases page, so a manual download of a goreleaser artifact is the third option for environments where neither package manager is available. The documentation lives separately at rbac-lookup.docs.fairwinds.com, and the README is explicit that it is the place to start, which tells you the intended audience is an administrator who will read the docs rather than a developer who will read the source.

## The dependency list shows how it reaches the cluster

The Go module file is short and every dependency is telling. The CLI framework is cobra, which gives the command structure and the flag handling. The Kubernetes client libraries are k8s.io/api, k8s.io/apimachinery and k8s.io/client-go, all at version 0.28.1, which is what allows the tool to read RoleBinding and ClusterRoleBinding objects and resolve the subjects inside them. The interesting entry is the trio of golang.org/x/oauth2, google.golang.org/api and cloud.google.com/go/compute/metadata, because those are the pieces used to authenticate against Google Cloud. A cluster administrator running GKE has several ways to prove who they are, and the OAuth2 and Google API dependencies point at the GKE path in particular, with the compute metadata client serving the node's own credentials. In other words, the tool is built to be run by someone whose identity comes from the cloud provider rather than from a kubeconfig with a static token, which is the normal situation inside GKE. The module targets Go 1.20, and the repository also carries a plugin.yaml and a CODEOWNERS file at the top level.

## The Makefile treats coverage and vet as part of the build

The build file is more disciplined than a typical three-line Go Makefile, and the details tell you how the project is maintained. Version and commit are stamped into the binary at link time, and the build target strips symbols, which keeps the released artifact small:

```bash
build:
	$(GOBUILD) -o $(BINARY_NAME) -ldflags "-X main.version=$(VERSION) -X main.commit=$(COMMIT) -s -w" -v
```

The default target runs the tests before the build, so a broken test blocks a binary. The test target runs with the benchmark and memory flags and writes a coverage profile, then runs go vet into a separate report file, and finally renders an HTML coverage report, so coverage is a produced artefact rather than a number somebody remembers to read. Cross compilation is handled with a dedicated target that disables cgo and pins the target operating system and architecture:

```bash
build-linux:
	CGO_ENABLED=0 GOOS=linux GOARCH=amd64 $(GOBUILD) -o $(BINARY_NAME) -ldflags "-X main.VERSION=$(VERSION)" -v
```

That target is the one that matters for a CLI that people download and run, since a static binary with no cgo dependency runs on any Linux host without a matching glibc. The tidy target runs go mod tidy and clean removes the binary and formats the tree, which is a small sign of the everyday friction being kept under control.

## A repository shaped around a command and its tests

The top level layout shows what kind of project this is. main.go sits at the root, cmd/ holds the cobra command tree, and lookup/ is the package that does the actual work of resolving roles for a subject. There is a dedicated e2e/ directory, which is the part worth noticing: an RBAC tool can be unit tested with fake clients and still be wrong about how bindings look in a real cluster, so end to end tests against a cluster are the ones that catch mistakes in subject resolution. The docs/ directory matches the separate documentation site, and the Makefile and .goreleaser.yml sit alongside them. Configuration for CI is in .circleci/, which tells you the project still builds on CircleCI rather than only on GitHub Actions, and .github/ is also present for the repository's own workflows and templates. The .goreleaser.yml is what makes the per release binaries for multiple platforms, and the presence of ROADMAP.md is a reasonable sign that the maintainers expect the tool to keep evolving, which is the question an adopter should ask next.

## The Fairwinds ecosystem around it

The project sits inside a set of Kubernetes tools from the same maintainers, and reading that list tells you what problem space RBAC Lookup occupies. Polaris audits, enforces and builds policies for Kubernetes resources, with over twenty built-in checks for best practices, so it is the tool that acts on a policy where this one reports on access. Goldilocks right-sizes your Kubernetes Deployments by comparing memory and CPU settings against actual usage, which is resource management rather than access control. Pluto detects Kubernetes resources that have been deprecated or removed in future versions, so it is about API lifecycle. Nova checks whether your Helm charts have updates available. RBAC Manager simplifies the management of RBAC in your clusters, and as noted earlier it is the operator half of the pair, since it lets you define access more concisely and then scale and automate that definition. Taken together, the set is a portfolio rather than a single tool, and the practical implication is that an RBAC cleanup in a large cluster usually ends with RBAC Manager doing the writing and RBAC Lookup being the tool that tells you what the result looks like.

## The release gap is the thing to watch

The release history is unusual and worth reading carefully. The three listed releases are v0.10.3 from 2025-08-01, v0.10.2 from 2023-09-05 and v0.10.1 from 2023-03-31, so the gap between the oldest two releases is about five months while the gap between the newest two is nearly two years. The repository itself was pushed to more recently, with the last push on 2026-09-21, and it is not archived, which means work is still landing even though tagged releases are infrequent. The version number is still below one, so there is no stability promise encoded in the version. For a tool whose job is to be trusted with a security question, that release rhythm is the first thing to weigh, because an RBAC view that is a year out of date is a view of the permissions that existed a year ago. The project is Apache-2.0 licensed, the community runs on a Fairwinds Slack, and the documentation site is the right place to check whether the tool has caught up with the Kubernetes version in front of you.

## Conclusion

rbac-lookup fits an administrator answering a specific question during an incident or an access review, namely what permissions does this service account actually have once every binding in the cluster is taken together, and it fits anyone who prefers a small binary to a policy engine. It does not fit a team that wants to prevent over-permission rather than discover it, and it does not fit a cluster where the answer is spread across RoleBinding and ClusterRoleBinding objects that the tool cannot see, so its output still needs checking against the live cluster. Before you rely on it, install a pinned version with brew install FairwindsOps/tap/rbac-lookup or the ASDF plugin, note that the newest release is v0.10.3 from 2025-08-01 while the last push was on 2026-09-21, and read the documentation at rbac-lookup.docs.fairwinds.com, since the README itself is short and points there for the detail.

## FAQ

### What does rbac-lookup do?

It is a CLI that finds the Kubernetes roles and cluster roles bound to any user, service account or group name, so you can see the permissions an identity actually holds across all the bindings in a cluster.

### How do I install rbac-lookup?

With Homebrew, using brew install FairwindsOps/tap/rbac-lookup, or with ASDF through the plugin add, install and global commands. Binaries are generated with goreleaser for each release, and the documentation is at rbac-lookup.docs.fairwinds.com.

### How is rbac-lookup different from RBAC Manager?

They are separate tools from the same maintainers. RBAC Lookup provides visibility into Kubernetes auth by listing what is bound to a subject, while RBAC Manager is a Kubernetes operator that makes RBAC configuration more concise and easier to scale and automate.

### How does rbac-lookup authenticate to a cluster?

The Go module depends on k8s.io/client-go for the Kubernetes API along with golang.org/x/oauth2, google.golang.org/api and cloud.google.com/go/compute/metadata, which is the path for running against GKE with cloud provider credentials.

### Is rbac-lookup still updated?

The repository is not archived and the last push was on 2026-09-21, but releases are infrequent, with the newest being v0.10.3 dated 2025-08-01 and the version still below one.

## Sources

- [FairwindsOps/rbac-lookup on GitHub](https://github.com/FairwindsOps/rbac-lookup)
- [License: Apache-2.0](https://github.com/FairwindsOps/rbac-lookup/blob/master/LICENSE)
- [Project website](https://fairwinds.com)
- [README](https://github.com/FairwindsOps/rbac-lookup/blob/master/README.md)
- [Releases](https://github.com/FairwindsOps/rbac-lookup/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fairwindsops-rbac-lookup