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
helmbereitgestellt wird. - Python-compliance-App: Dieses Repository enthält einen Python-Mikroservice, der Flask verwendet und mit
helmbereitgestellt wird. - Node-cloudant-compliance-app: Dieses Repository enthält eine Node.js-Anwendung, die mit
kubectlbereitgestellt 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.yamlDevSecOps. - 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.jsonist die Kartierung bestimmter Stellen, die bei der Quellcodeprüfung gefunden wurden und verworfen werden können..pipeline-config.yamldie 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 auffalsegesetzt 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
scriptan, 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.yamlhinzu: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.