Krane

Kubernetes RBAC Analysis made Easy

Krane is a simple Kubernetes RBAC static analysis tool. It identifies potential security risks in K8s RBAC design and makes suggestions on how to mitigate them. Krane dashboard presents current RBAC security posture and lets you navigate through its definition.

Features

• RBAC Risk rules - Krane evaluates a set of built-in RBAC risk rules. These can be modified or extended with a set of custom rules.
• Portability - Krane can run in one of the following modes:
  • Locally as a CLI or docker container.
  • In CI/CD pipelines as a step action detecting potential RBAC flaws before it gets applied to the cluster.
  • As a standalone service continuously analysing state of RBAC within a Kubernetes cluster.
• Reporting - Krane produces an easy to understand RBAC risk report in machine-readable format.
• Dashboard - Krane comes with a simple Dashboard UI helping you understand in-cluster RBAC design. Dashboard presents high-level overview of RBAC security posture and highlights detected risks. It also allows for further RBAC controls inspection via faceted tree and graph network views.
• Alerting - It will alert on detected medium and high severity risks via its Slack integration.
• RBAC in the Graph - Krane indexes entirety of Kubernetes RBAC in a local Graph database which makes any further ad-hoc interrogating of RBAC data easy, with arbitrary CypherQL queries.

Contents

• Quick Start
• Usage Guide
• Architecture
• Kubernetes Deployment
• Notifications
• Local Development
• Contributing to Krane
• Community
• Roadmap
• License

Quick Start

You can get started with Krane by installing it via Helm chart in your target Kubernetes cluster or running it locally with Docker.

Install Helm chart

It is assumed that you have Helm CLI installed on your machine.

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

Follow Helm chart installation output on how to port-forward Krane dashboard.

Run with Docker

It is assumed that you have docker running on your local machine. Install docker-compose if you haven't already.

Krane depends on FalkorDB. docker-compose stack defines all what's required to build and run Krane service locally. It'll also take care of its FalkorDB dependency.

docker-compose up -d

Krane docker image will be pre-built automatically if not already present on local machine.

Note that when running docker-compose locally, Krane won't start RBAC report and dashboard automatically. Instead, the container will sleep for 24h by default - this value can be adjusted in docker-compose.override.yml. Exec into a running Krane container to run commands. Local docker-compose will also mount kube config (~/.kube/config) inside the container enabling you to run reports against any Kubernetes clusters to which you already have access to.

Exec into a running Krane container.

docker-compose exec krane bash

Once in the container you can start using krane commands. Try krane -help.

krane -h

To inspect what services are running and the associated ports:

docker-compose ps

To stop Krane and its dependency services:

docker-compose down

Usage Guide

Commands

$ krane --help

  NAME:

    krane

  DESCRIPTION:

    Kubernetes RBAC static analysis & visualisation tool

  COMMANDS:

    dashboard Start K8s RBAC dashboard server
    help      Display global or [command] help documentation
    report    Run K8s RBAC report

  GLOBAL OPTIONS:

    -h, --help
        Display help documentation

    -v, --version
        Display version information

    -t, --trace
        Display backtrace when an error occurs

  AUTHOR:

    Marcin Ciszak <[email protected]> - Appvia Ltd <appvia.io>

Generate RBAC report

With local kubectl context

To run a report against a running cluster you must provide a kubectl context

krane report -k <context>

You may also pass -c <cluster-name> flag if you plan to run the tool against multiple clusters and index RBAC graph separately for each cluster name.

From RBAC files stored in directory

To run a report against local RBAC yaml/json files, provide a directory path

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

NOTE: Krane expects the following files (in either YAML or JSON format) to be present in specified directory path:

• psp
• roles
• clusterroles
• rolebindings
• clusterrolebindings

If Pod Security Policies are not in use you may bypass the expectation above by creating a psp file manually with the following content:

{
  "items": []
}

Note, PodSecurityPolicy was deprecated in Kubernetes v1.21, and removed from Kubernetes in v1.25.

Inside a Kubernetes cluster

To run a report from a container running in Kubernetes cluster

krane report --incluster

NOTE: Service account used by Krane will require access to RBAC resources. See Prerequisites for details.

In CI/CD pipeline

To validate RBAC definition as a step in CI/CD pipeline

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

NOTE: Krane expects certain naming convention to be followed for locally stored RBAC resource files. See section above. In order to run krane commands it's recommended that CI executor references quay.io/appvia/krane:latest docker image.

CI mode is enabled by --ci flag. Krane will return non zero status code along with details of breaking risk rules when one or more dangers have been detected.

Visualisation Dashboard

To view RBAC facets tree, network graph and latest report findings you need to start dashboard server first.

krane dashboard

Cluster flag -c <cluster-name> may be passed if you want to run the dashboard against specific cluster name. Dashboard will look for data related to specified cluster name which is cached on the file system.

Command above will start local web server on default port 8000, and display the dashboard link.

The server binds to 0.0.0.0 so that it is reachable when running in a cluster. Pass -b 127.0.0.1 to keep it on the loopback interface when running locally.

The dashboard has no authentication. It serves everything Krane knows about your cluster's RBAC to anyone who can reach the port, so do not expose it directly. Reach it with kubectl port-forward, restrict access with a NetworkPolicy (the chart already labels the pod with network/krane: "true"), or put an authenticating proxy in front of it.

The dashboard is a set of static files served from dashboard/compiled, and the report writes its data into the same directory. A report generated while the dashboard is running is picked up without a restart.

Views