Scanner les images Docker dans une chaîne d’intégration continue (CI) GitLab

GitLab propose à ses usagers de scanner un conteneur dans une CI via un scanneur externe. Cela permet d’inclure dans la CI une étape durant laquelle Cyberwatch génèrera la liste des vulnérabilités et le SBOM d’une image Docker. Cela permet aussi aux utilisateurs ayant accès aux fonctionnalités GitLab Ultimate d’afficher directement dans l’interface GitLab les vulnérabilités détectées sur l’image scannée ainsi que la liste des paquets détectés.

Cyberwatch peut être utilisé pour scanner les images dans une CI GitLab. Nous allons voir comment configurer et utiliser cette fonctionnalité.

Prérequis

Afin de pouvoir utiliser cette fonctionnalité, il est nécessaire d’avoir préalablement configuré un moteur d’exécution Docker. Cyberwatch propose un moteur de scan embarqué par défaut. Si toutefois vous souhaitez utiliser votre moteur d’exécution, la procédure est expliquée ici.

Configurer le scanneur de conteneur

Pour permettre à GitLab de se connecter à Cyberwatch, il est nécessaire de configurer un scanneur de conteneur :

  1. Cliquer sur Administration
  2. Cliquer sur Outils externes
  3. Cliquer sur l’onglet Scanneurs de conteneur
  4. Cliquer sur le bouton Ajouter
  5. Choisir un nom et sélectionner la cible “GitLab”
  6. Choisir la source et, si vous en avez enregistré plusieurs, le moteur d’exécution Docker qui sera utilisé pour scanner les images Docker
  7. Enregistrer

Vous obtenez les données nécessaires pour ajouter Cyberwatch comme scanneur de conteneur dans GitLab. Pensez à enregistrer ces données, elles ne seront plus accessibles par la suite.

Il est possible de créer plusieurs jeux d’identifiants et définir ainsi plusieurs scanneurs dans plusieurs CI. Cela permet de configurer au niveau de chaque projet le scanneur à utiliser. On peut ainsi répartir les scans d’image Docker entre les nœuds dans une instance multi-nœuds ou ajouter de la concurrence sur un même nœud.

Il est également possible de régler le délai entre deux requêtes de l’API. Ce temps correspond à l’intervalle entre deux requêtes de l’API lors de la création du rapport de vulnérabilités d’une image Docker.

Un temps trop court peut entraîner des problèmes de surcharge de l’API, un temps trop long va allonger inutilement le temps nécessaire pour scanner une image. La valeur par défaut est de 30 secondes.

Ajouter Cyberwatch comme scanneur de conteneur

Vous pouvez maintenant ajouter Cyberwatch comme scanneur de conteneur pour vos CI GitLab.

Pour indiquer à GitLab qu’on utilise Cyberwatch comme scanneur de conteneur, vous devrez modifier le fichier gitlab-ci.yml du projet et y intégrer l’extrait suivant, ou une variation :

stages:
  - test # Requis

include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml # Requis

container_scanning: # Le nom NE DOIT PAS être modifié
  stage: test # Requis
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event" # Modifiable
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH # Modifiable
  variables:
    CS_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG # Modifiable
    CS_ANALYZER_IMAGE: cyberwatch/ci-container-scanner # Requis

Des variables d’environnement nécessaires doivent être configurées afin que le scanner d’images Docker puisse contacter Cyberwatch :

  • CYBERWATCH_SCANNER_ENDPOINT : Point de terminaison configuré plus tôt
  • CYBERWATCH_SCANNER_USER : Nom d’utilisateur associé au Point de terminaison
  • CYBERWATCH_SCANNER_PASSWORD : Mot de passe associé à l’utilisateur

En plus des variables nécessaires à Cyberwatch, d’autres variables peuvent être utilisées pour configurer l’accès à Cyberwatch :

  • CYBERWATCH_SCANNER_INSECURE : (défaut: non attribuée). Si la variable est configurée, alors la connexion entre le conteneur scanner et Cyberwatch se fera de manière non-sécurisée. Il est déconseillé d’utiliser cette option

