Krane turns Kubernetes RBAC definitions into a risk report and a graph dashboard

RBAC sprawl is a graph problem, and kubectl get role is not an answer

Every namespace in a Kubernetes cluster tends to accumulate roles, cluster roles, role bindings and cluster role bindings, and the interesting question is rarely what a single object grants. It is which combination of rules ends up giving a workload more than anyone intended. Krane is built for that question. As the README describes it, it is a simple Kubernetes RBAC static analysis tool that identifies potential security risks in an RBAC design and makes suggestions on how to mitigate them.

The audience is platform and security engineers who have inherited a cluster and cannot read the access model by eye, plus pipeline owners who want a check on manifests before they are applied. The tool has two halves that map onto those two jobs. One half is analysis, a set of built-in RBAC risk rules that Krane evaluates and that can be modified or extended with custom rules, producing an easy to understand risk report in a machine readable format. The other half is comprehension, a dashboard that presents the current RBAC security posture and lets you explore its definition, with a faceted tree and a graph network view for inspecting individual controls.

The word static matters. Nothing is mutated and no policy is enforced. What you get back is a list of findings and a navigable picture of the access graph, which is a different deliverable from a tool that refuses an apply.

Three run modes: a CLI, a CI step, and a service inside the cluster

The README lists portability as a feature and names three ways to use Krane. It can run locally as a CLI or as a Docker container, from an image published on Quay.io. It can run in a CI/CD pipeline as a step that detects potential RBAC flaws before they are applied to the cluster. And it can run as a standalone service that continuously analyses the state of RBAC inside a Kubernetes cluster.

That third mode is what the dashboard and the alerting are built around. The service indexes the entirety of Kubernetes RBAC in a local graph database, and it alerts on detected medium and high severity risks through a Slack integration. The graph is the mechanism behind the network view: once roles, cluster roles and bindings are nodes and edges, arbitrary CypherQL queries become a way to interrogate the access model by hand rather than through the fixed set of risk rules.

The implementation language is Ruby, and the repository layout is consistent with a Ruby gem plus a JavaScript dashboard: a Gemfile, a krane.gemspec, a lib directory, and a dashboard directory with its own package.json and lockfile. The Dockerfile builds the UI in a separate stage with Vite before the Ruby stages, so the two halves ship as one image.

Installing the Helm chart into a namespace of its own

The quickest route into a cluster is the Helm chart. The assumption is that you already have the Helm CLI installed, and the README gives the three commands that add the repository, refresh it, and install the release into a namespace named krane, creating that namespace as part of the install:

$ helm repo add appvia https://appvia.github.io/krane
$ helm repo update
$ helm install krane appvia/krane --namespace krane --create-namespace

After the install, the Helm output explains how to port-forward the Krane dashboard so you can reach the UI from your machine. There is no separate step in the README for applying the service account permissions by hand, but the documentation does point to a prerequisites file, k8s/one-time/prerequisites.yaml, for the details of what a service account needs in order to read RBAC resources. That file is the first thing to inspect if a report or the dashboard comes back empty in a cluster.

The chart is the sensible choice for the continuous mode, since the service needs a long lived pod, a graph database and a Slack connection. The repository also carries a k8s directory and a docker-compose.k8s.yml, alongside skaffold.yaml for local development against a cluster, and a charts directory that holds the chart sources.

The Docker Compose stack and the FalkorDB dependency it pulls in

For a local look, the README points to Docker with docker-compose installed. Krane depends on FalkorDB, and the compose stack defines everything needed to build and run the service, including that dependency. Starting it is a single command:

docker-compose up -d

The Krane image is built automatically if it is not already on the machine. The compose file shows what the stack actually is. Two services, falkordb and krane, with the graph database on its usual port and the Krane service published on port 8000:

services:

  falkordb:
    image: falkordb/falkordb:v4.20.3
    container_name: falkordb
    ports:
      - 6379:6379

Two details in that file explain a lot about the project's direction. The FalkorDB container is configured with result set limits lifted, because the defaults would silently truncate reports on a large cluster, and the bundled web browser UI is switched off since Krane talks to the graph directly. The same comment block records that the goal was to reproduce the behaviour RedisGraph used to provide, which is a fair description of the migration in progress.

Resource limits are set in the compose file too, one CPU and 200M for the database and 400M for Krane, with smaller reservations. On a cluster with many roles those numbers are the first constraint you are likely to hit, and they are not tuned for scale.

Three ways to point Krane at RBAC: context, directory, or the cluster itself

The report command is where the analysis happens, and it takes three different kinds of input. Against a running cluster you supply a kubectl context:

krane report -k <context>

If you plan to run the tool against several clusters and index each RBAC graph separately, you can also pass a cluster name with the `-c` flag. Against files on disk you give a directory path instead:

