Folgen Sie der Ausgabe der Helm-Chart-Installation, um das Krane-Dashboard per Port-Forwarding zu erreichen.

### Ausführung mit Docker

Es wird davon ausgegangen, dass Sie [docker](https://docs.docker.com/get-docker/) auf Ihrem lokalen Rechner installiert haben. Installieren Sie [docker-compose](https://docs.docker.com/compose/install/#install-compose), falls noch nicht geschehen.

Krane ist von RedisGraph abhängig. Der `docker-compose`-Stack definiert alles, was zum Erstellen und Ausführen des _Krane_-Dienstes lokal erforderlich ist. Er kümmert sich auch um die [RedisGraph](https://oss.redislabs.com/redisgraph/)-Abhängigkeit.```
docker-compose up -d

Sobald Sie im Container sind, können Sie die `krane`-Befehle verwenden. Versuchen Sie `krane -help`.```sh
krane -h

Um _Krane_ und seine abhängigen Dienste zu stoppen:```
docker-compose down

krane

Kubernetes RBAC static analysis & visualisation tool

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

-h, --help
    Display help documentation

-v, --version
    Display version information

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

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

### RBAC-Bericht generieren

#### Mit lokalem `kubectl`-Kontext

Um einen Bericht gegen einen laufenden Cluster auszuführen, müssen Sie einen _kubectl_-Kontext bereitstellen.```
krane report -k <context>

HINWEIS: _Krane_ erwartet, dass die folgenden Dateien (im YAML- oder JSON-Format) im angegebenen Verzeichnispfad vorhanden sind:
  - psp
  - roles
  - clusterroles
  - rolebindings
  - clusterrolebindings

Wenn Pod Security Policies nicht verwendet werden, können Sie die obige Erwartung umgehen, indem Sie manuell eine `psp`-Datei mit folgendem Inhalt erstellen:```json
{
  "items": []
}

HINWEIS: Das von _Krane_ verwendete Dienstkonto benötigt Zugriff auf RBAC-Ressourcen. Siehe [Voraussetzungen](https://github.com/appvia/krane/blob/HEAD/k8s/one-time/prerequisites.yaml) für Details.

#### In CI/CD-Pipeline

Um die RBAC-Definition als Schritt in der CI/CD-Pipeline zu validieren```
krane report --ci -d </path/to/rbac-directory>

Cluster-Flag `-c <Cluster-Name>` kann übergeben werden, wenn das Dashboard für einen bestimmten Cluster-Namen ausgeführt werden soll. Das Dashboard sucht dann nach Daten, die mit dem angegebenen Cluster-Namen verknüpft sind und auf dem Dateisystem zwischengespeichert sind.

Der obige Befehl startet einen lokalen Webserver auf dem Standard-Port `8000` und zeigt den Dashboard-Link an.

## Architektur

### RBAC-Daten in einer lokalen Graphdatenbank indiziert

_Krane_ indiziert RBAC-Entitäten in RedisGraph. Dies ermöglicht es uns, das Netzwerk von Abhängigkeiten effizient und einfach mit einer Teilmenge von [CypherQL](https://oss.redislabs.com/redisgraph/cypher_support/) zu durchsuchen, das von [RedisGraph](https://oss.redislabs.com/redisgraph/) unterstützt wird.

#### Schema

![Krane Entity Graph](https://raw.githubusercontent.com/appvia/krane/HEAD/doc/images/krane-graph-diagram.svg "Krane Entity Graph")

#### Knoten

Die folgenden Knoten werden im Graph für die relevanten RBAC-Objekte erstellt:

* `Psp`       - Ein PSP-Knoten, der Attribute zur Pod-Sicherheitsrichtlinie enthält. Nur anwendbar bei K8s < 1.25.
* `Rule`      - Ein Rule-Knoten repräsentiert eine Zugriffskontrollregel für Kubernetes-Ressourcen.
* `Role`      - Ein Role-Knoten repräsentiert eine bestimmte Rolle oder ClusterRole. Das `kind`-Attribut definiert den Typ der Rolle.
* `Subject`   - Subject repräsentiert alle möglichen Akteure im Cluster (`kind`: User, Group und ServiceAccount)
* `Namespace` - Kubernetes-Namespace-Knoten.

#### Kanten

* `:SECURITY`  - Definiert eine Verbindung zwischen Rule- und Psp-Knoten. Nur anwendbar bei K8s < 1.25.
* `:GRANT`     - Definiert eine Verbindung zwischen Role und der mit dieser Rolle verknüpften Rule.
* `:ASSIGN`    - Definiert eine Verbindung zwischen einem Actor (Subject) und einer bestimmten Role/ClusterRole (Role-Knoten).
* `:RELATION`  - Definiert eine Verbindung zwischen zwei verschiedenen Actor (Subject)-Knoten.
* `:SCOPE`     - Definiert eine Verbindung zwischen Role- und Namespace-Knoten.
* `:ACCESS`    - Definiert eine Verbindung zwischen Subject- und Namespace-Knoten.
* `:AGGREGATE` - Definiert eine Verbindung zwischen ClusterRoles (eine ClusterRole aggregiert eine andere) `A-(aggregiert)->B`
* `:COMPOSITE` - Definiert eine Verbindung zwischen ClusterRoles (eine ClusterRole kann in einer anderen aggregiert werden) `A<-(ist ein Kompositum von)-B`

Alle Kanten sind bidirektional, was bedeutet, dass der Graph in beide Richtungen durchsucht werden kann.
Die einzigen Ausnahmen sind die Beziehungen `:AGGREGATE` und `:COMPOSITE`, die unidirektional sind, obwohl sie dieselben Kantenknoten betreffen.

#### Abfragen des Graphen

Um den Graphen direkt abzufragen, können Sie in einen laufenden `redisgraph`-Container exec'en, `redis-cli` starten und Ihre eigenen Abfragen ausführen. Folgen Sie der offiziellen [Anleitung](https://oss.redislabs.com/redisgraph/) für Beispiele von [Befehlen](https://oss.redislabs.com/redisgraph/commands/).

Sie können den Graphen auch von der _Krane_-Konsole aus abfragen. Exec'en Sie zuerst in den laufenden _Krane_-Container, dann```ruby
# 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 results

res.print_resultset

Hinweis: Die obige Beispielabfrage wählt alle Subjects aus, denen Rollen/ClusterRoles zugewiesen sind, die Zugriff auf `update configmaps` gewähren.

## Konfiguration

### RBAC-Risikoregeln

RBAC-Risikoregeln sind in der Datei [Rules](https://github.com/appvia/krane/blob/HEAD/config/rules.yaml) definiert. Die Struktur jeder Regel ist weitgehend selbsterklärend.
Der integrierte Satz kann erweitert / überschrieben werden, indem zusätzliche benutzerdefinierte Regeln zur Datei [Custom Rules](https://github.com/appvia/krane/blob/HEAD/config/custom-rules.yaml) hinzugefügt werden.

#### Makros für Risikoregeln

Makros sind „Container“ für einen Satz gemeinsamer/geteilter Attribute und werden von einer oder mehreren Risikoregeln referenziert. Wenn Sie ein Makro in einer bestimmten Risikoregel verwenden möchten, müssen Sie es namentlich referenzieren, z. B. `macro: <Makro-Name>`. Beachten Sie, dass in einem referenzierten `macro` definierte Attribute Vorrang vor denselben Attributen haben, die auf Regel-Ebene definiert sind.

Ein Makro kann jedes der folgenden Attribute enthalten:

- `query`   - [RedisGraph-Abfrage](#querying-the-graph). Hat Vorrang vor `template`. Erfordert die Definition von `writer`.
- `writer`  - Ein Ruby-Ausdruck, der zum Formatieren des Ergebnissatzes von `query` verwendet wird. `writer` hat Vorrang vor `template`.
- `template` - Name einer integrierten Abfrage-/Writer-Vorlage. Wenn `query` & `writer` nicht angegeben sind, wird der gewählte Abfragegenerator zusammen mit dem passenden Writer verwendet.

#### Attribute von Risikoregeln

Eine Regel kann jedes der folgenden Attribute enthalten:

- `id`           [Erforderlich] Die Regel-ID ist eine eindeutige Kennung der Regel.
- `group_title`  [Erforderlich] Titel, der für alle Elemente dieser Risikoprüfung gilt.
- `severity`     [Erforderlich] Schweregrad, einer von :danger, :warning, :info.
- `info`         [Erforderlich] Textinformationen zur Prüfung und Vorschläge zur Risikominderung.
- `query`        [Bedingt] [RedisGraph-Abfrage](#querying-the-graph).
  - Hat Vorrang vor `template`. Erfordert die Definition von `writer`.
- `writer`       [Bedingt] Writer ist ein Ruby-Ausdruck, der zum Formatieren des Ergebnissatzes der Abfrage verwendet wird.
  - Writer hat Vorrang vor `template`. Erfordert die Definition von `query`.
- `template`     [Bedingt] Name einer integrierten Abfrage-/Writer-Vorlage. Wenn `query` & `writer` nicht angegeben sind, wird der gewählte Abfragegenerator zusammen mit dem passenden Writer verwendet.
  - Einige integrierte Vorlagen erfordern, dass auf individueller Regel-Ebene das Attribut `match_rules` angegeben wird, um die korrekte Abfrage zu erstellen. Vorlagen, die dies derzeit erfordern:

    - **_risky-role_** - Erstellt eine Multi-Match-Graph-Abfrage basierend auf den durch `match_rules` angegebenen Zugriffsregeln. Die generierte Graph-Abfrage gibt die folgenden Spalten zurück:
      - role_name
      - role_kind
      - namespace_name (ein _Array_ wird zurückgegeben, wenn mehrere Elemente zurückgegeben werden)

- `match_rules`  [Bedingt] Erforderlich, wenn `template` für die Abfrageerstellung auf Match-Regeln angewiesen ist.
  - Beispiel:
    ```yaml
     match_rules:
     - resources: ['cronjobs']
       verbs: ['update']
    ```
     Attribute und Werte folgen der [Kubernetes-RBAC-Rollenspezifikation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-examples).

- `custom_params` [Optional] Liste benutzerdefinierter Schlüssel-Wert-Paare, die in einer Regel-`query` und `writer`-Darstellung ausgewertet und ersetzt werden.
  - Beispiel:
    ```yaml
    custom_params:
    - attrA: valueA
    - attrB: valueB
    ```
    Vorlagenplatzhalter für die obigen Schlüssel `{{attrA}}` und `{{attrB}}` werden durch `valueA` bzw. `valueB` ersetzt.

- `threshold`  [Optional] Numerischer Wert. Wenn definiert, wird dies als Vorlagenplatzhalter `{{threshold}}` im `writer`-Ausdruck verfügbar.
- `macro`      [Optional] Referenz auf gemeinsame Parameter, die in einem benannten Makro definiert sind.
- `disabled`   [Optional] Wenn auf `true` gesetzt, deaktiviert es die angegebene Regel und schließt sie von der Bewertung aus.
                Standardmäßig sind alle Regeln aktiviert.

#### Beispiele für Risikoregeln

##### Explizite Abfrage & Writer-Ausdruck```yaml
- id: verbose-rule-example
  group_title: Example rule
  severity:    :danger
  info:        Risk description and instructions on how to mitigate it goes here
  query: |
    MATCH
      (s:Subject)-[:ACCESS]->(ns:Namespace)
    WHERE
      NOT s.name IN {{whitelist_subject_names}}
    RETURN
      s.kind as subject_kind,
      s.name as subject_name,
      COLLECT(ns.name) as namespace_names
    ORDER BY
      subject_kind,
      subject_name,
      namespace_names DESC
  threshold: 2
  writer: |
    if result.namespace_names.count > {{threshold}}
      "#{result.subject_kind} #{result.subject_name} can access namespaces: #{result.namespace_names.join(', ')}"
    end
  disabled: true

Das obige Beispiel zeigt eine der integrierten Regeln. Es verweist auf die Vorlage `risky-role`, die bei der Verarbeitung die Regel erweitert, indem sie `query`- und `writer`-Ausdrücke einfügt, bevor die Regelauswertung ausgelöst wird. `match_rules` wird verwendet, um die entsprechende Match-Abfrage zu erstellen.

### RBAC-Risiko-Whitelist

Die optionale Whitelist enthält eine Reihe von benutzerdefinierten Attributnamen und deren (whitelisted) Werten.

#### Whitelist-Attribute

Attributnamen und ihre Werte sind beliebig. Sie sind in der [Whitelist](https://github.com/appvia/krane/blob/HEAD/config/whitelist.yaml)-Datei definiert und in drei separate Abschnitte unterteilt:
  - `global` - Obere Ebene. Hier definierte benutzerdefinierte Attribute gelten für alle Risikoregeln, unabhängig vom Clusternamen.
  - `common` - Benutzerdefinierte Attribute werden auf eine bestimmte Risikoregeln-`id` beschränkt, unabhängig vom Clusternamen.
  - `cluster` (mit verschachtelter Liste von Clusternamen) - Benutzerdefinierte Attribute gelten für eine bestimmte Risikoregeln-`id` für einen angegebenen Clusternamen.

Jede [Risikoregeln](#rbac-risk-rules) versucht bei der Auswertung, alle in der `query` verwendeten Parameter-Platzhalter zu interpolieren, z. B. `{{your_whitelist_attribute_name}}`. Wenn ein Platzhalterparameter-Name (d. h. ein Name zwischen den doppelten geschweiften Klammern) mit einem der whitelisted Attributnamen für diese Risikoregeln-`id` übereinstimmt, wird er durch seinen berechneten Wert ersetzt.
Wenn für einen bestimmten Platzhalter keine Werte gefunden werden, wird er durch `['']` ersetzt.

#### Whitelist-Beispiele

Das folgende Whitelist-Beispiel erzeugt die folgende Zuordnung `placeholder-key => value` für eine [Risikoregeln](#rbac-risk-rules) mit dem `id`-Attributwert, der mit `_"some-risk-rule-id"_` übereinstimmt```
{{whitelist_role_names}}    => ['acp:prometheus:operator']
{{whitelist_subject_names}} => ['privileged-psp-user', 'another-user']

## Kubernetes-Bereitstellung

_Krane_ kann einfach in lokale oder entfernte Kubernetes-Cluster bereitgestellt werden.

### K8s-Voraussetzungen

Kubernetes-Namespace, Service Account sowie entsprechende RBAC müssen im Cluster vorhanden sein. Siehe [Voraussetzungen](https://github.com/appvia/krane/blob/HEAD/k8s/one-time/prerequisites.yaml) als Referenz.

Der Standard-Einstiegspunkt von _Krane_ führt [bin/in-cluster-run](https://github.com/appvia/krane/blob/HEAD/bin/in-cluster-run) aus, der darauf wartet, dass die RedisGraph-Instanz verfügbar wird, bevor er die RBAC-_Report_-Schleife und den _Dashboard_-Webserver startet.

Sie können bestimmte Aspekte der Ausführung im Cluster mit den folgenden Umgebungsvariablen steuern:

* `KRANE_REPORT_INTERVAL` - Definiert das Intervall in Sekunden für die Ausführung des RBAC-Statikanalyse-Reports. Standard: `300` (in Sekunden, d.h. 5 Minuten).
* `KRANE_REPORT_OUTPUT` - Definiert das Ausgabeformat des RBAC-Risikoreports. Mögliche Werte: `:json`, `:yaml`, `:none`. Standard: `:json`.

### Lokales oder entferntes K8s-Cluster

#### Helm Chart

Bevor wir beginnen, benötigen Sie die folgenden Werkzeuge:
* [Helm CLI](https://helm.sh/docs/intro/install/)

Installieren Sie das Helm-Chart:```sh
$ helm repo add appvia https://appvia.github.io/krane
$ helm repo update
$ helm install krane appvia/krane --namespace krane --create-namespace

Beachten Sie, dass der _Krane_-Dashboard-Dienst standardmäßig nicht freigegeben ist!```sh
kubectl port-forward svc/krane 8000 \
  --context=<docker-desktop> \
  --namespace=krane

# Open Krane dashboard at http://localhost:8000

Hinweis: Stellen Sie sicher, dass Ihr aktueller kube-Kontext korrekt eingestellt ist, bevor Sie den obigen Befehl ausführen!

Der Anwendungsstack sollte jetzt in einem Kubernetes-Cluster bereitgestellt sein und alle Dienste bereit und exponiert. Beachten Sie, dass _Krane_ automatisch seine Berichtsschleife und den Dashboard-Server startet.```sh
docker stack services --orchestrator kubernetes --namespace krane krane

Überprüfen Sie die RBAC-Sicherheitslage Ihres Kubernetes-Clusters, indem Sie http://localhost:8000 besuchen.

Beachten Sie, dass Sie für entfernte Cluster-Bereitstellungen wahrscheinlich zuerst den _Krane_-Dienst port-forwarden müssen.```sh
kubectl --context=my-remote-cluster --namespace=krane port-forward svc/krane 8000

## Notifications

Krane wird Sie über erkannte Anomalien mittlerer und hoher Schwere über seine Slack-Integration benachrichtigen.

Um Benachrichtigungen zu aktivieren, geben Sie Slack `webhook_url` & `channel` in der Datei [config/config.yaml](https://github.com/appvia/krane/blob/HEAD/config/config.yaml) an, oder setzen Sie alternativ die Umgebungsvariablen `SLACK_WEBHOOK_URL` und `SLACK_CHANNEL`. Umgebungsvariablen haben Vorrang vor den Werten in der Konfigurationsdatei.

## Lokale Entwicklung

Dieser Abschnitt beschreibt die Schritte zur Einrichtung der lokalen Entwicklung.

### Einrichtung

Installieren Sie die _Krane_ Code-Abhängigkeiten mit```sh
./bin/setup

Um zu überprüfen, ob der RedisGraph-Dienst läuft:```sh
docker-compose ps

### Entwicklung

An diesem Punkt sollten Sie in der Lage sein, die _Krane_ Codebasis zu ändern und die Ergebnisse durch Aufrufen von Befehlen in der lokalen Shell zu testen.```sh
$ ./bin/krane --help                    # to get help
$ ./bin/krane report -k docker-desktop  # to generate your first report for
                                        # local docker-desktop k8s cluster
...

Dies wird automatisch den Dashboard-Server starten, den Standardbrowser öffnen und auf Änderungen an den Quelldateien überwachen.

_Krane_ kommt vorkonfiguriert für eine verbesserte Entwicklererfahrung mit [Skaffold](https://skaffold.dev/). Das Iterieren am Projekt und das Validieren der Anwendung durch Ausführen des gesamten Stacks in einem lokalen oder entfernten Kubernetes-Cluster ist jetzt noch einfacher geworden. Code-Hot-Reload ermöglicht es, lokale Änderungen automatisch an den laufenden Container weiterzugeben, um den Entwicklungslebenszyklus zu beschleunigen.```sh
skaffold dev --kube-context docker-desktop --namespace krane --port-forward

## Mitwirken an Krane

Wir begrüßen alle Beiträge aus der Community! Schauen Sie sich unseren [Beitragsleitfaden](https://github.com/appvia/krane/blob/HEAD/CONTRIBUTING.md) an, um weitere Informationen zum Einstieg zu erhalten. Wenn Sie _Krane_ nutzen, nützlich finden oder sich allgemein für Kubernetes-Sicherheit interessieren, lassen Sie es uns bitte wissen, indem Sie dieses Repository **mit einem Stern markieren** und **beobachten**. Danke!

## Mitmachen

Beteiligen Sie sich an der Diskussion auf unserem [Community-Kanal](https://www.appvia.io/join-the-appvia-community).

Krane ist ein Community-Projekt und wir begrüßen Ihre Beiträge. Um einen Fehler zu melden, eine Verbesserung vorzuschlagen oder eine neue Funktion anzufragen, öffnen Sie bitte ein Github-Issue. Informationen dazu, wie Sie helfen können, finden Sie in unserem [Beitragsleitfaden](https://github.com/appvia/krane/blob/HEAD/CONTRIBUTING.md).

## Roadmap

Einzelheiten zu unseren Plänen für das Projekt finden Sie in unserer [Roadmap](https://github.com/appvia/krane/projects/1).


## Lizenz

Autor: Marcin Ciszak <[email protected]>

Copyright (c) 2019-2020 [Appvia Ltd](https://appvia.io)

Dieses Projekt wird unter der [Apache License, Version 2.0](https://github.com/appvia/krane/blob/HEAD/LICENSE) vertrieben.