Come le pipeline DevSecOps utilizzano i repository

Per costruire, testare e distribuire l'applicazione, le pipeline DevSecOps utilizzano due repository:

• app-repo: il repository dell'applicazione, che contiene il codice origine per l'applicazione.
• config-repo: il repository di configurazione, che contiene gli script e i file YAML di configurazione della pipeline.

Nell'applicazione di esempioDevSecOps, questi due repository sono gli stessi. La maggior parte di coloro che adottano DevSecOps inizia con questo modello. Ma, man mano che si onboarding di più microservizi, potrebbe essere necessario un repository di configurazione della pipeline separato e dedicato. Poiché il repository dell'applicazione e il repository di configurazione sono gli stessi nell'app di esempio, il repository viene clonato due volte quando vengono eseguite le pipeline, il che può causare errori. Pertanto, è una buona pratica avere un repository di configurazione separato per ospitare file di configurazione e script che possono essere condivisi e riutilizzati tra diverse toolchain e pipeline DevSecOps. Per ulteriori informazioni sulla personalizzazione del repository di configurazione, consultare la procedura di personalizzazione avanzata.

DevSecOps gli script considerano app-repo e config-repo come due archivi separati. Gli script clonano due volte i repository durante la fase iniziale della pipeline. Questi cloni vengono indicati come app-repo e one-pipeline-config-repo. Ogni fase viene eseguita nel contesto di config repo.

Opzione 1: aggiungi il tuo repository dell'applicazione e utilizza il repository dell'applicazione di esempio come repository di configurazione

Per aggiungere il repository dell'applicazione alla toolchain e utilizzare il repository dell'applicazione di esempio come repository di configurazione, completare la seguente procedura:

1. Nella console IBM Cloud, fare clic sull'icona Menu > Automazione piattaforma > Catene di strumenti e selezionare la catena di strumenti che si desidera modificare.
2. Fai clic su Aggiungi.
3. Seleziona dove è ospitato il tuo repository dell'applicazione, Gitlab o GitHub.
4. Utilizzare il server predefinito o aggiungerne uno nuovo.
5. Inserisci l' URL e del server personalizzato e il token di accesso personale.
6. Fai clic su Crea integrazione.
7. Inserisci il tuo repository del codice sorgente dell'applicazione URL.
8. Fai clic su Crea integrazione.

Successivamente, specifica il repository dell'applicazione di esempio come tuo repository di configurazione completando la seguente procedura:

1. Nella console IBM Cloud, fare clic sull'icona Menu > Automazione piattaforma > Catene di strumenti e selezionare la catena di strumenti che si desidera modificare.
2. Fare clic su pr - pipeline.
3. Fare clic su Impostazioni e andare alla scheda Proprietà dell'ambiente.
4. Modificare il valore della proprietà " pipeline-config-repo " in modo che punti all'archivio dell'applicazione di esempio URL.
5. Tornare alla toolchain CI.
6. Fare clic su ci - pipeline.
7. Fare clic su Impostazioni e andare alla scheda Proprietà dell'ambiente.
8. Modificare il valore della proprietà " pipeline-config-repo " in modo che punti all'archivio dell'applicazione di esempio URL.

Le tue pipeline CI ora utilizzano il repository dell'applicazione di esempio pipeline-config come tuo repository di configurazione.

Opzione 2: sostituire il repository dell'applicazione di esempio con il proprio repository dell'applicazione

Per sostituire il repository dell'applicazione di esempio con il tuo repository dell'applicazione, completa la seguente procedura:

1. Nella console IBM Cloud, fare clic sull'icona Menu > Automazione piattaforma > Catene di strumenti e selezionare la catena di strumenti CI che si desidera modificare.
2. Individuare il repository del codice origine dell'applicazione di esempio e selezionare Configura.
3. Sostituisci il repository URL con il repository del codice sorgente dell'applicazione URL.
4. Fai clic su Salva integrazione.

Dopo aver sostituito il repository dell'applicazione di esempio, assicurati che il nuovo repository dell'applicazione contenga un file .pipeline-config.yaml e gli script corrispondenti. Copiare il file .pipeline-config.yaml e gli script dal repository dell'applicazione di esempio al repository dell'applicazione oppure utilizzare questo file di configurazione di esempio.

Configurazione delle pipeline CI

Dopo aver aggiunto il repository dell'applicazione, è necessario configurare le pipeline CI per utilizzare il nuovo repository.

Utilizzo di script personalizzati con DevSecOps

Il file 'pipeline-config.yaml è il componente chiave che orchestra e personalizza il comportamento della pipeline DevSecOps. Il file utilizza script per creare, verificare e distribuire l'applicazione. Il file definisce come sono configurati gli stage e quali script vengono eseguiti. Per ulteriori informazioni, consultare Script personalizzati.

Esistono due categorie principali di script utilizzati dalle pipeline DevSecOps:

• Script relativi all'applicazione utilizzati per creare, verificare e distribuire l'applicazione. Questi script sono sotto la vostra responsabilità e non rientrano nell'ambito del supporto DevSecOps. Poiché questi script non hanno un'implementazione predefinita, è necessario aggiungerli all'applicazione o al repository di configurazione. Potrebbe essere necessario estrarre gli script da Jenkins o da un'altra origine.
• Script di sicurezza e conformità che eseguono scansioni di sicurezza e conformità. La maggior parte viene con gli script predefiniti che è possibile sovrascrivere per utilizzare la propria implementazione personalizzata.