Plus d’informations sont disponibles dans la documentation de GitLab sur les variables (en anglais).

Le registre Docker est automatiquement déduit de l’image scannée. L’accès au registre est fait via les identifiants passés en variable d’environnement à la CI GitLab, comme suit :

  • CS_REGISTRY_USER : Identifiant utilisé pour la connexion au registre
  • CS_REGISTRY_PASSWORD : Mot de passe utilisé pour la connexion au registre

La démarche pour ajouter ces variables d’environnement à votre projet est la suivante :

  1. Se connecter à GitLab avec un compte ayant accès à la page de paramètres du projet concerné
  2. Sur la page du projet, déplier la partie « Paramètres » et aller dans la partie CI/CD
  3. Déplier la partie « Variables »
  4. Ajouter les variables CYBERWATCH_SCANNER_ENDPOINT, CYBERWATCH_SCANNER_USER, CYBERWATCH_SCANNER_PASSWORD, et au besoin CS_REGISTRY_USER et CS_REGISTRY_PASSWORD

Une fois les variables d’environnement enregistrées et le fichier gitlab-ci.yml ajouté, l’image désignée par $CS_IMAGE sera scannée par Cyberwatch. Dans les artéfacts du job « container_scanning », vous trouverez deux fichiers :

  • gl-container-scanning-report.json : Le rapport de vulnérabilité interprétable par GitLab selon la spécification disponible ici
  • gl-sbom-report-cdx.json : Le SBOM de l’image docker au format CycloneDX, dont la spécification est disponible ici

Scanner les images Docker dans une chaîne d’intégration continue (CI) GitHub

En suivant une procédure similaire à celle utilisée pour GitLab, il est possible d’intégrer Cyberwatch dans un pipeline GitHub via les GitHub Actions. Les principales différences résident dans la déclaration des variables et la manière de structurer le pipeline.

Déclaration des variables d’environnement

Après avoir configuré un scanneur de conteneur depuis Cyberwatch, 3 variables seront affichées afin de faire la liaison entre l’instance Cyberwatch et le repository GitHub.

  1. Récupérer ainsi CYBERWATCH_SCANNER_ENDPOINT, CYBERWATCH_SCANNER_USER et CYBERWATCH_SCANNER_PASSWORD
  2. Ajouter les comme secrets dans votre repository dans « Settings », puis dans l’onglet « Secrets and variables » et « Actions »

Ces 3 variables sont obligatoires pour le bon fonctionnement de l’intégration. Cependant, il en existe d’autres optionnelles permettant par exemple, de s’authentifier auprès d’un registre privé, décrites précédemment.

Création du pipeline GitHub Action

Pour créer un pipeline CI avec GitHub, cliquer sur « Action », puis « set up a workflow yourself » (ou « Simple Workflow » afin d’avoir une structure de départ). Voici un exemple d’un pipeline minimal permettant le scan de l’image publique Ruby lors d’un push sur le repository :

name: GitHub Actions CI Scan Container
on: [push]
jobs:
  CI-Container-Scanner:
    runs-on: ubuntu-latest
    container:
      image: cyberwatch/ci-container-scanner
    env:
      CYBERWATCH_SCANNER_ENDPOINT: ${{ secrets.CYBERWATCH_SCANNER_ENDPOINT }}
      CYBERWATCH_SCANNER_USER: ${{ secrets.CYBERWATCH_SCANNER_USER }}
      CYBERWATCH_SCANNER_PASSWORD: ${{ secrets.CYBERWATCH_SCANNER_PASSWORD }}
      CS_IMAGE: library/ruby:3.0
    steps:
      - run: gtcs

Dans le cadre de l’établissement d’un pipeline plus complexe, il est possible de se référer à la documentation de GitHub.

Retour en haut