[!IMPORTANT] KubeClarity wurde eingestellt und durch openclarity/openclarity ersetzt.

Prüfen Sie die Veröffentlichungsmitteilung für weitere Informationen.

Dieses Projekt erhält keine Updates mehr. Wir empfehlen Ihnen, zu migrieren.

KubeClarity ist ein Werkzeug zur Erkennung und Verwaltung von Software-Stücklisten (SBOM) und Schwachstellen von Container-Images und Dateisystemen. Es scannt sowohl Kubernetes-Cluster zur Laufzeit als auch CI/CD-Pipelines für eine verbesserte Sicherheit der Softwarelieferkette.

Inhaltsverzeichnis

• Warum?
  • SBOM- und Schwachstellenerkennungs-Herausforderungen
  • Lösung
• Funktionen
  • Integrierte SBOM-Generatoren und Schwachstellenscanner
• Architektur
• Erste Schritte
  • KubeClarity Backend
    • Installation mit Helm
    • Deinstallation mit Helm
    • Lokal mit Demodaten erstellen und ausführen
  • CLI
    • Installation
    • SBOM-Generierung
    • Schwachstellenscan
    • Exportieren von Ergebnissen in das KubeClarity Backend
• Erweiterte Konfiguration
  • SBOM-Generierung mit lokalem Docker-Image als Eingabe
  • Schwachstellenscan mit lokalem Docker-Image als Eingabe
  • Unterstützung privater Registries für CLI
  • Unterstützung privater Registries für K8s-Laufzeitscan
  • Zusammenführen von SBOM und Schwachstellen über verschiedene CI/CD-Phasen hinweg
  • Ausgabe verschiedener SBOM-Formate
  • Remote-Scanner-Server für CLI
• Einschränkungen
• Fahrplan
• Mitwirken
• Lizenz

Warum?

SBOM- und Schwachstellenerkennungs-Herausforderungen

• Eine effektive Schwachstellenerkennung erfordert eine genaue Erkennung der Software-Stückliste (SBOM):
  • Verschiedene Programmiersprachen und Paketmanager
  • Verschiedene Betriebssystemverteilungen
  • Paketabhängigkeitsinformationen werden normalerweise beim Build entfernt
• Welcher ist der beste Scanner/SBOM-Analysator?
• Was sollen wir scannen: Git-Repos, Builds, Container-Images oder die Laufzeit?
• Jeder Scanner/Analysator hat sein eigenes Format - wie vergleicht man die Ergebnisse?
• Wie verwaltet man die entdeckten SBOMs und Schwachstellen?
• Wie sind meine Anwendungen von einer neu entdeckten Schwachstelle betroffen?

Lösung

• Unterteilen Sie die Schwachstellenerkennung in zwei Phasen:
  • Inhaltsanalyse zur Generierung der SBOM
  • Scannen der SBOM auf Schwachstellen
• Erstellen Sie eine erweiterbare Infrastruktur, um:
  • Mehrere Inhaltsanalysatoren parallel auszuführen
  • Mehrere Schwachstellenscanner parallel auszuführen
• Scannen und Zusammenführen von Ergebnissen zwischen verschiedenen CI-Phasen mit der KubeClarity CLI
• Laufzeit-K8s-Scan zur Erkennung von nach der Bereitstellung entdeckten Schwachstellen
• Gruppieren Sie gescannte Ressourcen (Images/Verzeichnisse) unter definierten Anwendungen, um die Abhängigkeiten im Objektbaum zu navigieren (Anwendungen, Ressourcen, Pakete, Schwachstellen)

Funktionen

• Dashboard
  • Behebbare Schwachstellen nach Schweregrad
  • Top 5 gefährdete Elemente (Anwendungen, Ressourcen, Pakete)
  • Trends neuer Schwachstellen
  • Paketanzahl nach Lizenztyp
  • Paketanzahl nach Programmiersprache
  • Allgemeine Zähler
