Portare la propria applicazione in DevSecOps

Esistono vari modi per integrare la propria applicazione in una toolchain di tipo " DevSecOps " per l'integrazione continua e la distribuzione continua.

Utilizzare campioni

Per integrare la vostra applicazione in una toolchain di DevSecOps per un'integrazione e un deployment continui, iniziate con le nostre configurazioni di esempio.

Node.js esempio

Creare la propria catena di strumenti DevSecOps utilizzando l'applicazione di esempio fornita di default. L' hello - compliance - app ospita un server Node.js che fornisce una pagina web statica.

Altri campioni

In alternativa, si può iniziare utilizzando uno di questi campioni:

  • Code-engine-compliance-app: questo repository contiene un'applicazione Node.js che illustra le strategie di compilazione Code Engine e può essere distribuita come applicazione Code Engine o come lavoro Code Engine.
  • Go-compliance-app: questo repository contiene un microservizio Go che utilizza Gin, distribuito utilizzando helm.
  • Python-compliance-app: questo repository contiene un microservizio Python che utilizza Flask, distribuito utilizzando helm.
  • Node-cloudant-compliance-app: questo repository contiene un'applicazione Node.js distribuita usando kubectl, che interagisce con un'istanza Cloudant creata tramite Infrastructure-As-Code (Terraform).

Utilizzare la configurazione dedotta di DevSecOps

Una volta aggiunto il repository del codice sorgente della propria applicazione alla catena di strumenti DevSecOps CI, è possibile utilizzare la funzione di configurazione della pipeline Inferred DevSecOps per iniziare immediatamente. Questa funzione:

  • Non richiede alcuna personalizzazione iniziale.
  • Influenza il contenuto del file di configurazione della pipeline .pipeline-config.yaml DevSecOps.
  • Identifica gli script necessari per costruire, testare e distribuire il codice.
  • Fornisce il codice per questi script.

Utilizzate questa funzione per integrare in modo semplice e rapido i vostri microservizi o le vostre applicazioni nelle pipeline di DevSecOps e per ottimizzare l'adozione di DevSecOps.

Generare il file yaml di configurazione della pipeline CI per un dato repository di codice sorgente (configurazione DevSecOps dedotta in modalità stand-alone)

È possibile generare un file di configurazione della pipeline per un dato repository di codice sorgente in modo statico/stand-alone. Questa funzione si basa sulla stessa logica della configurazione inferita di DevSecOps ed è fornita tramite uno script specifico nell'immagine di base della conformità DevSecOps.

Prerequisiti

  • Avere un motore docker attivo e funzionante sul proprio ambiente locale
  • yq per eseguire i seguenti comandi

Utilizzo

Lo script si trova nel seguente percorso dell'immagine di base della conformità: /opt/one-pipeline/polyglot/tools/enable-devsecops.sh.

L'uso dello script è enable-devsecops.sh [--configuration <key>=value]* [--configuration-file <filename>] [--version <v9|v10|v11>]* <path to source code directory>

I seguenti frammenti illustrano come utilizzare questo script.

# clone the source code repository that you want to generate CI pipeline config for
git clone https://us-south.git.cloud.ibm.com/open-toolchain/hello-containers
cd hello-containers

