FAQ pour DevSecOps

Obtenez des réponses aux questions fréquemment posées concernant l'utilisation d' DevSecOps.

Quelle est la différence entre le pipeline CI et le pipeline CC ?

Vous remarquerez peut-être que les pipelines CI et CC ont des étapes communes. Les analyses et les contrôles effectués sont de nature et de détails similaires. Le tableau suivant présente les différences entre les pipelines CI et CC.

Différences entre les pipelines CI et CC
Pipeline CI Pipeline CC
Il fait partie de la chaîne d'outils CI. Il fait partie de la chaîne d'outils CC.
Il est déclenché après qu'une demande de fusion a été fusionnée avec la branche master Il peut être déclenché manuellement ou à des intervalles prédéfinis indépendants d'un calendrier de déploiement.
Une application URL et les détails du dépôt de code de l'application sont saisis dans le cadre de la procédure d'installation. Une application URL et les détails du code de l'application sont fournis après la configuration de la chaîne d'outils CC et avant le lancement de la première exécution du pipeline.
Les questions relatives aux incidents qui sont créées dans le cadre de diverses analyses et vérifications au cours des contrôles de conformité ne comportent pas de date d'échéance. Les incidents créés dans le cadre des différentes analyses et vérifications effectuées lors des contrôles de conformité sont assortis d'une date d'échéance.
Les incidents créés sont détectés lors de la construction. Les incidents créés sont détectés au cours d'analyses périodiques de l'environnement d'essai ou de production.
Le fichier summary.json n'est pas généré à la fin de chaque exécution du pipeline CI. Le fichier summary.json n'est pas généré à la fin de chaque exécution du pipeline CI.
Il comprend des étapes telles que la création d'un artefact d'application, la signature de l'artefact et le déploiement sur le cluster de développement. Cela crée à son tour des entrées pour le pipeline de CD. Il n'exécute que les analyses et les contrôles nécessaires aux tests de conformité.

Comment un utilisateur peut-il personnaliser le pipeline ?

Un pipeline est personnalisé à l'aide de scripts personnalisés. Les scripts personnalisés sont des points d'extension dans le pipeline où les adoptants, les équipes et les utilisateurs peuvent fournir des scripts pour exécuter des tâches personnalisées dans le cadre de leurs stratégies CI/CD.

Les scripts personnalisés contrôlent les étapes de pipeline. Vous pouvez utiliser un fichier de configuration pour (pipeline-config.yaml) définir le comportement des étapes, le contenu des scripts et l'artefact de base qui exécute les scripts. Les scripts et la configuration des étapes du pipeline sont chargés à partir d'un référentiel d'application similaire à .travis.yml ou Jenkinsfile ou d'un référentiel personnalisé.

Pour plus d'informations, voir Personnaliser les pipelines à l'aide de scripts personnalisés.

Image multiarchitecture pour les limitations des plateformes s390x et Power