• Anwendungen
  • Automatische Erkennung von Anwendungen in der K8s-Laufzeit
  • Anwendungen erstellen/bearbeiten/löschen
  • Pro Anwendung Navigation zu zugehörigen:
    • Ressourcen (Images/Verzeichnisse)
    • Pakete
    • Schwachstellen
    • Von den Ressourcen verwendete Lizenzen
• Anwendungsressourcen (Images/Verzeichnisse)
  • Pro Ressource Navigation zu zugehörigen:
    • Anwendungen
    • Pakete
    • Schwachstellen
• Pakete
  • Pro Paket Navigation zu zugehörigen:
    • Anwendungen
    • Verlinkbare Liste von Ressourcen und den erkennenden SBOM-Analysatoren
    • Schwachstellen
• Schwachstellen
  • Pro Schwachstelle Navigation zu zugehörigen:
    • Anwendungen
    • Ressourcen
    • Liste der erkennenden Scanner
• K8s-Laufzeitscan
  • Bedarfsgesteuerter oder geplanter Scan
  • Automatische Erkennung von Ziel-Namespaces
  • Scan-Fortschritt und Ergebnisnavigation pro betroffenem Element (Anwendungen, Ressourcen, Pakete, Schwachstellen)
  • CIS Docker-Benchmark
• CLI (CI/CD)
  • SBOM-Generierung mit mehreren integrierten Inhaltsanalysatoren (Syft, cyclonedx-gomod)
  • Schwachstellenscan von SBOM/Image/Verzeichnis mit mehreren integrierten Scannern (Grype, Dependency-track)
  • Zusammenführen von SBOM und Schwachstellen über verschiedene CI/CD-Phasen hinweg
  • Exportieren von Ergebnissen in das KubeClarity Backend
• API
  • Die API für KubeClarity finden Sie hier

Integrierte SBOM-Generatoren und Schwachstellenscanner

Der KubeClarity-Inhaltsanalysator integriert die folgenden SBOM-Generatoren:

• Syft
• Cyclonedx-gomod
• Trivy

Der KubeClarity-Schwachstellenscanner integriert die folgenden Scanner:

• Grype
• Dependency-Track
• Trivy

Architektur

Erste Schritte

KubeClarity Backend

Installation mit Helm:

1. Helm-Repository hinzufügen ```shell helm repo add kubeclarity https://openclarity.github.io/kubeclarity

   root@kitploit:~

2. Speichern Sie die Standard-Chart-Werte von KubeClarity

   root@kitploit:~

   helm show values kubeclarity/kubeclarity > values.yaml
   

3. Überprüfen Sie die Konfiguration in values.yaml und aktualisieren Sie die erforderlichen Werte bei Bedarf. Um die unterstützten SBOM-Generatoren und Schwachstellenscanner zu aktivieren und zu konfigurieren, überprüfen Sie bitte die "analyzer"- und "scanner"-Konfiguration unter dem Abschnitt "vulnerability-scanner" in den Helm-Werten.

4. Stellen Sie KubeClarity mit Helm bereit ```shell helm install --values values.yaml --create-namespace kubeclarity kubeclarity/kubeclarity -n kubeclarity

   root@kitploit:~

oder für OpenShift Restricted SCC kompatible Installation: ```shell helm install --values values.yaml --create-namespace kubeclarity kubeclarity/kubeclarity -n kubeclarity --set global.openShiftRestricted=true
--set kubeclarity-postgresql.securityContext.enabled=false --set kubeclarity-postgresql.containerSecurityContext.enabled=false
--set kubeclarity-postgresql.volumePermissions.enabled=true --set kubeclarity-postgresql.volumePermissions.securityContext.runAsUser="auto"
--set kubeclarity-postgresql.shmVolume.chmod.enabled=false

3. Port-Weiterleitung zur KubeClarity UI:   ```shell
kubectl port-forward -n kubeclarity svc/kubeclarity-kubeclarity 9999:8080

4. Öffnen Sie die KubeClarity-Benutzeroberfläche im Browser: http://localhost:9999/

