Utilisation de votre propre application pour DevSecOps

Il existe différentes façons d'intégrer votre propre application à une chaîne d'outils d' DevSecOps pour l' et le déploiement continus.

Utiliser des échantillons

Pour intégrer votre propre application dans une chaîne d'outils DevSecOps en vue d'une intégration et d'un déploiement continus, commencez par utiliser nos exemples de configuration.

Node.js exemple

Créez votre chaîne d'outils DevSecOps en utilisant l'exemple d'application par défaut qui est fourni. hello-compliance-app héberge un serveur Node.js qui fournit une page Web statique.

Autres échantillons

Vous pouvez également commencer par utiliser l'un de ces échantillons :

  • Code-engine-compliance-app: ce dépôt contient une application Node.js qui illustre les stratégies de construction Code Engine et peut être déployée en tant qu'application Code Engine ou tâche Code Engine.
  • Go-compliance-app: ce dépôt contient un microservice Go utilisant Gin, déployé à l'aide de helm.
  • Python-compliance-app: ce dépôt contient un microservice Python utilisant Flask, déployé avec helm.
  • Node-cloudant-compliance-app: ce référentiel contient une application Node.js déployée à l'aide de kubectl, qui interagit avec une instance Cloudant créée via Infrastructure-As-Code (Terraform).

Utiliser la configuration déduite de DevSecOps

Une fois que vous avez ajouté votre propre dépôt de code source d'application à la chaîne d'outils CI DevSecOps, vous pouvez utiliser la fonction de configuration du pipeline DevSecOps pour commencer immédiatement. Cette fonction :

  • Ne nécessite pas de personnalisation initiale.
  • Infère le contenu du fichier de configuration du pipeline .pipeline-config.yaml DevSecOps.
  • Identifie les scripts nécessaires pour construire, tester et déployer le code.
  • Fournit le code de ces scripts.

Utilisez cette fonctionnalité pour intégrer facilement et rapidement vos micro-services ou applications aux pipelines DevSecOps et rationaliser l'adoption de DevSecOps.

Générer un fichier yaml de configuration du pipeline CI pour un dépôt de code source donné (configuration déduite de DevSecOps en mode autonome)

Vous pouvez générer un fichier de configuration de pipeline pour un dépôt de code source donné de manière statique/en mode autonome. Cette fonctionnalité repose sur la même logique que la configuration déduite de DevSecOps et est fournie par un script spécifique dans l'image de base de conformité de DevSecOps.

Prérequis

  • Disposer d'un moteur Docker opérationnel dans votre environnement local
  • yq afin d'exécuter les commandes suivantes

Utilisation

Le script se trouve dans l'image de base de la conformité, au chemin suivant : /opt/one-pipeline/polyglot/tools/enable-devsecops.sh.

L'utilisation du script est la suivante enable-devsecops.sh [--configuration <key>=value]* [--configuration-file <filename>] [--version <v9|v10|v11>]* <path to source code directory>

Les extraits suivants illustrent l'utilisation de ce 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

Vous pouvez fournir des paramètres spécifiques en utilisant les options --configuration (ou --configuration-file <file path> avec un fichier contenant une paire clé-valeur).

Les paramètres fournis configureront le processus d'extraction de DevSecOps. Les paramètres disponibles sont décrits ici : configuration du spot d'extraction

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

Résultats

polyglot-spots.json et .pipeline-config.yaml sont ajoutés au répertoire racine du dépôt de code source.

  • polyglot-spots.json est la cartographie des points spécifiques trouvés lors de l'inspection du code source et qui peuvent être éliminés.
  • .pipeline-config.yaml qui sera utilisé par le pipeline CI

Vous pouvez maintenant pousser le site .pipeline-config.yaml vers le dépôt git du code source et l'utiliser comme dépôt de l'application comme décrit dans Onboarding an application.

Ajout de paramètres d'étape

Le code source de chaque application d'exemple contient un fichier « .pipeline-config.yaml ». Le fichier .pipeline-config.yaml est le fichier de configuration principal utilisé par les chaînes d'outils d'intégration continue et de déploiement continu pour toutes les étapes du processus d'exécution du pipeline.

Ajoutez un fichier de configuration .pipeline-config.yaml contenant les propriétés suivantes requises par chaque étape :

image
Le nom de l'image « Docker » utilisé pour exécuter l'étape. Par exemple, utilisez le code suivant pour signer vos images :
image: icr.io/continuous-delivery/pipeline/image-signing:1.0.   0@sha256:e9d8e354668ba3d40be2aaee08298d2aa7f0e1c8a1829cca4094ec93830e3e6a
abort_on_failure

Définissez cette propriété sur « true » pour interrompre l'exécution du pipeline en cas d'échec d'une étape. Si cette propriété est définie sur false, l'étape est marquée comme transmise avec un état d'avertissement, également appelé état ambre, et le pipeline continue de s'exécuter.

script

Le script qui exécute les actions requises au cours de cette étape. Créez les scripts dans le répertoire « script » du référentiel de l'application, puis exécutez-les à partir de cet emplacement. Par exemple, le fragment de code suivant illustre le contenu de la section script lorsque vous souhaitez signer les images :

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

Définissez cette propriété sur « true » si vous souhaitez activer les fonctions d' docker s dans le pipeline en cours d'exécution. Une fois que vous avez déterminé les paramètres requis, vous pouvez définir les différentes étapes du pipeline.

setup

Définissez cette étape pour exécuter les scripts de préconfiguration.

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

Définissez cette étape pour exécuter les cas de test de l'application.

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

Définissez cette étape pour exécuter un examen statique sur le code.

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

Définissez cette étape pour compiler et conteneuriser votre application.

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

Définissez cette étape pour déployer votre application dans l'environnement cible.

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

Par défaut, la DevSecOps CI toolchain signe toutes les images qui sont construites pendant l'étape de conteneurisation. Les clés GPG fournies lors de la configuration de la chaîne d'outils sont utilisées pour signer les images. Si vous souhaitez personnaliser le processus de signature d'image, ajoutez la définition d'étape suivante dans votre .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

Définissez cette étape pour exécuter votre test de réception après le déploiement.

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

Définissez cette étape pour télécharger les éléments de preuve et les pièces à conviction issus des étapes précédentes.

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

Définissez cette étape pour exécuter une analyse des vulnérabilités dans les artefacts générés.

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

Définissez cette étape pour exécuter l'analyse dynamique sur l'application déployée.

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

Pour plus d'informations sur les étapes, voir Scripts personnalisés.