openclarity/kubeclarityKubeClarity è uno strumento per il rilevamento e la gestione del Software Bill of Materials (SBOM) e delle vulnerabilità delle immagini container e dei filesystem.
[!IMPORTANT] KubeClarity è stato deprecato e sostituito da openclarity/openclarity.
Consulta il comunicato di rilascio per maggiori informazioni.
Questo progetto non riceve aggiornamenti. Ti invitiamo a migrare.
KubeClarity è uno strumento per il rilevamento e la gestione della Software Bill Of Materials (SBOM) e delle vulnerabilità di immagini contenitore e filesystem. Esegue scansioni sia su cluster K8s in runtime che su pipeline CI/CD per una maggiore sicurezza della catena di fornitura del software.
L'analizzatore di contenuto di KubeClarity si integra con i seguenti generatori di SBOM:
Lo scanner di vulnerabilità di KubeClarity si integra con i seguenti scanner:
Aggiungere il repository Helm ```shell helm repo add kubeclarity https://openclarity.github.io/kubeclarity
Salva i valori predefiniti del chart di KubeClarity
helm show values kubeclarity/kubeclarity > values.yaml
Controlla la configurazione in values.yaml e aggiorna i valori necessari se
richiesto. Per abilitare e configurare i generatori di SBOM e gli scanner di
vulnerabilità supportati, controlla la configurazione "analyzer" e "scanner" nella
sezione "vulnerability-scanner" nei valori di Helm.
Distribuisci KubeClarity con Helm ```shell helm install --values values.yaml --create-namespace kubeclarity kubeclarity/kubeclarity -n kubeclarity
o per installazione compatibile con OpenShift Restricted SCC: ```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. Inoltra la porta verso l'interfaccia di KubeClarity: ```shell
kubectl port-forward -n kubeclarity svc/kubeclarity-kubeclarity 9999:8080
NOTA
KubeClarity richiede questi permessi K8s:
Permesso Motivazione Leggere i segreti in CREDS_SECRET_NAMESPACE (default: kubeclarity) Ciò consente di configurare i segreti per il pull delle immagini per la scansione di repository di immagini private. Leggere le config map nel namespace di deployment di KubeClarity. Ciò è necessario per ottenere il template configurato del job di scansione. Elencare i pod nell'ambito del cluster. Ciò è necessario per calcolare i pod target da scansionare. Elencare i namespace. Ciò è necessario per recuperare i namespace target da scansionare nell'interfaccia di scansione runtime di K8s. Creare ed eliminare job nell'ambito del cluster. Ciò è necessario per gestire i job che scansioneranno i pod target nei loro namespace.
Helm uninstall ```shell helm uninstall kubeclarity -n kubeclarity
Pulire le risorse
Per impostazione predefinita, Helm non rimuoverà i PVC e i PV per i StatefulSets. Eseguire il seguente comando per eliminarli tutti:
kubectl delete pvc -l app.kubernetes.io/instance=kubeclarity -n kubeclarity
Compilare l'interfaccia utente e il backend e avviare il backend localmente (2 opzioni):
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
Aprire l'interfaccia utente di KubeClarity nel browser: http://localhost:8080/
KubeClarity include una CLI che può essere eseguita localmente ed è particolarmente utile per le pipeline CI/CD. Permette di analizzare immagini e directory per generare SBOM e scansionarlo per vulnerabilità. I risultati possono essere esportati nel backend di KubeClarity.
Scaricare la distribuzione della release per il proprio sistema operativo dalla pagina delle release
Estrarre il binario kubeclarity-cli, aggiungerlo al PATH e si è pronti all'uso!
Un'immagine Docker è disponibile su ghcr.io/openclarity/kubeclarity-cli con l'elenco dei
tag disponibili qui.
``` make cli ``` Copia `./cli/bin/cli` nel tuo PATH con il nome `kubeclarity-cli`.
Utilizzo:``` kubeclarity-cli analyze <image/directory name> --input-type <dir|file|image(default)> -o
Esempio:```
kubeclarity-cli analyze --input-type image nginx:latest -o nginx.sbom
Opzionalmente, è possibile configurare un elenco degli analizzatori di contenuti da utilizzare tramite la variabile d'ambiente ANALYZER_LIST
separata da uno spazio (es. ANALYZER_LIST="<nome analizzatore 1> <nome analizzatore 2>")
Esempio:``` ANALYZER_LIST="syft gomod" kubeclarity-cli analyze --input-type image nginx:latest -o nginx.sbom
### Scansione delle vulnerabilità
Utilizzo:```
kubeclarity-cli scan <image/sbom/directoty/file name> --input-type <sbom|dir|file|image(default)> -f <output file>
Esempio:``` kubeclarity-cli scan nginx.sbom --input-type sbom
Opzionalmente, è possibile configurare un elenco degli scanner di vulnerabilità da utilizzare tramite la variabile d'ambiente `SCANNERS_LIST`, separati da uno spazio (ad esempio `SCANNERS_LIST="<Scanner1 name> <Scanner2 name>"`)```
SCANNERS_LIST="grype trivy" kubeclarity-cli scan nginx.sbom --input-type sbom
Per esportare i risultati della CLI verso il backend KubeClarity, è necessario utilizzare un ID applicazione come definito dal backend KubeClarity. L'ID applicazione può essere trovato nella schermata Applicazioni dell'interfaccia utente o utilizzando l'API KubeClarity.
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
#### Esportazione dei risultati della scansione delle vulnerabilità```
# 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
## Scansione delle vulnerabilità utilizzando un'immagine docker locale come input```
# Local docker images can be scanned using the LOCAL_IMAGE_SCAN env variable
# For example:
LOCAL_IMAGE_SCAN=true kubeclarity-cli scan nginx.sbom
La CLI di KubeClarity può leggere un file di configurazione che memorizza le credenziali per i registry privati.
Esempio di sezione registry del file di configurazione:``` registry: auths: - authority: <registry 1> username: <username for registry 1> password: <password for registry 1> - authority: <registry 2> token: <token for registry 2>
Esempio di configurazione del registro senza autorità: (in questo caso queste credenziali saranno utilizzate per tutti i registri)```
registry:
auths:
- username: <username>
password: <password>
--config command line flag.kubeclarity scan registry/nginx:private --config $HOME/own-kubeclarity-config
## Supporto per registri privati per scansione runtime K8s
Kubeclarity utilizza [k8schain](https://github.com/google/go-containerregistry/tree/main/pkg/authn/k8schain#k8schain) di google/go-containerregistry per l'autenticazione ai registri.
Se le credenziali di servizio necessarie non sono individuabili da k8schain, possono essere definite tramite i segreti descritti di seguito.
Inoltre, se le credenziali del servizio non si trovano nel namespace "kubeclarity", impostare CREDS_SECRET_NAMESPACE nel Deployment di kubeclarity.
Quando si utilizzano i [charts](https://github.com/openclarity/kubeclarity/blob/main/charts) di Helm, CREDS_SECRET_NAMESPACE è impostato al namespace di rilascio in cui è installato kubeclarity.
### Amazon ECR
Crea un [utente IAM AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console) con autorizzazioni `AmazonEC2ContainerRegistryFullAccess`.
Utilizza le credenziali dell'utente (`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_DEFAULT_REGION`) per creare il seguente segreto:```
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
Nota:
ecr-saAWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY e AWS_DEFAULT_REGIONCrea un account di servizio Google con autorizzazioni Artifact Registry Reader.
Utilizza il file json dell'account di servizio per creare il seguente segreto``` kubectl -n kubeclarity create secret generic --from-file=sa.json gcr-sa
Nota:
1. Il nome del segreto deve essere `gcr-sa`
1. `sa.json` deve essere il nome del file json dell'account di servizio quando si genera il segreto
2. KubeClarity utilizza le [credenziali predefinite dell'applicazione](https://developers.google.com/identity/protocols/application-default-credentials). Queste funzionano solo quando si esegue KubeClarity da GCP.
## Unione di SBOM e vulnerabilità tra diverse fasi CI/CD```
# 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
Il comando kubeclarity-cli analyze può formattare l'SBOM risultante in diversi formati, se necessario, per integrarsi con un altro sistema. I formati supportati sono:
| Formato | Nome Configurazione |
|---|---|
| CycloneDX JSON (predefinito) | cyclonedx-json |
| CycloneDX XML | cyclonedx-xml |
| SPDX JSON | spdx-json |
| SPDX Tag Value | spdx-tv |
| Syft JSON | syft-json |
AVVERTENZA
KubeClarity elabora CycloneDX internamente, gli altri formati sono supportati tramite una conversione. Il processo di conversione può essere con perdita a causa di incompatibilità tra i formati, pertanto non è garantito che tutti i campi/informazioni siano presenti nell'output risultante.
Per configurare kubeclarity-cli per utilizzare un formato diverso da quello predefinito, è possibile utilizzare la variabile d'ambiente ANALYZER_OUTPUT_FORMAT con il nome della configurazione sopra indicato:``` ANALYZER_OUTPUT_FORMAT="spdx-json" kubeclarity-cli analyze nginx:latest -o nginx.sbom
## Server scanner remoti per CLI
Quando si esegue il CLI di kubeclarity per la scansione delle vulnerabilità, il CLI dovrà scaricare i relativi database delle vulnerabilità nella posizione in cui è in esecuzione il CLI di kubeclarity. Eseguire il CLI in una pipeline CI/CD comporterà il download dei database ad ogni esecuzione, sprechando tempo e larghezza di banda. Per questo motivo, molti degli scanner supportati dispongono di una modalità remota in cui un server è responsabile della gestione dei database e, eventualmente, della scansione degli artefatti.
> ***Nota***
>
> Gli esempi seguenti riguardano ciascuno scanner, ma possono essere combinati per funzionare insieme come nella modalità non remota.
### Trivy
Lo scanner Trivy supporta la modalità remota utilizzando il server Trivy. Il server Trivy può essere distribuito come documentato qui: [trivy client-server mode](https://aquasecurity.github.io/trivy/v0.34/docs/references/modes/client-server/). Le istruzioni per installare il CLI Trivy sono disponibili qui: [trivy install](https://aquasecurity.github.io/trivy/v0.34/getting-started/installation/). Il team Aqua fornisce un'immagine contenitore ufficiale che può essere utilizzata per eseguire il server in kubernetes/docker, che useremo negli esempi qui.
Per avviare il server:```
docker run -p 8080:8080 --rm aquasec/trivy:0.41.0 server --listen 0.0.0.0:8080
Per eseguire una scansione utilizzando il server:``` SCANNERS_LIST="trivy" SCANNER_TRIVY_SERVER_ADDRESS="http://:8080" ./kubeclarity_cli scan --input-type sbom nginx.sbom
Il server trivy fornisce anche l'autenticazione basata su token per prevenire
l'uso non autorizzato di un'istanza del server trivy. È possibile abilitarla eseguendo il
server con il flag aggiuntivo:```
docker run -p 8080:8080 --rm aquasec/trivy:0.41.0 server --listen 0.0.0.0:8080 --token mytoken
e passando il token allo scanner:``` SCANNERS_LIST="trivy" SCANNER_TRIVY_SERVER_ADDRESS="http://:8080" SCANNER_TRIVY_SERVER_TOKEN="mytoken" ./kubeclarity_cli scan --input-type sbom nginx.sbom
### Grype
Grype supporta la modalità remota utilizzando [grype-server](https://github.com/portshift/grype-server) un wrapper RESTful per grype che fornisce un'API che riceve un SBOM e restituisce i risultati della scansione grype per quel SBOM. Grype-server viene fornito come immagine container, quindi può essere eseguito in kubernetes o tramite docker standalone.
Per avviare il server:```
docker run -p 9991:9991 --rm gcr.io/eticloud/k8sec/grype-server:v0.1.5
Per eseguire una scansione utilizzando il server:``` 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
Se il server Grype è distribuito con TLS puoi sovrascrivere lo schema URL predefinito come:```
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
Vedi la configurazione di esempio qui
Le pull request e le segnalazioni di bug sono benvenute.
Per modifiche più grandi, crea prima un Issue su GitHub per discutere le modifiche proposte e le possibili implicazioni.
Per ulteriori dettagli, consulta le linee guida per i contributi di questo progetto