Tipi di attività comuni

Le attività possono assumere diverse forme nella vostra pipeline:

• Impegni sul codice sorgente- Il codice che viene costruito e testato
• Immagini del contenitore- Docker immagini prodotte dalle vostre compilazioni
• Artefatti di distribuzione- manifesti Kubernetes, grafici Helm o file di configurazione
• Esecuzione della pipeline- L'esecuzione della pipeline stessa

Il diagramma seguente mostra i vari tipi di asset supportati in DevSecOps:

Come identificare le attività

Ogni bene deve essere identificato in modo univoco e immutabile. Questo assicura che le prove raccolte per un asset si riferiscano sempre allo stesso esatto artefatto, anche se la pipeline viene eseguita più volte.

Formati di identificazione dei beni:

• Commit Asset: repository e hash del commit

  https://repo.url/org/repo#<COMMIT-SHA>
  

• Asset immagine: Docker immagine e relativo digest

  docker://registry.URL/name@sha256:<SHA256-DIGEST>
  

• Asset della corsa della pipeline: ID della pipeline e della corsa

  pipelinerun://<PIPELINE_ID>/<RUN_ID>
  

• Altre attività: Esempi completamente qualificati URL

  • Impegnare l'asset con il nome del file (helm chart o file di configurazione):

    https://repo.url/org/repo#<COMMIT-SHA>/<filename>
    

  • Bene artefatto:

    <artifactory-url>/artifact.<filetype>
    

Usare identificatori immutabili (SHA dei commit, image digest) piuttosto che etichette mutabili (tag, branch) per garantire che le prove facciano sempre riferimento alla versione esatta dell'artefatto.

Salvare le informazioni sul repository

Quando la pipeline controlla il codice sorgente, si usa il comando save_repo per registrare i dettagli del repository. Questo associa gli artefatti di compilazione allo specifico commit che li ha prodotti.

Esempio:

save_repo app-repo \
  url=<app_url> \
  path=my-app \
  commit=commit1 \
  branch=master \
  buildnumber=1

Salvare le informazioni sull'artefatto

Dopo aver creato gli artefatti (immagini, file di distribuzione, ecc.), usare il comando save_artifact per registrarne i dettagli. Questo cattura il nome, il tipo, il digest e la provenienza dell'artefatto.

Quando usarlo:

• Dopo aver creato un'immagine Docker
• Dopo aver generato i manifesti di distribuzione
• Dopo aver creato qualsiasi artefatto che verrà distribuito

Esempio: Salvataggio di un'immagine Docker

Dopo che la pipeline ha creato e inviato un'immagine Docker:

save_artifact app-image \
  name=us.icr.io/my-registry/my-app:20230828074614-master-commit-1@sha256:sha2561 \
  type=image \
  digest=sha256:sha2561 \
  tags=mytag1 \
  source=<source_url> \
  signature=sign-1 \
  provenance=us.icr.io/my-registry/my-app:20230828074614-master-commit-1@sha256:sha2561

Esempio: Salvataggio di un artefatto di distribuzione

Per gli artefatti non legati all'immagine, come i manifesti di Kubernetes o i grafici di Helm:

save_artifact artifact-1 \
  name=my-app_IKS_deployment \
  type=deployment \
  signature=sign2 \
  deployment_type=IKS \
  provenance=<url>

Comprendere i parametri dell'inventario

Utilizzare il comando cocoa inventory add con i seguenti parametri:

Creazione di voci di inventario

Gli esempi seguenti mostrano come creare voci di inventario per diversi tipi di beni. Si noti come i parametri corrispondano alle informazioni salvate in precedenza con save_artifact.

Esempio: Registrazione di un'immagine Docker nell'inventario

Questo esempio crea una voce di inventario per l'immagine Docker salvata in precedenza:

cocoa inventory add \
  --artifact=us.icr.io/my-registry/my-app:20230828074614-master-commit-1@sha256:sha2561 \
  --name=my-app \
  --app-artifacts='{ "app": "my-app", "tags": "20230828074614-master-commit1" }' \
  --signature=sign1 \
  --provenance=us.icr.io/my-registry/my-app:20230828074614-master-commit-1@sha256:sha2561 \
  --sha256=sha256:sha2561 \
  --type=image \
  --repository-url=<repo_url> \
  --commit-sha=commit1 \
  --version=commit1 \
  --build-number=1 \
  --pipeline-run-id=pipeline-run-1 \
  --org=Org \
  --repo=my-inventory-20230421184544472 \
  --git-provider=github \
  --git-token-path=./inventory-token \
  --git-api-url=<api_url>