krane report -d </path/to/rbac-directory>

And from a container running inside a Kubernetes cluster, the in-cluster mode uses a single flag:

krane report --incluster

In cluster mode the service account used by Krane needs access to RBAC resources, which is what the prerequisites file covers. The command set is otherwise small: the help output lists just two subcommands, `dashboard` and `report`, alongside `help`, with global options for help, version and a backtrace on error. The dashboard server is started with `krane dashboard`, and it also accepts the cluster name flag so you can point it at a specific indexed cluster.

The local compose run has one sharp edge worth knowing before you start. Krane does not start the report and dashboard automatically in that mode. The container sleeps for 24 hours by default, and that value is adjusted in docker-compose.override.yml. The stack also mounts your kube config inside the container, so you can run reports against any cluster you already have access to.

Directory mode expects five exact file names, including a psp that no longer exists

The most brittle part of Krane is the directory mode, and it is a naming contract rather than a schema. Krane expects the following files, in either YAML or JSON format, to be present in the directory you point at: psp, roles, clusterroles, rolebindings and clusterrolebindings. No directory scanning, no globbing, no inference from content.

The psp entry is the awkward one, because PodSecurityPolicy was deprecated in Kubernetes v1.21 and removed from Kubernetes in v1.25. If your cluster is on a modern version, you have no Pod Security Policies at all, and the README tells you to create a psp file manually with the following content:

{
  "items": []
}

That is a harmless placeholder for a resource type that no longer exists, but it is a sign of the tool's age. The same age shows in CI mode, where the README says CI executor should reference the quay.io/appvia/krane:latest image, and in the documentation itself, which is truncated in places, for instance the dashboard section ends mid sentence.

For CI use, the mode is straightforward. The command takes the directory and the `--ci` flag:

krane report --ci -d </path/to/rbac-directory>

CI mode is enabled by the `--ci` flag, and Krane returns a non zero status code with details of breaking risk rules when one or more dangers have been detected. That exit code is the useful part for a pipeline, since it lets a merge be blocked on a rule violation. The catch is that the pipeline step is only as good as the naming convention above.

The graph layer is the differentiator against a hand rolled kubectl audit

It is worth being precise about what Krane does that a manual review does not. A manual audit means listing roles, reading each rule, listing bindings, and mentally joining the two sets for a specific question such as which service accounts can read secrets. The graph approach stores the entire RBAC definition as nodes and relationships and then answers that question as a query.

This is also where Krane differs in kind from admission time enforcement. An admission style check reacts when a manifest is applied and can block it. Krane works on the definition, reports the findings in a machine readable format, and in CI mode turns breaking rules into a failed status code, so the block happens before apply rather than during it. The trade-off is coverage of live state. The in-cluster service exists to close that gap by analysing the state of RBAC within a running cluster and alerting on medium and high severity risks through Slack, so you are told when the posture changes rather than only when the next manifest lands.

The custom rules capability is the other half of the value. The built-in risk rules can be modified or extended with a set of custom rules, which is where an organisation encodes its own idea of acceptable privilege instead of accepting a generic list.

Beta status, recent releases, and the Apache-2.0 licence

The README badge says Stability: Beta, and the release history supports treating it that way. The tags are v0.1.6 published on 2026-08-20, v0.1.5 published the same day, and a krane-0.1.6 tag alongside them, which suggests the packaging step and the gem release are versioned separately. The repository is not archived and the last push was on 2026-10-18, so the code is being worked on even though the version number has stayed in the zero one range.

The licence is Apache-2.0, with the text in the LICENSE file, and the same Apache header appears on the source files, including the Dockerfile and the compose file, both of which carry the standard copyright line for Appvia Ltd. The project is published as a container image on Quay.io and as a Ruby gem, since the repository contains a krane.gemspec and a bin directory.

The dependency surface is modest. The Docker image is assembled in three stages: a Node 22 Alpine stage that installs the dashboard dependencies with npm ci and runs the Vite build, a Ruby 3.2.2 Alpine stage that installs the gems with a bundler version pinned from the lockfile, and a final stage carrying the built app. The gems are installed with a Bundler deployment configuration that excludes development and test groups, so a running instance does not carry the test suite.

Editorial conclusion

Krane suits teams that want an RBAC risk report in CI before manifests reach a cluster, and platform engineers who want a browsable picture of who can do what in a live cluster. It is a poor fit if you need admission-time enforcement, since it reports rather than rejects, and it is a poor fit for directory mode unless you can name your files psp, roles, clusterroles, rolebindings and clusterrolebindings. Before adopting it, run krane report against a real context and read the results against your own definition of acceptable privilege, and check the resource limits in docker-compose.yml, which cap the FalkorDB instance at one CPU and 200M of memory.

Frequently asked questions

Official sources

1. appvia/krane on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases