Eigene App zu DevSecOps mitbringen

Es gibt verschiedene Möglichkeiten, Ihre eigene Anwendung in eine „ DevSecOps ”-Toolchain für kontinuierliche Integration und kontinuierliche Bereitstellung zu integrieren.

Verwendung von Proben

Um Ihre eigene Anwendung in eine DevSecOps-Toolchain für eine nahtlose kontinuierliche Integration und Bereitstellung zu integrieren, beginnen Sie mit unseren Beispiel-Setups.

Node.js Beispiel

Erstellen Sie Ihre DevSecOps-Toolchain unter Verwendung der bereitgestellten Standard-Beispielanwendung. Die hello-compliance-app hostet einen Node.js-Server, der eine statische Webseite bereitstellt.

Weitere Beispiele

Alternativ können Sie mit einem dieser Beispiele beginnen:

  • Code-engine-compliance-app: Dieses Repository enthält eine Node.js-Anwendung, die Code Engine-Erstellungsstrategien veranschaulicht und als Code Engine-Anwendung oder Code Engine-Job bereitgestellt werden kann.
  • Go-Compliance-App: Dieses Repository enthält einen Go-Mikrodienst, der Gin verwendet und über helm bereitgestellt wird.
  • Python-compliance-App: Dieses Repository enthält einen Python-Mikroservice, der Flask verwendet und mit helm bereitgestellt wird.
  • Node-cloudant-compliance-app: Dieses Repository enthält eine Node.js-Anwendung, die mit kubectl bereitgestellt wird und mit einer Cloudant-Instanz interagiert, die über Infrastructure-As-Code (Terraform) erstellt wurde.

Verwenden Sie die abgeleitete DevSecOps-Konfiguration

Sobald Sie Ihr eigenes Repository für Anwendungsquellcode zur CI-Toolchain von DevSecOps hinzugefügt haben, können Sie die Funktion "Inferred DevSecOps Pipeline Configuration" verwenden, um sofort loszulegen. Diese Funktion:

  • Erfordert keine anfängliche Anpassung.
  • Ermittelt den Inhalt der Pipeline-Konfigurationsdatei .pipeline-config.yaml DevSecOps.
  • Identifiziert die Skripte, die zum Erstellen, Testen und Bereitstellen des Codes benötigt werden.
  • Stellt den Code für diese Skripte bereit.

Verwenden Sie diese Funktion, um Ihre Mikrodienste oder Anwendungen einfach und schnell in DevSecOps-Pipelines einzubinden und die Einführung von DevSecOps zu optimieren.

Generierung einer CI-Pipeline-Konfigurations-Yaml-Datei für ein bestimmtes Quellcode-Repository (abgeleitete DevSecOps-Konfiguration im Standalone-Modus)

Sie können eine Pipeline-Konfigurationsdatei für ein bestimmtes Quellcode-Repository auf statische Weise/im Standalone-Modus erzeugen. Diese Funktion basiert auf der gleichen Logik wie die abgeleitete DevSecOps Konfiguration und wird durch ein spezielles Skript im DevSecOps compliance base image bereitgestellt.

Voraussetzungen

  • Eine Docker-Engine in Ihrer lokalen Umgebung einrichten und ausführen
  • yq, um die folgenden Befehle auszuführen

Verwendung

Das Skript befindet sich unter folgendem Pfad im Compliance-Basis-Image: /opt/one-pipeline/polyglot/tools/enable-devsecops.sh.

Die Verwendung des Skripts lautet enable-devsecops.sh [--configuration <key>=value]* [--configuration-file <filename>] [--version <v9|v10|v11>]* <path to source code directory>

Die folgenden Ausschnitte veranschaulichen, wie dieses Skript zu verwenden ist.

# 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

Sie können spezifische Parameter mit Hilfe der Optionen --configuration (oder --configuration-file <file path> mit einer Datei mit einem Schlüssel-Wert-Paar) angeben.

Mit den angegebenen Parametern wird der Extraktionsprozess DevSecOps konfiguriert. Die verfügbaren Parameter werden hier beschrieben: Konfiguration des Extraktionspunkts

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