Esempio: Registrazione di un artefatto di distribuzione nell'inventario

Per gli artefatti di distribuzione, il processo è simile ma utilizza il tipo deployment:

cocoa inventory add \
  --artifact=my-app_IKS_deployment \
  --name=my-app_IKS_deployment \
  --app-artifacts='{ "app": "my-app", "tags": "20230828074614-master-commit1" }' \
  --signature=sign2 \
  --provenance=<provenance_url> \
  --sha256=sha256:sha2562 \
  --type=deployment \
  --repository-url=<repo_url> \
  --commit-sha=commit1 \
  --version=commit1 \
  --build-number=1 \
  --pipeline-run-id=pipeline-run-1 \
  --org=Org \
  --repo=my-inventory-20230421184544472 \
  --git-provider=github \
  --git-token-path=./inventory-token \
  --git-api-url=<api_url>

Raccolta di prove per i beni

Utilizzare il comando collect-evidence dopo ogni scansione o test. Il parametro asset-key deve corrispondere alla chiave utilizzata quando si salva l'asset con save_artifact o save_repo. Per informazioni dettagliate sul comando collect-evidence, compresi tutti i parametri, i formati degli strumenti supportati e l'uso della CLI, vedere lo script collect-evidence.

Esempio: Raccolta di prove per i test sul codice sorgente

Per i test eseguiti sul repository del codice sorgente:

collect-evidence \
  --tool-type "jest" \
  --status "success" \
  --evidence-type "com.ibm.unit_tests" \
  --asset-type "repo" \
  --asset-key "repo-1"

Esempio: Raccolta di prove per i test unitari su un artefatto

Dopo aver eseguito i test di accettazione, raccogliere le prove sugli artefatti:

collect-evidence \
  --tool-type "jest" \
  --status "success" \
  --evidence-type "com.ibm.acceptance_tests" \
  --asset-type "artifact" \
  --asset-key "app-image"

Dopo aver eseguito i test di accettazione, raccogliere prove su più artefatti:

collect-evidence \
  --tool-type "jest" \
  --status "success" \
  --evidence-type "com.ibm.acceptance_tests" \
  --evidence-per-asset \
  --assets "app-image:artifact" \
  --assets "artifact-1:artifact"

Utilizzare identificatori immutabili

Usare sempre gli SHA dei commit e i digest delle immagini piuttosto che i tag o i nomi dei rami. I riferimenti mutabili possono cambiare, interrompendo il legame tra prove e risorse.

Mantenere una denominazione coerente

Mantenere i nomi degli artefatti statici per tutta l'esecuzione della pipeline. Evitate di incorporare valori dinamici come i timestamp nel campo del nome per garantire il corretto tracciamento dei problemi e la chiusura automatica.

Abbinare i tipi di attività

Assicurarsi che il parametro type in cocoa inventory add corrisponda al tipo utilizzato in save_artifact. La mancata corrispondenza dei tipi può causare errori nella raccolta delle prove.

Provenienza di riferimento nelle distribuzioni

Nelle pipeline CD, utilizzare il campo provenance per scaricare gli artefatti piuttosto che il campo artifact. La provenienza URL fornisce la posizione completa e immutabile dell'artefatto.

Riutilizzo delle prove per un'esecuzione ottimizzata della pipeline

Per ottimizzare i tempi di esecuzione della pipeline e l'utilizzo delle risorse, è possibile abilitare il riutilizzo delle prove. Questa funzione consente di saltare le scansioni o i test quando l'asset (artefatto o repo) da analizzare non è cambiato dall'ultima scansione.

Per ulteriori informazioni sul riutilizzo delle evidenze, comprese le condizioni di riutilizzo, i periodi di validità e la configurazione avanzata, vedere Riutilizzo delle evidenze nelle pipeline PR e CI.

Nella pipeline del CD, la distribuzione deve fare riferimento a un campo di provenienza invece che a una risorsa utente per scaricare la risorsa utente