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.yamlDevSecOps. - 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.jsonest la cartographie des points spécifiques trouvés lors de l'inspection du code source et qui peuvent être éliminés..pipeline-config.yamlqui 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 surfalse, 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
scriptlorsque 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'dockers 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.