HINWEIS
KubeClarity erfordert diese K8s-Berechtigungen:

Deinstallation mit Helm:

1. Helm deinstallieren ```shell helm uninstall kubeclarity -n kubeclarity

   root@kitploit:~

2. Ressourcen bereinigen

   Standardmäßig entfernt Helm nicht die PVCs und PVs für die StatefulSets. Führen Sie den folgenden Befehl aus, um alle zu löschen:

   root@kitploit:~

   kubectl delete pvc -l app.kubernetes.io/instance=kubeclarity -n kubeclarity
   

Lokal mit Demodaten bauen und ausführen

1. UI und Backend bauen und das Backend lokal starten (2 Optionen):

   1. Mit Docker:
      1. UI und Backend bauen (das Image-Tag wird mit VERSION gesetzt):
         root@kitploit:~

         VERSION=test make docker-backend
         

      2. Backend mit Demodaten ausführen:
         root@kitploit:~

         docker run -p 8080:8080 -e FAKE_RUNTIME_SCANNER=true -e FAKE_DATA=true -e ENABLE_DB_INFO_LOGS=true -e DATABASE_DRIVER=LOCAL ghcr.io/openclarity/kubeclarity:test run
         

   2. Lokaler Build:
      1. UI und Backend bauen
         root@kitploit:~

         make ui && make backend
         

      2. Das gebaute Site kopieren:
         root@kitploit:~

         cp -r ./ui/build ./site
         

      3. Backend lokal mit Demodaten ausführen:
         root@kitploit:~

         FAKE_RUNTIME_SCANNER=true DATABASE_DRIVER=LOCAL FAKE_DATA=true ENABLE_DB_INFO_LOGS=true ./backend/bin/backend run
         

2. Öffnen Sie die KubeClarity-Benutzeroberfläche im Browser: http://localhost:8080/

CLI

KubeClarity enthält eine CLI, die lokal ausgeführt werden kann und besonders nützlich für CI/CD-Pipelines ist. Sie ermöglicht die Analyse von Images und Verzeichnissen zur Erstellung von SBOM und deren Überprüfung auf Schwachstellen. Die Ergebnisse können in das KubeClarity-Backend exportiert werden.

Installation

SBOM-Generierung

Verwendung:``` kubeclarity-cli analyze <image/directory name> --input-type <dir|file|image(default)> -o

Beispiel:```
kubeclarity-cli analyze --input-type image nginx:latest -o nginx.sbom

Optionalerweise kann eine Liste der zu verwendenden Content-Analyzer mit der Umgebungsvariablen ANALYZER_LIST konfiguriert werden, getrennt durch ein Leerzeichen (z. B. ANALYZER_LIST="<Analyzer 1 Name> <Analyzer 2 Name>")

Beispiel:``` ANALYZER_LIST="syft gomod" kubeclarity-cli analyze --input-type image nginx:latest -o nginx.sbom

### Schwachstellenscanning

Verwendung:```
kubeclarity-cli scan <image/sbom/directoty/file name> --input-type <sbom|dir|file|image(default)> -f <output file>

Beispiel:``` kubeclarity-cli scan nginx.sbom --input-type sbom

Optional kann eine Liste der zu verwendenden Schwachstellenscanner mithilfe der Umgebungsvariablen `SCANNERS_LIST` 
durch ein Leerzeichen getrennt konfiguriert werden (z.B. `SCANNERS_LIST="<Scanner1 name> <Scanner2 name>"`)

Beispiel:```
SCANNERS_LIST="grype trivy" kubeclarity-cli scan nginx.sbom --input-type sbom

Exportieren von Ergebnissen an das KubeClarity-Backend

Um CLI-Ergebnisse an das KubeClarity-Backend zu exportieren, muss eine Anwendungs-ID verwendet werden, die vom KubeClarity-Backend definiert wird. Die Anwendungs-ID finden Sie im Bildschirm "Applications" der Benutzeroberfläche oder über die KubeClarity-API.

Exportieren von SBOM```

