Comment les pipelines DevSecOps utilisent les référentiels

Pour construire, tester et déployer votre application, les pipelines DevSecOps utilisent deux référentiels :

• app-repo: référentiel d'application, qui contient le code source de votre application.
• config-repo: référentiel de configuration, qui contient vos fichiers YAML de configuration de pipeline et vos scripts.

Dans l'exemple d'applicationDevSecOps, ces deux référentiels sont les mêmes. La plupart des adeptes de DevSecOps commencent par ce modèle. Cependant, à mesure que vous intégrez d'autres microservices, un référentiel de configuration de pipeline dédié et distinct peut être nécessaire. Etant donné que le référentiel d'application et le référentiel de configuration sont identiques dans l'exemple d'application, le référentiel est cloné deux fois lors de l'exécution des pipelines, ce qui peut entraîner des erreurs. C'est pourquoi la meilleure pratique consiste à disposer d'un référentiel de configuration distinct pour héberger les fichiers de configuration et les scripts qui peuvent être partagés et réutilisés entre les différentes chaînes d'outils et pipelines DevSecOps. Pour plus d'informations sur la personnalisation du référentiel de configuration, voir les étapes de personnalisation avancées.

DevSecOps les scripts considèrent le app-repo et le config-repo comme deux référentiels distincts. Les scripts clonent les référentiels deux fois lors de la phase de démarrage du pipeline. Ces clones sont appelés app-repo et one-pipeline-config-repo. Chaque étape est exécutée dans le contexte de config repo.

Option 1: Ajoutez votre référentiel d'application et utilisez le modèle de référentiel d'application comme référentiel de configuration

Pour ajouter votre référentiel d'application à la chaîne d'outils et utiliser le référentiel d'application exemple comme référentiel de configuration, procédez comme suit:

1. Dans la console " IBM Cloud, cliquez sur l'icône " Menu, " > " Automatisation de la plate-forme > " Chaînes d'outils, et sélectionnez la chaîne d'outils que vous souhaitez modifier.
2. Cliquez sur Ajouter.
3. Sélectionnez l'emplacement où votre référentiel d'applications est hébergé, Gitlab ou GitHub.
4. Utilisez le serveur par défaut ou ajoutez-en un nouveau.
5. Saisissez l' URL e du serveur personnalisé et le jeton d'accès personnel.
6. Cliquez sur Créer une intégration.
7. Entrez le référentiel de code source de votre application URL.
8. Cliquez sur Créer une intégration.

Ensuite, spécifiez l'exemple de référentiel d'application comme référentiel de configuration en procédant comme suit:

1. Dans la console " IBM Cloud, cliquez sur l'icône " Menu, " > " Automatisation de la plate-forme > " Chaînes d'outils, et sélectionnez la chaîne d'outils que vous souhaitez modifier.
2. Cliquez sur pr-pipeline.
3. Cliquez sur Paramètres et accédez à l'onglet Propriétés d'environnement.
4. Modifier la valeur de la propriété ' pipeline-config-repo ' pour qu'elle pointe vers le référentiel d'applications d'exemple URL.
5. Revenez à votre chaîne d'outils d'EC.
6. Cliquez sur ci-pipeline.
7. Cliquez sur Paramètres et accédez à l'onglet Propriétés d'environnement.
8. Modifier la valeur de la propriété ' pipeline-config-repo ' pour qu'elle pointe vers le référentiel d'applications d'exemple URL.

Vos pipelines d'EC utilisent désormais le modèle de référentiel d'application pipeline-config comme référentiel de configuration.

Option 2: Remplacez l'exemple de référentiel d'application par votre propre référentiel d'application

Pour remplacer l'exemple de référentiel d'application par votre propre référentiel d'application, procédez comme suit:

1. Dans la console 'IBM Cloud, cliquez sur l'icône 'Menu ' > 'Automatisation de la plate-forme > 'Chaînes d'outils, et sélectionnez la chaîne d'outils CI que vous souhaitez modifier.
2. Recherchez le référentiel de code source de l'exemple d'application et sélectionnez Configurer.
3. Remplacez le référentiel URL par le référentiel de votre code source d'application URL.
4. Cliquez sur Save integration.

Après avoir remplacé l'exemple de référentiel d'application, assurez-vous que le nouveau référentiel d'application contient un fichier .pipeline-config.yaml et les scripts correspondants. Copiez le fichier .pipeline-config.yaml et les scripts du référentiel de l'exemple d'application dans votre référentiel d'application ou utilisez cet exemple de fichier de configuration.

Configuration des pipelines d'EC

Après avoir ajouté votre référentiel d'application, vous devez configurer les pipelines d'EC pour qu'ils fonctionnent avec le nouveau référentiel.

Utiliser des scripts personnalisés avec DevSecOps

Le fichier " pipeline-config.yaml est le composant clé qui orchestre et personnalise le comportement du pipeline DevSecOps. Le fichier utilise des scripts pour générer, tester et déployer votre application. Le fichier définit comment les étapes sont configurées et quels scripts sont exécutés. Pour plus d'informations, voir Scripts personnalisés.

Il existe deux grandes catégories de scripts utilisés dans les pipelines DevSecOps:

• Scripts liés à l'application qui sont utilisés pour générer, tester et déployer votre application. Ces scripts relèvent de votre propre responsabilité et sont hors de portée de l'assistance DevSecOps. Comme ces scripts n'ont pas d'implémentation par défaut, vous devez les ajouter à votre application ou à votre référentiel de configuration. Vous devrez peut-être extraire les scripts de Jenkins ou d'une autre source.
• Des scripts de sécurité et de conformité qui exécutent des analyses de sécurité et de conformité. La plupart sont fournis avec des scripts par défaut que vous pouvez remplacer pour utiliser votre propre implémentation personnalisée.