export compliance_base_image=$(curl -L https://us-south.git.cloud.ibm.com/open-toolchain/compliance-pipelines/-/raw/open-v10/definitions/ci-trigger.yaml?ref_type=heads | yq '.spec.params[] | select(.name == "compliance-baseimage") | .default')

# environment variable compliance_base_image should contains a value like icr.io/continuous-delivery/toolchains/devsecops/devsecops-baseimage:3.109.7_commons-1.50.2 or upper

# define hint for unit-test and acceptance-test configuration properties as the hello-containers
# sample has specific npm script entries for it

docker run --platform linux/amd64 -v.:/src --rm -it $compliance_base_image /opt/one-pipeline/polyglot/tools/enable-devsecops.sh --configuration hint-npm-unit-testing-script=test-unit --configuration hint-npm-acceptance-testing-script=test-fvt /src

È possibile fornire parametri specifici utilizzando le opzioni di --configuration (o --configuration-file <file path> con un file contenente una coppia chiave-valore).

I parametri forniti configurano il processo di estrazione di DevSecOps. I parametri disponibili sono descritti qui: configurazione del punto di estrazione

docker run --platform linux/amd64 -v.:/src --rm -it $compliance_base_image /opt/one-pipeline/polyglot/tools/enable-devsecops.sh --configuration hint-npm-unit-testing-script=test-unit --configuration hint-npm-acceptance-testing-script=test-fvt /src

Risultati

polyglot-spots.json e .pipeline-config.yaml vengono aggiunti alla directory principale del repository del codice sorgente.

  • polyglot-spots.json è la cartografia di punti specifici trovati nell'ispezione del codice sorgente e che possono essere scartati.
  • .pipeline-config.yaml che verrà utilizzato dalla pipeline CI

A questo punto, è possibile eseguire il push di .pipeline-config.yaml sul repository git del codice sorgente e usarlo come repository dell'applicazione, come descritto in Onboarding di un'applicazione.

Aggiunta di parametri dello stage

Il codice sorgente di ciascuna applicazione di esempio contiene un file .pipeline-config.yaml. Il file .pipeline-config.yaml è il file di configurazione core utilizzato da continue e continue toolchain di distribuzione per tutte le fasi del processo di esecuzione della pipeline.

Aggiungere un file di configurazione .pipeline-config.yaml che contenga le seguenti proprietà richieste da ogni fase:

image
Il nome immagine Docker che viene utilizzato per eseguire il stage. Ad esempio, utilizzare il seguente codice per firmare le tue immagini:
image: icr.io/continuous-delivery/pipeline/image-signing:1.0.   0@sha256:e9d8e354668ba3d40be2aaee08298d2aa7f0e1c8a1829cca4094ec93830e3e6a
abort_on_failure

Impostare questa proprietà su true per arrestare l'esecuzione della pipeline se la fase non riesce. Se questa proprietà è impostata su false, il passo viene contrassegnato come passato con uno stato di avvertenza, noto anche come stato ambra, e la pipeline continua l'esecuzione.

script

Lo script che esegue le azioni richieste nella fase. Creare gli script nella directory script all'interno del repository dell'applicazione e richiamare gli script da questa posizione. Ad esempio, il seguente snippet di codice mostra il contenuto della sezione script quando si desidera firmare le immagini:

script: |
   #!/usr/bin/env bash
   STAGE_DIND="true"
   STAGE_ABORT_ON_FAILURE="false"
   STAGE_IMAGE_PULL_POLICY="IfNotPresent"
   source scripts/sign_image.sh
dind

Impostare questa proprietà su true se si desidera abilitare docker funzioni nella pipeline di esecuzione. Dopo aver determinato quali parametri sono richiesti, è possibile definire vari passi nella pipeline.

setup

Definire questa fase per eseguire gli script di pre - setup.

setup:
   image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.      12@sha256:ff4053b0bca784d6d105fee1d008cfb20db206011453071e86b69ca3fde706a4
   script: |
   #!/usr/bin/env bash
   echo "Please insert any required pre-build tasks in this stage."
test

Definire questa fase per eseguire i casi di test dell'app.

test:
   abort_on_failure: false
image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.      12@sha256:ff4053b0bca784d6d105fee1d008cfb20db206011453071e86b69ca3fde706a4
script: |
   #!/usr/bin/env bash
   cd ../"$(load_repo app-repo path)"
   #npm ci
   #npm test
   source test/test.sh
static-scan

Definire questa fase per eseguire una scansione statica sul codice.

static-scan:
   dind: true
   image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.12@sha256:ff4053b0bca784d6d105fee1d008cfb20db206011453071e86b69ca3fde706a4
   script: |
   #!/usr/bin/env bash
   echo "Please insert script to invoke/execute static scan tool like SonarQube on the application source code."
containerize

Definire questa fase per costruire e containerizzare la tua app.

containerize:
   dind: true
   image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.      12@sha256:ff4053b0bca784d6d105fee1d008cfb20db206011453071e86b69ca3fde706a4
   script: |
   #!/usr/bin/env bash

   if [[ "$PIPELINE_DEBUG" == 1 ]]; then
   trap env EXIT
   env
   set -x
   fi
   source scripts/build_setup.sh
   source scripts/build.sh
deploy

Definire questa fase per distribuire la tua app sull'ambiente di destinazione.

deploy:
   image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.      12@sha256:ff4053b0bca784d6d105fee1d008cfb20db206011453071e86b69ca3fde706a4
   script: |
   #!/usr/bin/env bash

   if [[ "$PIPELINE_DEBUG" == 1 ]]; then
   trap env EXIT
   env
   set -x
   fi
   source scripts/deploy_setup.sh
   source scripts/deploy.sh
sign-artifact

Per impostazione predefinita, la catena di strumenti CI DevSecOps firma tutte le immagini costruite durante la fase di containerizzazione. Le chiavi GPG fornite durante la configurazione della toolchain vengono utilizzate per firmare le immagini. Se vuoi personalizzare il processo di firma dell'immagine, aggiungi la seguente definizione di fase nel tuo .pipeline-config.yaml:

sign-artifact:
   abort_on_failure: false
   image: icr.io/continuous-delivery/pipeline/image-signing:1.0.      0@sha256:e9d8e354668ba3d40be2aaee08298d2aa7f0e1c8a1829cca4094ec93830e3e6a
   script: |
   #!/usr/bin/env bash
   STAGE_DIND="true"
   STAGE_ABORT_ON_FAILURE="false"
   STAGE_IMAGE_PULL_POLICY="IfNotPresent"
   source scripts/sign_image.sh
acceptance-test

Definire questa fase per eseguire il test di accettazione dopo la distribuzione.

acceptance-test:
   abort_on_failure: false
   image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.      12@sha256:ff4053b0bca784d6d105fee1d008cfb20db206011453071e86b69ca3fde706a4
   script: |
   #!/usr/bin/env bash
   export APP_URL=$(cat ../app-url)
   source scripts/setup_go.sh
   echo "APP_URL :- ${APP_URL}"
   go run acceptance-test/acceptance-test.test.go
release

Definire questa fase per caricare prove e risorse utente generate dalle fasi precedenti.

release:
   abort_on_failure: false
   image: icr.io/continuous-delivery/toolchains/devsecops/compliance-baseimage:2.26.      1@sha256:a780174a64474187b01b5e40a1721d8307f02897ac6f3eba2d482d4f4926edf1
   script: |
   #!/usr/bin/env bash
   source scripts/release.sh
scan-artifact

Definire questa fase per eseguire una scansione delle vulnerabilità nelle risorse utente generate.

scan-artifact:
   abort_on_failure: false
   image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.      6@sha256:7f588468622a981f89cf5e1212aaf75fface9da6169b5345ca52ab63d8215907
   script: |
   #!/usr/bin/env bash
   source scripts/va_scan.sh
dynamic-scan

Definire questa fase per eseguire la scansione dinamica sull'applicazione distribuita.

dynamic-scan:
   dind: true
   abort_on_failure: false
   image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.12@sha256:ff4053b0bca784d6d105fee1d008cfb20db206011453071e86b69ca3fde706a4
   script: |
   #!/usr/bin/env bash
   echo "Please insert script to invoke/execute dynamic scan tool like OWASP ZAP on the built and deployed application."

Per ulteriori informazioni sulle fasi, consultare Script personalizzati.