The SBOM can be exported to KubeClarity backend by setting the BACKEND_HOST env variable and the -e flag.

Note: Until TLS is supported, BACKEND_DISABLE_TLS=true should be set.

BACKEND_HOST= BACKEND_DISABLE_TLS=true kubeclarity-cli analyze --application-id -e -o

For example:

BACKEND_HOST=localhost:9999 BACKEND_DISABLE_TLS=true kubeclarity-cli analyze nginx:latest --application-id 23452f9c-6e31-5845-bf53-6566b81a2906 -e -o nginx.sbom

#### Exportieren von Schwachstellen-Scan-Ergebnissen```
# The vulnerability scan result can be exported to KubeClarity backend by setting the BACKEND_HOST env variable and the -e flag.
# Note: Until TLS is supported, BACKEND_DISABLE_TLS=true should be set.

BACKEND_HOST=<KubeClarity backend address> BACKEND_DISABLE_TLS=true kubeclarity-cli scan <image> --application-id <application ID> -e

# For example:
SCANNERS_LIST="grype" BACKEND_HOST=localhost:9999 BACKEND_DISABLE_TLS=true kubeclarity-cli scan nginx.sbom --input-type sbom  --application-id 23452f9c-6e31-5845-bf53-6566b81a2906 -e

Erweiterte Konfiguration

SBOM-Erstellung unter Verwendung eines lokalen Docker-Images als Eingabe```

Local docker images can be analyzed using the LOCAL_IMAGE_SCAN env variable

For example:

LOCAL_IMAGE_SCAN=true kubeclarity-cli analyze nginx:latest -o nginx.sbom

## Schwachstellenscan unter Verwendung eines lokalen Docker-Images als Eingabe```
# Local docker images can be scanned using the LOCAL_IMAGE_SCAN env variable

# For example:
LOCAL_IMAGE_SCAN=true kubeclarity-cli scan nginx.sbom

Private Registry-Unterstützung für die CLI

Die KubeClarity-CLI kann eine Konfigurationsdatei lesen, die Anmeldedaten für private Registries speichert.

Beispiel für den Registry-Abschnitt der Konfigurationsdatei:``` registry: auths: - authority: <registry 1> username: <username for registry 1> password: <password for registry 1> - authority: <registry 2> token: <token for registry 2>

Beispiel einer Registry-Konfiguration ohne Autorisierung: (in diesem Fall werden diese Anmeldeinformationen für alle Registries verwendet)```
registry:
  auths:
    - username: <username>
      password: <password>

Konfigurationsdatei für CLI angeben```

The default config path is $HOME/.kubeclarity or it can be specified by --config command line flag.

kubeclarity <scan/analyze> --config

For example:

kubeclarity scan registry/nginx:private --config $HOME/own-kubeclarity-config

## Unterstützung privater Registrierungen für den K8s-Laufzeitscan

Kubeclarity verwendet [k8schain](https://github.com/google/go-containerregistry/tree/main/pkg/authn/k8schain#k8schain) von google/go-containerregistry zur Authentifizierung an den Registrierungen.
Falls die erforderlichen Dienst-Anmeldedaten nicht von der k8schain ermittelt werden können, können sie über die unten beschriebenen Secrets definiert werden.

Zusätzlich, falls sich die Dienst-Anmeldedaten nicht im Namespace "kubeclarity" befinden, setzen Sie bitte CREDS_SECRET_NAMESPACE im kubeclarity Deployment.
Bei Verwendung von Helm [charts](https://github.com/openclarity/kubeclarity/blob/HEAD/charts) wird CREDS_SECRET_NAMESPACE auf den Release-Namespace gesetzt, in dem kubeclarity installiert ist.

### Amazon ECR

Erstellen Sie einen [AWS IAM-Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console) mit den Berechtigungen `AmazonEC2ContainerRegistryFullAccess`.

Verwenden Sie die Benutzer-Anmeldedaten (`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_DEFAULT_REGION`), um das folgende Secret zu erstellen:```
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: ecr-sa
  namespace: kubeclarity