One-Pipeline offre un support natif pour les plateformes s390x et Power en utilisant runtimeClassName (une chaîne indiquant le profil d'exécution) dans le fichier de configuration de one-pipeline. Toutefois, cette prise en charge native s'accompagne de certaines limitations et recommandations :

  • Limites :
    • Cette fonctionnalité est disponible uniquement dans v11.
    • L' heure de démarrage du pod est plus élevée que pour la classe d'exécution x86.
    • Vous devez utiliser podman avec les charges de travail s390x ou Power. Docker n'est pas disponible.
      • Les scripts utilisateurs doivent être mis à jour pour fonctionner avec la commande podman au lieu de la commande docker
      • L'image de la scène doit avoir podman installé.
  • Recommandations : utiliser les classes d'exécution x86 pour
    • la numérisation, étant donné que les différentes images des outils de numérisation peuvent ne pas prendre en charge l'architecture multiple.
    • la signature de l'image, car la prise en charge de plusieurs architectures n'est pas disponible (travail en cours).

Comment puis-je créer une image de base personnalisée multi-architecture?

One Pipeline fournit une image de base officielle multi-architecture qui prend en charge les plateformes suivantes :

  • linux/amd64
  • linux/ppc64le
  • linux/s390x

Dans la plupart des cas, nous vous recommandons d'utiliser directement l'image de base officielle :

icr.io/continuous-delivery/toolchains/devsecops/baseimage:<version>

Si votre application nécessite des paquets supplémentaires du système d'exploitation, des environnements d'exécution de langages ou d'autres dépendances personnalisées, vous pouvez créer votre propre image de base multi-architecture personnalisée dans le cadre de votre pipeline d'intégration continue (CI).

Utilisez Docker Buildx avec l'option --platform dans votre étape build-artifact :

docker buildx build \
  --platform linux/amd64,linux/ppc64le,linux/s390x \
  -t <registry>/<namespace>/<image>:<tag> \
  --push .

Ce processus permet de créer des images spécifiques à chaque architecture et de les publier sous la forme d'un seul manifeste d'images multi-architectures. Les environnements d'exécution de conteneurs récupèrent automatiquement l'image adaptée à la plateforme cible.

Approche recommandée

  1. Utilisez l'image de base « One Pipeline » comme image « FROM » dans votre Dockerfile.
  2. N'ajoutez que les paquets ou dépendances supplémentaires requis par votre application.
  3. Compilez et publiez l'image à l'aide de Buildx d' Docker, dans votre pipeline d'intégration continue.
  4. Vérifiez l'image publiée à l'aide de docker buildx imagetools inspect ou skopeo inspect.

Pour plus d'informations sur la prise en charge multi-architecture et ses limitations, consultez la section « Limitations des images multi-architecture pour les plateformes s390x et Power ».

Déclenchement d'un pipeline à l'aide de l'interface de programmation

Un pipeline peut être déclenché à l'aide du CLI IBM Cloud ou d'une API. Avec l'interface de programmation, vous pouvez démarrer un pipeline en fournissant les identifiants de la chaîne d'outils et du pipeline. En utilisant l'API, vous pouvez envoyer une requête POST avec l'authentification et les en-têtes appropriés pour déclencher le pipeline.

Pour plus d'informations, voir Utilisation des déclencheurs

Quelle propriété d'environnement est utilisée pour cloner des dépôts Git?

Les pipelines d' DevSecOps s utilisent un système de jetons hiérarchique pour authentifier les opérations sur le référentiel d' Git s, y compris le clonage. La propriété d'environnement « git-token » sert de jeton par défaut, mais vous pouvez la remplacer par des jetons plus spécifiques afin d'améliorer la sécurité et le contrôle d'accès.

Ordre de priorité des jetons

Le pipeline résout les jetons d'authentification d' Git s selon l'ordre de priorité suivant (du plus élevé au plus bas):

  1. Jeton d'accès personnel (PAT) défini dans l'intégration de la chaîne d'outils pour un référentiel spécifique
  2. Jeton spécifique au référentiel: git-token-[repo_name]-[repo_org]
  3. Jeton spécifique à l'organisation: git-token-[repo_org]
  4. Jeton par défaut: git-token
  5. OAuth jeton issu de l'intégration de la chaîne d'outils (si l'on utilise « OAuth » au lieu de « PAT »)

Exemples de noms de jetons

Pour un dépôt accessible à l'adresse https://github.com/my-org/my-app:

  • Spécifique au référentiel : git-token-my-app-my-org
  • Spécifique à l'organisation : git-token-my-org

Remarques importantes

  • Si la même instance d' git-token est utilisée à la fois pour les opérations de lecture des référentiels (clonage) et pour les opérations d'écriture (définition du statut PR/CI, mise à jour de l'inventaire), un accès en lecture seule n'est pas suffisant. Le jeton doit disposer de droits d'écriture.
  • L'utilisation de jetons spécifiques à un dépôt ou à une organisation vous permet d'appliquer le principe du privilège minimal en n'accordant que les autorisations nécessaires pour chaque dépôt.

Pour plus d'informations sur les fonctions liées aux jetons de référentiel, consultez la section « Récupération des informations et des jetons de référentiel ».

Comment tester les modifications apportées à la configuration d' OnePipeline?

Pour tester les modifications apportées à la configuration d' OnePipeline, il est nécessaire d'adopter une approche systématique afin d'éviter de perturber les pipelines de production tout en validant les personnalisations.

Comprendre les composants d' OnePipeline

OnePipeline se compose de deux éléments principaux personnalisables :

  • Définitions de pipelines Tekton: définitions de pipelines gérées de manière centralisée pour les workflows PR, CI, CD et CC, disponibles dans le référentiel compliance-pipelines. De nouvelles versions sont publiées toutes les deux semaines.

    • v10: Version stable avec une capacité de traitement simultané limitée
    • v11: version de nouvelle génération offrant une personnalisation et une capacité de traitement simultané maximales

  • Configuration du pipeline (.pipeline-config.yaml): fichier de configuration personnalisé qui remplace les paramètres par défaut du pipeline, notamment les images, les scripts, les architectures et les propriétés du pipeline. Ce fichier peut être stocké dans le référentiel de votre application ou dans un référentiel de configuration centralisé.

Méthode de test n° 1 : utilisation d'un fichier de configuration de test

Il s'agit de la méthode recommandée pour tester les modifications de configuration sans affecter les pipelines de production.

  1. Créer une branche de test

    • Créez une branche dans le référentiel contenant votre fichier .pipeline-config.yaml
    • Effectuez vos modifications de configuration dans cette branche

  2. Configurer un déclencheur de test

    • Dupliquez le déclencheur de pipeline existant dans votre chaîne d'outils
    • Donnez-lui un nom clair (par exemple, Manual-Test-Config)
    • Modifiez les propriétés du déclencheur pour qu'elles pointent vers votre configuration de test :
      • pipeline-config: Nom de votre fichier de configuration
      • pipeline-config-branch: Nom de votre branche de test
      • pipeline-config-repo: Dépôt URL contenant la configuration

  3. Test en mode développement

    • Activer le mode développement dans les propriétés du déclencheur
    • Exécutez le pipeline pour valider vos scripts personnalisés
    • Le mode développement ignore la collecte des preuves, la création des problèmes de conformité et les mises à jour de l'inventaire, ce qui le rend idéal pour des itérations rapides
    • Important: le mode développement n'est pas adapté aux charges de travail en production

  4. Test avec vérifications de conformité

    • Après avoir validé les scripts en mode développement, désactivez dev-mode
    • Désactivez la mise à jour des stocks pendant les tests
    • Mettre en place un processus complet comprenant la collecte des preuves et la gestion des problèmes
    • Vérifiez que tous les contrôles de conformité se déroulent comme prévu

  5. Promouvoir vers la production

    • Une fois que les tests sont concluants, créez une pull request pour intégrer vos modifications à la branche principale
    • Les modifications s'appliqueront automatiquement aux déclencheurs de production
    • En cas de problème, vous pouvez rapidement annuler les modifications

Approche de test n° 2 : modification de la configuration du pipeline

Définitions des branchements de pipeline (niveau avancé)

  • (Créer une branche du dépôt compliance-pipelines )
  • Développez et testez les modifications apportées à votre fork
  • Ajoutez le dépôt dérivé en tant qu'intégration d' Git s dans votre chaîne d'outils
  • Modifiez temporairement la définition du pipeline pour qu'elle fasse référence à votre fork
  • Configurez un déclencheur en mode développement pour tester la nouvelle définition de pipeline
  • Suivez les étapes de test décrites dans l'approche 1

Pratiques recommandées

  • Testez toujours d'abord en mode développement pour détecter rapidement les erreurs de script
  • Utilisez des noms descriptifs pour les déclencheurs de test afin d'éviter toute confusion
  • Consignez vos modifications de configuration dans les messages de validation
  • Veillez à laisser les déclencheurs de test désactivés ou à les supprimer après les tests afin d'éviter toute exécution accidentelle
  • Envisagez de mettre en place une chaîne d'outils de test dédiée pour les modifications importantes apportées au pipeline
  • Examinez attentivement les journaux du pipeline pour vous assurer que toutes les étapes s'exécutent comme prévu

Pour plus d’informations sur la personnalisation des pipelines, consultez la section Scripts personnalisés et