Évaluer la conformité des politiques en CI

Ajouter l'Évaluation de Politique à vos pipelines d'intégration continue vous aide à détecter et prévenir les cas où les changements de code causeraient une dégradation de la conformité des politiques par rapport à votre ligne de base.

La stratégie recommandée pour l'Évaluation de Politique dans un environnement CI implique d'évaluer une image locale et de comparer les résultats à une ligne de base. Si la conformité des politiques pour l'image locale est pire que la ligne de base spécifiée, l'exécution CI échoue avec une erreur. Si la conformité des politiques est meilleure ou inchangée, l'exécution CI réussit.

Cette comparaison est relative, ce qui signifie qu'elle ne concerne que de savoir si votre image CI est meilleure ou pire que votre ligne de base. Ce n'est pas une vérification absolue pour réussir ou échouer toutes les politiques. En mesurant relativement à une ligne de base que vous définissez, vous pouvez rapidement voir si un changement a un impact positif ou négatif sur la conformité des politiques.

Comment ça fonctionne

Lorsque vous faites l'Évaluation de Politique en CI, vous exécutez une évaluation de politique locale sur l'image que vous construisez dans votre pipeline CI. Pour exécuter une évaluation locale, l'image que vous évaluez doit exister dans le magasin d'images où votre workflow CI est exécuté. Soit construisez ou tirez l'image, puis exécutez l'évaluation.

Pour exécuter l'évaluation de politique et déclencher un échec si la conformité de votre image locale est pire que votre ligne de base de comparaison, vous devez spécifier la version d'image à utiliser comme ligne de base. Vous pouvez coder en dur une référence d'image spécifique, mais une meilleure solution est d'utiliser les environnements pour inférer automatiquement la version d'image d'un environnement. L'exemple qui suit utilise les environnements pour comparer l'image CI avec l'image dans l'environnement production.

Exemple

L'exemple suivant sur comment exécuter l'évaluation de politique en CI utilise l'Action GitHub Docker Scout pour exécuter la commande compare sur une image construite en CI. La commande compare a une entrée to-env, qui exécutera la comparaison contre un environnement appelé production. L'entrée exit-on est définie à policy, ce qui signifie que la comparaison échoue seulement si la conformité des politiques s'est dégradée.

Cet exemple ne suppose pas que vous utilisez Docker Hub comme votre registre de conteneurs. En conséquence, ce workflow utilise docker/login-action deux fois :

• Une fois pour s'authentifier auprès de votre registre de conteneurs.
• Une fois de plus pour s'authentifier auprès de Docker pour tirer les résultats d'analyse de votre image production.

Si vous utilisez Docker Hub comme votre registre de conteneurs, vous n'avez besoin de vous authentifier qu'une seule fois.

Note

En raison d'une limitation dans Docker Engine, charger des images multi-plateformes ou des images avec des attestations dans le magasin d'images n'est pas pris en charge.

Pour que l'évaluation de politique fonctionne, vous devez charger l'image dans le magasin d'images local du runner. Assurez-vous que vous construisez une image mono-plateforme sans attestations, et que vous chargez les résultats de construction. Sinon, l'évaluation de politique échoue.

Notez également la permission pull-requests: write pour le job. L'Action GitHub Docker Scout ajoute un commentaire de pull request avec les résultats d'évaluation par défaut, ce qui nécessite cette permission. Pour plus de détails, voir Commentaires de Pull Request.

name: Docker

on:
  push:
    tags: ["*"]
    branches:
      - "main"
  pull_request:
    branches: ["**"]

env:
  REGISTRY: docker.io
  IMAGE_NAME: <IMAGE_NAME>
  DOCKER_ORG: <ORG>

jobs:
  build:
    permissions:
      pull-requests: write

    runs-on: ubuntu-latest
    steps:
      - name: Log into registry ${{ env.REGISTRY }}
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ secrets.REGISTRY_USER }}
          password: ${{ secrets.REGISTRY_TOKEN }}
      
      - name: Setup Docker buildx
        uses: docker/setup-buildx-action@v3

      - name: Extract metadata
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ${{ env.IMAGE_NAME }}

      - name: Build image
        id: build-and-push
        uses: docker/build-push-action@v4
        with:
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          sbom: ${{ github.event_name != 'pull_request' }}
          provenance: ${{ github.event_name != 'pull_request' }}
          push: ${{ github.event_name != 'pull_request' }}
          load: ${{ github.event_name == 'pull_request' }}

      - name: Authenticate with Docker
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_USER }}
          password: ${{ secrets.DOCKER_PAT }}

      - name: Compare
        if: ${{ github.event_name == 'pull_request' }}
        uses: docker/scout-action@v1
        with:
          command: compare
          image: ${{ steps.meta.outputs.tags }}
          to-env: production
          platform: "linux/amd64"
          ignore-unchanged: true
          only-severities: critical,high
          organization: ${{ env.DOCKER_ORG }}
          exit-on: policy

La capture d'écran suivante montre à quoi ressemble le commentaire GitHub PR lorsqu'une vérification d'évaluation de politique échoue parce que la politique s'est dégradée dans l'image PR comparée à la ligne de base.

Cet exemple a démontré comment exécuter l'évaluation de politique en CI avec GitHub Actions. Docker Scout prend également en charge d'autres plateformes CI. Pour plus d'informations, voir Intégrations CI Docker Scout.