Ergebnisse

polyglot-spots.json und .pipeline-config.yaml Dateien werden dem Stammverzeichnis des Quellcode-Repositorys hinzugefügt.

  • polyglot-spots.json ist die Kartierung bestimmter Stellen, die bei der Quellcodeprüfung gefunden wurden und verworfen werden können.
  • .pipeline-config.yaml die von der CI-Pipeline verwendet werden sollen

Sie können nun die .pipeline-config.yaml in das Git-Repository für den Quellcode pushen und es als Anwendungs-Repository verwenden, wie in Onboarding einer Anwendung beschrieben.

Phasenparameter hinzufügen

Der Quellcode jeder Beispiel-App enthält eine Datei namens „ .pipeline-config.yaml “. Die Datei „ .pipeline-config.yaml “ ist die zentrale Konfigurationsdatei, die von Toolchains für kontinuierliche Integration und kontinuierliche Bereitstellung für alle Phasen des Pipeline-Ausführungsprozesses verwendet wird.

Fügen Sie eine Konfigurationsdatei vom Typ .pipeline-config.yaml hinzu, in der die folgenden Eigenschaften enthalten sind, die für jede Stage erforderlich sind:

image
Der Name des „ Docker “-Images, das zum Ausführen der Stufe verwendet wird. Verwenden Sie beispielsweise den folgenden Code zum Signieren Ihrer Images:
image: icr.io/continuous-delivery/pipeline/image-signing:1.0.   0@sha256:e9d8e354668ba3d40be2aaee08298d2aa7f0e1c8a1829cca4094ec93830e3e6a
abort_on_failure

Setzen Sie diese Eigenschaft auf „ true “, um den Pipeline-Lauf zu stoppen, falls die Stufe fehlschlägt. Wenn diese Eigenschaft auf false gesetzt ist, wird der Schritt als erfolgreich mit einem Warnstatus markiert, der auch als bernsteinfarben bezeichnet wird, und die Pipeline wird weiter ausgeführt.

script

Das Skript, das die in dieser Phase erforderlichen Aktionen ausführt. Erstellen Sie die Skripte im Skriptverzeichnis innerhalb des App-Repositorys und rufen Sie die Skripte von diesem Speicherort aus auf. Das folgende Code-Snippet zeigt als Beispiel den Inhalt des Abschnitts script an, wenn Sie die Images signieren möchten:

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

Setzen Sie diese Eigenschaft auf „ true “, wenn Sie die Funktionen von „ docker “ in der laufenden Pipeline aktivieren möchten. Nachdem Sie festgelegt haben, welche Parameter erforderlich sind, können Sie verschiedene Schritte in der Pipeline definieren.

setup

Definieren Sie diese Phase, um die Vorbereitungsskripte auszuführen.

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

Definieren Sie diese Phase, um die Testfälle der App auszuführen.

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

Definieren Sie diese Phase, um einen statischen Scan für den Code auszuführen.

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

Definieren Sie diese Phase, um Ihre App zu erstellen und zu containerisieren.

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

Definieren Sie diesen Schritt, um Ihre App in der Zielumgebung bereitzustellen.

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

Standardmäßig signiert die DevSecOps CI-Toolchain alle Images, die während der Containerisierungsphase erstellt werden. GPG-Schlüssel, die beim Einrichten der Toolchain bereitgestellt werden, werden zum Signieren der Images verwendet. Wenn Sie den Imagesignierungsprozess anpassen möchten, fügen Sie die folgende Phasendefinition zu .pipeline-config.yaml hinzu:

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

Legen Sie diese Phase fest, damit Ihr Abnahmetest nach der Bereitstellung ausgeführt wird.

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

Legen Sie diese Phase fest, um Belege und Artefakte hochzuladen, die in den vorangegangenen Phasen erstellt wurden.

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

Definieren Sie diese Phase, um einen Scan auf Schwachstellen in den generierten Artefakten auszuführen.

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

Definieren Sie diese Phase, um einen dynamischen Scan für die implementierte Anwendung auszuführen.

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."

Weitere Informationen zu den Stages finden Sie unter Angepasste Scripts.