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 RedisGraph. docker-compose stack defines all what's required to build and run Krane service locally. It'll also take care of its RedisGraph 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 <marcin.ciszak@appvia.io> - 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.

Architecture

RBAC Data indexed in a local Graph database

Krane indexes RBAC entites in RedisGraph. This allows us to query network of dependencies efficiently and simply using subset of CypherQL supported by RedisGraph.

Schema

Nodes

The following nodes are created in the Graph for the relevant RBAC objects:

• Psp - A PSP node containing attributes around the pod security policy. Only applicable when working with K8s < 1.25.
• Rule - Rule node represents access control rule around Kubernetes resources.
• Role - Role node represents a given Role or ClusterRole. kind attribute defines type of role.
• Subject - Subject represents all possible actors in the cluster (kind: User, Group and ServiceAccount)
• Namespace - Kubernetes Namespace node.

Edges

• :SECURITY - Defines a link between Rule and Psp nodes. Only applicable when working with K8s < 1.25.
• :GRANT - Defines a link between Role and Rule associated with that role.
• :ASSIGN - Defines a link between an Actor (Subject) and given Role/ClusterRole (Role node).
• :RELATION - Defines a link between two different Actor (Subject) nodes.
• :SCOPE - Defines a link between Role and Namespace nodes.
• :ACCESS - Defines a link between Subject and Namespace nodes.
• :AGGREGATE - Defines a link between ClusterRoles (one ClusterRole aggregates another) A-(aggregates)->B
• :COMPOSITE - Defines a link between ClusterRoles (one ClusterRole can be aggregated in another) A<-(is a composite of)-B

All edges are bidirectional, which means graph can be queried in either direction. Only exceptions are :AGGREGATE and :COMPOSITE relations which are uni-directional, though concerned with the same edge nodes.

Querying the Graph

In order to query the graph directly you can exec into a running redisgraph container, start redis-cli and run your arbitrary queries. Follow official instructions for examples of commands.

You can also query the Graph from Krane console. First exec into running Krane container, then

# Start Krane console - this will open interactive ruby shell with Krane code preloaded

console

# Instantiate Graph client

graph = Krane::Clients::RedisGraph.client cluster: 'default'

# Run arbitrary CypherQL query against indexed RBAC Graph

res = graph.query(%Q(
  MATCH (r:Rule {resource: "configmaps", verb: "update"})<-[:GRANT]-(ro:Role)<-[:ASSIGN]-(s:Subject)
  RETURN s.kind as subject_kind, s.name as subject_name, ro.kind as role_kind, ro.name as role_name))

# Print the resu