type: Opaque
data:
  AWS_ACCESS_KEY_ID: $(echo -n 'XXXX'| base64 -w0)
  AWS_SECRET_ACCESS_KEY: $(echo -n 'XXXX'| base64 -w0)
  AWS_DEFAULT_REGION: $(echo -n 'XXXX'| base64 -w0)
EOF

Hinweis:

1. Der Secret-Name muss ecr-sa sein
2. Die Secret-Daten-Schlüssel müssen auf AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY und AWS_DEFAULT_REGION gesetzt werden

Google GCR

Erstellen Sie ein Google-Dienstkonto mit Artifact Registry Reader-Berechtigungen.

Verwenden Sie die JSON-Datei des Dienstkontos, um das folgende Secret zu erstellen``` kubectl -n kubeclarity create secret generic --from-file=sa.json gcr-sa

Hinweis:
1. Der Secret-Name muss `gcr-sa` sein
1. `sa.json` muss der Name der Servicekonto-JSON-Datei beim Generieren des Secrets sein
2. KubeClarity verwendet [Standardanmeldedaten für Anwendungen](https://developers.google.com/identity/protocols/application-default-credentials). Diese funktionieren nur, wenn KubeClarity von GCP aus ausgeführt wird.

## Zusammenführung von SBOM und Schwachstellen über verschiedene CI/CD-Stufen hinweg```
# Additional SBOM will be merged into the final results when '--merge-sbom' is defined during analysis. The input SBOM can be CycloneDX XML or CyclonDX json format.
# For example:
ANALYZER_LIST="syft" kubeclarity-cli analyze nginx:latest -o nginx.sbom --merge-sbom inputsbom.xml

Verschiedene SBOM-Formate ausgeben

Der Befehl kubeclarity-cli analyze kann das resultierende SBOM bei Bedarf in verschiedenen Formaten ausgeben, um es in ein anderes System zu integrieren. Die unterstützten Formate sind:

WARNING
KubeClarity verarbeitet CycloneDX intern, die anderen Formate werden über eine Konvertierung unterstützt. Der Konvertierungsprozess kann aufgrund von Inkompatibilitäten zwischen den Formaten verlustbehaftet sein, daher wird nicht garantiert, dass alle Felder/Informationen in der resultierenden Ausgabe vorhanden sind.

Um das kubeclarity-cli so zu konfigurieren, dass ein anderes als das Standardformat verwendet wird, kann die Umgebungsvariable ANALYZER_OUTPUT_FORMAT mit dem entsprechenden Konfigurationsnamen von oben verwendet werden:``` ANALYZER_OUTPUT_FORMAT="spdx-json" kubeclarity-cli analyze nginx:latest -o nginx.sbom

## Remote-Scanner-Server für die CLI

Beim Ausführen der kubeclarity-CLI zum Scannen nach Schwachstellen muss die CLI die relevanten Schwachstellen-Datenbanken an den Ort herunterladen, an dem die kubeclarity-CLI ausgeführt wird. Das Ausführen der CLI in einer CI/CD-Pipeline führt dazu, dass die Datenbanken bei jedem Lauf heruntergeladen werden, was Zeit und Bandbreite verschwendet. Aus diesem Grund haben mehrere der unterstützten Scanner einen Remote-Modus, in dem ein Server für die Verwaltung der Datenbanken und möglicherweise das Scannen der Artefakte verantwortlich ist.

> ***Hinweis***
>
> Die folgenden Beispiele gelten für jeden der Scanner, aber sie können kombiniert werden, um zusammen ausgeführt zu werden, genau wie im nicht-remoten Modus.

### Trivy

Der Trivy-Scanner unterstützt den Remote-Modus über den Trivy-Server. Der Trivy-Server kann wie hier dokumentiert bereitgestellt werden: [Trivy-Client-Server-Modus](https://aquasecurity.github.io/trivy/v0.34/docs/references/modes/client-server/). Anweisungen zur Installation der Trivy-CLI finden Sie hier: [Trivy-Installation](https://aquasecurity.github.io/trivy/v0.34/getting-started/installation/). Das Aqua-Team stellt ein offizielles Container-Image zur Verfügung, das verwendet werden kann, um den Server in Kubernetes/Docker auszuführen, was wir in den Beispielen hier verwenden werden.

So starten Sie den Server:```
docker run -p 8080:8080 --rm aquasec/trivy:0.41.0 server --listen 0.0.0.0:8080