A l'exception de l'étape de démarrage, chaque étape d'un pipeline CI, CD ou CC peut être personnalisée avec vos propres scripts pour remplacer l'implémentation par défaut de l'étape. L'étape de démarrage ne peut pas être personnalisée avec vos propres scripts.

Bien que les scripts Bash soient fournis en tant qu'exemples, vous pouvez générer, tester et déployer votre application à l'aide d'autres langages tels que Python ou Go. Veillez à utiliser le image approprié pour chaque étape. Reportez-vous aux imagesDocker dans la section Pipelines DevSecOps.

Reportez-vous au tableau Etapes et tâches qui récapitule les différentes étapes du pipeline d'EC. Le tableau fournit également des informations consolidées indiquant si l'étape possède une implémentation de référence par défaut, si elle peut être personnalisée ou ignorée, ou si une collecte d'informations collectées explicite est requise par l'exécution de l'étape.

Configuration du pipeline CD

Dans le flux de travailDevSecOps d'intégration et de déploiement continus, le pipeline d'intégration continue envoie des mises à jour au référentiel d'inventaire au cours de l'étape " deploy-release du pipeline d'intégration continue. Pour plus d'informations, voir l'exemple de script release.sh.

Dans ce flux de travail, plusieurs déclencheurs de CI et différentes chaînes d'outils de CI DevSecOps peuvent contribuer au même référentiel d'inventaire.

Contrairement au pipeline CI, le script de déploiement utilisé par le pipeline CD doit être adapté à partir de vos scripts en cours dans Jenkins, Travis ou sur une autre plateforme pour utiliser les entrées du référentiel d'inventaire.

Cet exemple de code montre comment extraire des informations de l'inventaire et l'utiliser pour exécuter un déploiement Kubernetes.

Emplacement des scripts DevSecOps

Les pipelines DevSecOps sont livrés avec des outils de sécurité et d'analyse par défaut et des scripts associés.

Par exemple, le début d'un journal d'étape fait référence au script par défaut:

scan-artifact:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.24
  dind: true
  dind_image: icr.io/continuous-delivery/toolchains/devsecops/docker:20.10.21-dind
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script: |
    #!/bin/sh

    "/opt/commons/scan-artifact/scan.sh"

/opt/commons/scan-artifact/scan.sh est le script par défaut.

Le pipeline DevSecOps fournit le chemin d'accès au dossier racine de la bibliothèque commons dans une variable d'environnement appelée " COMMONS_PATH, qui est disponible dans toutes les tâches et étapes. Pour accéder à un script intégré à l'image de base de conformité, utilisez la variable COMMONS_PATH avec le dossier de script dont vous avez besoin:

source "${COMMONS_PATH}/<script folder in commons>/<script file name>

Consultez le tableau Etapes et tâches qui récapitule les différentes étapes du pipeline CD. La table fournit également des informations consolidées indiquant si l'étape possède une implémentation de référence par défaut, si elle peut être personnalisée ou ignorée ou si une collecte d'informations collectées explicite est requise par l'exécution de l'étape.

Propriétés d'environnement

Les pipelines DevSecOps sont livrés avec des propriétés d'environnement prédéfinies, mais vous pouvez ajouter autant de propriétés personnalisées que nécessaire. Vous pouvez accéder à ces valeurs de propriétés dans vos scripts à l'aide de la commande get_env.

Après avoir ajouté votre propriété et sa valeur par défaut facultative au pipeline ou au déclencheur, utilisez la commande get_env dans votre script pour extraire la valeur de la propriété. L'exemple suivant extrait la valeur de la propriété my-variable:

MY_VARIABLE=$(get_env my-variable "")

Vous pouvez également remplacer dynamiquement la valeur d'une propriété dans un script à l'aide de la commande set_env. L'exemple suivant remplace la valeur de la propriété my-variable:

set_env my-variable new-value

Ignorer les étapes

Certaines étapes peuvent ne pas être pertinentes. Par exemple, vous ne générez peut-être pas d'images Docker ou vous n'avez pas encore implémenté de tests d'acceptation. Si vous souhaitez ignorer une étape, vous pouvez éditer le fichier .pipeline-config.yaml pour inclure exit 0 ou définir la variable skip sur true.

L'exemple suivant ajoute exit 0 pour ignorer une étape:

scan-artifact:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.24
  dind: true
  dind_image: icr.io/continuous-delivery/toolchains/devsecops/docker:20.10.21-dind
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  skip: false
  runAfter: null
  script: |
    #!/bin/sh

    exit 0
    "/opt/commons/scan-artifact/scan.sh"

Les images Docker dans les pipelines DevSecOps

Par défaut, les pipelines DevSecOps utilisent IBM Les images de Continuous Delivery. Ces images contiennent certains des outils les plus courants, tels que Node et Java, pour exécuter vos scripts. Vous pouvez également utiliser les images d'un autre fournisseur ou vos propres images personnalisées qui contiennent vos outils préférés.

Les images Docker utilisées par les pipelines DevSecOps sont spécifiées dans le fichier " .pipeline-config.yaml. Chaque étape peut utiliser une image différente.

scan-artifact:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.24
  dind: true
  dind_image: icr.io/continuous-delivery/toolchains/devsecops/docker:20.10.21-dind
(...)