openclarity/kubeclarityKubeClarity ist ein Werkzeug zur Erkennung und Verwaltung von Software-Stücklisten (SBOM) und Schwachstellen von Container-Images und Dateisystemen.
[!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.
Der KubeClarity-Inhaltsanalysator integriert die folgenden SBOM-Generatoren:
Der KubeClarity-Schwachstellenscanner integriert die folgenden Scanner:
Helm-Repository hinzufügen ```shell helm repo add kubeclarity https://openclarity.github.io/kubeclarity
Speichern Sie die Standard-Chart-Werte von KubeClarity
helm show values kubeclarity/kubeclarity > values.yaml
Ü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.
Stellen Sie KubeClarity mit Helm bereit ```shell helm install --values values.yaml --create-namespace kubeclarity kubeclarity/kubeclarity -n kubeclarity
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
HINWEIS
KubeClarity erfordert diese K8s-Berechtigungen:
Berechtigung Grund Geheimnisse im CREDS_SECRET_NAMESPACE lesen (Standard: kubeclarity) Dies ermöglicht Ihnen, Image-Pull-Secrets für das Scannen privater Image-Repositories zu konfigurieren. ConfigMaps im KubeClarity-Deployment-Namespace lesen. Dies wird benötigt, um die konfigurierte Vorlage des Scanner-Jobs abzurufen. Pods im Cluster-Bereich auflisten. Dies wird benötigt, um die Ziel-Pods zu berechnen, die gescannt werden müssen. Namespaces auflisten. Dies wird benötigt, um die Ziel-Namespaces für den K8s-Runtime-Scan in der Benutzeroberfläche abzurufen. Jobs im Cluster-Bereich erstellen und löschen. Dies wird benötigt, um die Jobs zu verwalten, die die Ziel-Pods in ihren Namespaces scannen.
Helm deinstallieren ```shell helm uninstall kubeclarity -n kubeclarity
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:
kubectl delete pvc -l app.kubernetes.io/instance=kubeclarity -n kubeclarity
UI und Backend bauen und das Backend lokal starten (2 Optionen):
VERSION=test make docker-backend
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
make ui && make backend
cp -r ./ui/build ./site
FAKE_RUNTIME_SCANNER=true DATABASE_DRIVER=LOCAL FAKE_DATA=true ENABLE_DB_INFO_LOGS=true ./backend/bin/backend run
Öffnen Sie die KubeClarity-Benutzeroberfläche im Browser: http://localhost:8080/
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.
Laden Sie die Release-Distribution für Ihr Betriebssystem von der Releases-Seite herunter.
Entpacken Sie die kubeclarity-cli-Binärdatei, fügen Sie sie zu Ihrem PATH hinzu, und schon sind Sie startklar!
Ein Docker-Image ist unter ghcr.io/openclarity/kubeclarity-cli mit einer Liste
verfügbarer Tags hier erhältlich.
``` make cli ``` Kopieren Sie `./cli/bin/cli` als `kubeclarity-cli` in Ihren PATH.
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
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.
BACKEND_HOST= BACKEND_DISABLE_TLS=true kubeclarity-cli analyze --application-id -e -o
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
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
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>
--config command line flag.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/main/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:
ecr-sa seinAWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY und AWS_DEFAULT_REGION gesetzt werdenErstellen 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
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:
| Format | Konfigurationsname |
|---|---|
| CycloneDX JSON (Standard) | cyclonedx-json |
| CycloneDX XML | cyclonedx-xml |
| SPDX JSON | spdx-json |
| SPDX Tag Value | spdx-tv |
| Syft JSON | syft-json |
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
Siehe Beispielkonfiguration hier
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