Um einen Scan mit dem Server auszuführen:``` SCANNERS_LIST="trivy" SCANNER_TRIVY_SERVER_ADDRESS="http://:8080" ./kubeclarity_cli scan --input-type sbom nginx.sbom

Der trivy-Server bietet außerdem eine tokenbasierte Authentifizierung, um die unbefugte Nutzung einer trivy-Serverinstanz zu verhindern. Sie können sie aktivieren, indem Sie den Server mit dem zusätzlichen Flag ausführen:```
docker run -p 8080:8080 --rm aquasec/trivy:0.41.0 server --listen 0.0.0.0:8080 --token mytoken

und das Token an den Scanner übergeben:``` SCANNERS_LIST="trivy" SCANNER_TRIVY_SERVER_ADDRESS="http://:8080" SCANNER_TRIVY_SERVER_TOKEN="mytoken" ./kubeclarity_cli scan --input-type sbom nginx.sbom

### Grype

Grype unterstützt den Remote-Modus mit [grype-server](https://github.com/portshift/grype-server),
einem RESTful Grype-Wrapper, der eine API bereitstellt, die ein SBOM empfängt und
die Grype-Scanergebnisse für dieses SBOM zurückgibt. Grype-server wird als Container-Image ausgeliefert,
sodass es in Kubernetes oder als eigenständiger Docker-Container ausgeführt werden kann.

Um den Server zu starten:```
docker run -p 9991:9991 --rm gcr.io/eticloud/k8sec/grype-server:v0.1.5

Um einen Scan mit dem Server auszuführen:``` SCANNERS_LIST="grype" SCANNER_GRYPE_MODE="remote" SCANNER_REMOTE_GRYPE_SERVER_ADDRESS=":9991" SCANNER_REMOTE_GRYPE_SERVER_SCHEMES="https" ./kubeclarity_cli scan --input-type sbom nginx.sbom

Wenn der Grype-Server mit TLS bereitgestellt wird, können Sie das Standard-URL-Schema wie folgt überschreiben:```
SCANNERS_LIST="grype" SCANNER_GRYPE_MODE="remote" SCANNER_REMOTE_GRYPE_SERVER_ADDRESS="<grype server address>:9991" SCANNER_REMOTE_GRYPE_SERVER_SCHEMES="https" ./kubeclarity_cli scan --input-type sbom nginx.sbom

Dependency Track

Siehe Beispielkonfiguration hier

Einschränkungen

1. Unterstützt Docker Image Manifest V2, Schema 2 (https://docs.docker.com/registry/spec/manifest-v2-2/). Das Scannen früherer Versionen wird fehlschlagen.

Roadmap

• Integration mit zusätzlichen Inhaltsanalysetools (SBOM-Generatoren)
• Integration mit zusätzlichen Schwachstellenscannern
• CIS Docker-Benchmark in der Benutzeroberfläche
• Image-Signierung mit Cosign
• CI/CD-Metadaten-Signierung und -Attestierung mit Cosign und in-toto (Lieferkettensicherheit)
• Systemeinstellungen und Benutzerverwaltung

Mitwirken

Pull-Requests und Fehlerberichte sind willkommen.

Für größere Änderungen erstellen Sie bitte zuerst ein Issue in GitHub, um Ihre vorgeschlagenen Änderungen und mögliche Auswirkungen zu besprechen.

Weitere Einzelheiten finden Sie in den Richtlinien für Beiträge zu diesem Projekt

Lizenz

Apache License, Version 2.0