Ad eccezione della fase iniziale, ogni fase di una pipeline CI, CD o CC può essere personalizzata con i propri script per sovrascrivere l'implementazione predefinita della fase. La fase iniziale non può essere personalizzata con i propri script.

Sebbene gli script Bash siano forniti come esempi, puoi creare, verificare e distribuire la tua applicazione utilizzando altri linguaggi come Python o Go. Assicurati di utilizzare il image corretto per ogni fase. Fare riferimento alle immaginiDocker nella sezione pipeline DevSecOps.

Fare riferimento alla tabella Fasi e attività che riepiloga le diverse fasi della pipeline CI. La tabella fornisce inoltre informazioni consolidate che indicano se lo stage dispone di un'implementazione di riferimento predefinita, se può essere personalizzato o ignorato o se è presente una raccolta di prove esplicita richiesta dall'esecuzione dello stage.

Configurazione della pipeline CD

Nel flusso di lavoroDevSecOps di integrazione e distribuzione continua, la pipeline CI invia gli aggiornamenti al repository dell'inventario durante la fase " deploy-release della pipeline CI. Per ulteriori informazioni, vedi lo script release.sh di esempio.

In questo flusso di lavoro, più trigger CI e diverse toolchain DevSecOps CI possono contribuire allo stesso repository di inventario.

Contrariamente alla pipeline CI, lo script di distribuzione utilizzato dalla pipeline CD deve essere adattato dai tuoi script correnti in Jenkins, Travis o in qualche altra piattaforma per utilizzare le voci nel repository di inventario.

Questo codice di esempio mostra come richiamare le informazioni dall'inventario e utilizzarle per eseguire una distribuzione Kubernetes.

Posizione degli script DevSecOps

Le pipeline DevSecOps sono dotate di strumenti di sicurezza e di scansione predefiniti e di script associati.

Ad esempio, l'inizio di un log dello stage fa riferimento allo script predefinito:

scan-artifact:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.24
  dind: true
  dind_image: icr.io/continuous-delivery/toolchains/devsecops/docker:20.10.21-dind
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script: |
    #!/bin/sh

    "/opt/commons/scan-artifact/scan.sh"

/opt/commons/scan-artifact/scan.sh è lo script predefinito.

La pipeline DevSecOps fornisce il percorso della cartella principale della libreria commons in una variabile d'ambiente chiamata " COMMONS_PATH, disponibile in tutti i task e le fasi. Per accedere a uno script creato nell'immagine base di conformità, utilizzare la variabile COMMONS_PATH con la cartella di script necessaria:

source "${COMMONS_PATH}/<script folder in commons>/<script file name>

Fare riferimento alla tabella Fasi e attività che riepiloga le varie fasi della pipeline CD. La tabella fornisce inoltre informazioni consolidate che indicano se lo stage ha un'implementazione di riferimento predefinita, se può essere personalizzata o ignorata o se è richiesta una raccolta di prove esplicite dall'esecuzione dello stage.

Proprietà ambiente

Le pipeline DevSecOps sono dotate di proprietà dell'ambiente predefinite, ma è possibile aggiungere tutte le proprietà personalizzate necessarie. È possibile accedere a questi valori di proprietà negli script utilizzando get_env, comando.

Dopo aver aggiunto la tua proprietà e il suo valore predefinito facoltativo alla pipeline o al trigger, utilizza il comando get_env nel tuo script per recuperare il valore della proprietà. Il seguente esempio richiama il valore della proprietà my-variable:

MY_VARIABLE=$(get_env my-variable "")

È anche possibile sovrascrivere dinamicamente il valore di una proprietà in uno script utilizzando set_env, comando. Il seguente esempio sovrascrive il valore nella proprietà my-variable:

set_env my-variable new-value

Fasi ignorate

Alcune fasi potrebbero essere irrilevanti. Ad esempio, potresti non creare alcuna immagine Docker oppure non hai ancora implementato i test di accettazione. Se si desidera ignorare uno stage, è possibile modificare il file .pipeline-config.yaml per includere exit 0 o impostare la variabile skip su true.

Il seguente esempio aggiunge exit 0 per ignorare una fase:

scan-artifact:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.24
  dind: true
  dind_image: icr.io/continuous-delivery/toolchains/devsecops/docker:20.10.21-dind
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  skip: false
  runAfter: null
  script: |
    #!/bin/sh

    exit 0
    "/opt/commons/scan-artifact/scan.sh"

Immagini Docker nelle pipeline DevSecOps

Per impostazione predefinita, le pipeline DevSecOps utilizzano IBM Immagini di Continuous Delivery. Queste immagini contengono alcuni degli strumenti più comuni come Node e Java per eseguire gli script. È anche possibile utilizzare le immagini di altri fornitori o le proprie immagini personalizzate che contengono gli strumenti preferiti.

Le immagini Docker utilizzate dalle pipeline DevSecOps sono specificate nel file '.pipeline-config.yaml. Ogni stage può utilizzare un'immagine differente.

scan-artifact:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.24
  dind: true
  dind_image: icr.io/continuous-delivery/toolchains/devsecops/docker:20.10.21-dind
(...)