⚠️ Traduction non officielle - Cette documentation est une traduction communautaire non officielle de Docker.

Commencer avec l'Évaluation de Politique dans Docker Scout

Table des matières

Dans la gestion de la chaîne d'approvisionnement logiciel, maintenir la sécurité et la fiabilité des artefacts est une priorité absolue. L'Évaluation de Politique dans Docker Scout introduit une couche de contrôle, au-dessus des capacités d'analyse existantes. Elle vous permet de définir des règles de chaîne d'approvisionnement pour vos artefacts, et vous aide à suivre comment vos artefacts se comportent, par rapport à vos règles et seuils, au fil du temps.

Apprenez comment vous pouvez utiliser l'Évaluation de Politique pour vous assurer que vos artefacts s'alignent avec les meilleures pratiques établies.

Comment fonctionne l'Évaluation de Politique

Lorsque vous activez Docker Scout pour un dépôt, les images que vous poussez sont automatiquement analysées. L'analyse vous donne des informations sur la composition de vos images, incluant les paquets qu'elles contiennent et les vulnérabilités auxquelles elles sont exposées. L'Évaluation de Politique s'appuie sur la fonctionnalité d'analyse d'image, interprétant les résultats d'analyse par rapport aux règles définies par les politiques.

Une politique définit des critères de qualité d'image que vos artefacts doivent remplir. Par exemple, la politique Aucune licence AGPL v3 signale toute image contenant des paquets distribués sous la licence AGPL v3. Si une image contient un tel paquet, cette image n'est pas conforme à cette politique. Certaines politiques, telles que la politique Aucune licence AGPL v3, sont configurables. Les politiques configurables vous permettent d'ajuster les critères pour mieux correspondre aux besoins de votre organisation.

Dans Docker Scout, les politiques sont conçues pour vous aider à améliorer progressivement votre posture de sécurité et de chaîne d'approvisionnement. Là où d'autres outils se concentrent sur la fourniture d'un statut de réussite ou d'échec, les politiques Docker Scout visualisent comment de petits changements incrémentaux affectent le statut de politique, même lorsque vos artefacts ne répondent pas aux exigences de politique (encore). En suivant comment l'écart d'échec change au fil du temps, vous voyez plus facilement si votre artefact s'améliore ou se détériore par rapport à la politique.

Les politiques ne doivent pas nécessairement être liées à la sécurité d'application et aux vulnérabilités. Vous pouvez utiliser les politiques pour mesurer et suivre d'autres aspects de la gestion de chaîne d'approvisionnement également, tels que l'utilisation de licences open-source et la mise à jour des images de base.

Types de politique

Dans Docker Scout, une politique est dérivée d'un type de politique. Les types de politique sont des modèles qui définissent les paramètres fondamentaux d'une politique. Vous pouvez comparer les types de politique aux classes dans la programmation orientée objet, avec chaque politique agissant comme une instance créée à partir de son type de politique correspondant.

Docker Scout prend en charge les types de politique suivants :

Docker Scout fournit automatiquement des politiques par défaut pour les dépôts où il est activé, sauf pour la politique Portes de Qualité SonarQube, qui nécessite l'intégration avec SonarQube avant utilisation.

Vous pouvez créer des politiques personnalisées à partir de n'importe lequel des types de politique pris en charge, ou supprimer une politique par défaut si elle n'est pas applicable à votre projet. Pour plus d'informations, consultez Configurer les politiques.

Vulnérabilité Basée sur la Gravité

Le type de politique Vulnérabilité Basée sur la Gravité vérifie si vos artefacts sont exposés à des vulnérabilités connues.

Par défaut, cette politique ne signale que les vulnérabilités de gravité critique et élevée où il y a une version de correction disponible. Essentiellement, cela signifie qu'il y a un correctif facile que vous pouvez déployer pour les images qui échouent à cette politique : mettez à niveau le paquet vulnérable vers une version contenant un correctif pour la vulnérabilité.

Les images sont considérées non conformes à cette politique si elles contiennent une ou plusieurs vulnérabilités qui tombent en dehors des critères de politique spécifiés.

Vous pouvez configurer les paramètres de cette politique en créant une version personnalisée de la politique. Les paramètres de politique suivants sont configurables dans une version personnalisée :

  • Âge : Le nombre minimum de jours depuis que la vulnérabilité a été publiée pour la première fois

    La justification pour ne signaler que les vulnérabilités d'un certain âge minimum est que les vulnérabilités nouvellement découvertes ne devraient pas causer l'échec de vos évaluations jusqu'à ce que vous ayez eu une chance de les adresser.

  • Gravités : Niveaux de gravité à considérer (par défaut : Critique, Élevée)

  • Vulnérabilités corrigeables uniquement : Que ce soit ou non de ne rapporter que les vulnérabilités avec une version de correction disponible (activé par défaut).

  • Types de paquets : Liste des types de paquets à considérer.

    Cette option vous permet de spécifier les types de paquets, comme définitions de type de paquet PURL, que vous voulez inclure dans l'évaluation de politique. Par défaut, la politique considère tous les types de paquets.

Pour plus d'informations sur la configuration des politiques, voir Configurer les politiques.

Licences Conformes

Le type de politique Licences Conformes vérifie si vos images contiennent des paquets distribués sous une licence inappropriée. Les images sont considérées non conformes si elles contiennent un ou plusieurs paquets avec une telle licence.

Vous pouvez configurer la liste des licences que cette politique devrait rechercher, et ajouter des exceptions en spécifiant une liste d'autorisation (sous la forme de PURL). Voir Configurer les politiques.

Images de Base à Jour

Le type de politique Images de Base à Jour vérifie si les images de base que vous utilisez sont à jour.

Les images sont considérées non conformes à cette politique si le tag que vous avez utilisé pour construire votre image pointe vers un digest différent de celui que vous utilisez. S'il y a une discordance dans les digests, cela signifie que l'image de base que vous utilisez est obsolète.

Vos images ont besoin d'attestations de provenance pour que cette politique s'évalue avec succès. Pour plus d'informations, voir Aucune donnée d'image de base.

Vulnérabilités de Haut Profil

Le type de politique Vulnérabilités de Haut Profil vérifie si vos images contiennent des vulnérabilités de la liste curée de Docker Scout. Cette liste est maintenue à jour avec les vulnérabilités nouvellement divulguées qui sont largement reconnues comme risquées.

La liste inclut les vulnérabilités suivantes :

Vous pouvez personnaliser cette politique pour changer quels CVE sont considérés comme de haut profil en configurant la politique. Les options de configuration personnalisée incluent :

  • CVE Exclus : Spécifiez les CVE que vous voulez que cette politique ignore.

    Par défaut : [] (aucun des CVE de haut profil n'est ignoré)

  • CISA KEV : Activez le suivi des vulnérabilités du catalogue des Vulnérabilités Connues Exploitées (KEV) de CISA

    Le catalogue CISA KEV inclut les vulnérabilités qui sont activement exploitées dans la nature. Lorsqu'activée, la politique signale les images qui contiennent des vulnérabilités du catalogue CISA KEV.

    Activé par défaut.

Pour plus d'informations sur la configuration de politique, voir Configurer les politiques.

Attestations de Chaîne d'Approvisionnement

Le type de politique Attestations de Chaîne d'Approvisionnement vérifie si vos images ont des attestations SBOM et provenance.

Les images sont considérées non conformes si elles manquent soit d'une attestation SBOM soit d'une attestation de provenance avec provenance mode max. Pour assurer la conformité, mettez à jour votre commande de construction pour attacher ces attestations au moment de la construction :

$ docker buildx build --provenance=true --sbom=true -t <IMAGE> --push .

Pour plus d'informations sur la construction avec des attestations, voir Attestations.

Si vous utilisez GitHub Actions pour construire et pousser vos images, apprenez comment vous pouvez configurer l'action pour appliquer des attestations SBOM et de provenance.

Utilisateur Non-Root par Défaut

Par défaut, les conteneurs s'exécutent comme le superutilisateur root avec pleins privilèges d'administration système à l'intérieur du conteneur, à moins que le Dockerfile spécifie un utilisateur par défaut différent. Exécuter des conteneurs comme un utilisateur privilégié affaiblit leur sécurité d'exécution, car cela signifie que tout code qui s'exécute dans le conteneur peut effectuer administrative actions.

La politique Utilisateur Non-Root par Défaut vérifie les images qui sont configurées pour s'exécuter comme le superutilisateur root par défaut. Pour être conforme à cette politique, les images doivent spécifier un utilisateur non-root pour la phase d'exécution. Les images sont non conformes à cette politique si elles ne spécifient pas un utilisateur non-root par défaut pour la phase d'exécution.

Pour les images non conformes, les résultats de l'évaluation montrent si oui ou non le root utilisateur a été défini explicitement pour l'image. Cela vous aide à distinguer entre les violations de politique causées par des images où le root utilisateur est implicite et des images où root est défini intentionnellement.

Le Dockerfile suivant s'exécute en tant que root par défaut malgré ne pas être explicitement défini :

FROM alpine
RUN echo "Hi"

Alors que dans le cas suivant, le root utilisateur est explicitement défini :

FROM alpine
USER root
RUN echo "Hi"
Note

Cette politique ne vérifie que l'utilisateur par défaut de l'image, comme défini dans le blob de configuration de l'image. Même si vous spécifiez un utilisateur non-root par défaut, il est toujours possible de remplacer l'utilisateur par défaut au moment de l'exécution, par exemple en utilisant le drapeau --user pour la commande docker run.

Pour rendre vos images conformes à cette politique, utilisez l'instruction Dockerfile USER pour définir un utilisateur par défaut qui n'a pas de privilèges root pour la phase d'exécution.

Les extraits de Dockerfile suivants montrent la différence entre une image conforme et une image non conforme.

FROM alpine AS builder
COPY Makefile ./src /
RUN make build

FROM alpine AS runtime
COPY --from=builder bin/production /app
ENTRYPOINT ["/app/production"]
FROM alpine AS builder
COPY Makefile ./src /
RUN make build

FROM alpine AS runtime
COPY --from=builder bin/production /app
USER nonroot
ENTRYPOINT ["/app/production"]

Images de Base Approuvées

La politique Images de Base Approuvées vérifie que les images de base que vous utilisez dans vos constructions sont maintenues et sécurisées.

Cette politique vérifie si les images de base utilisées dans vos constructions correspondent à l'un des motifs spécifiés dans la configuration de politique. Le tableau suivant montre quelques motifs d'exemple pour cette politique.

Cas d'utilisation Motif
Autoriser toutes les images de Docker Hub docker.io/*
Autoriser toutes les images Docker Official Images docker.io/library/*
Autoriser des images d'une organisation spécifique docker.io/orgname/*
Autoriser des balises d'un référentiel spécifique docker.io/orgname/repository:*
Autoriser des images sur un registre avec le nom d'hôte registry.example.com registry.example.com/*
Autoriser des balises fines des images NodeJS docker.io/library/node:*-slim

Un astérisque (*) correspond jusqu'au caractère qui suit, ou jusqu'à la fin de la référence d'image. Notez que le préfixe docker.io est requis pour correspondre aux images de Docker Hub. Ce est le nom d'hôte de registre de Docker Hub.

Cette politique est configurable avec les options suivantes :

  • Sources d'images de base approuvées

    Spécifiez les motifs de référence d'image que vous souhaitez autoriser. La politique évalue les références d'image de base par rapport à ces motifs.

    Par défaut : [*] (toute référence est une image de base autorisée)

  • Seules les balises prises en charge

    Autoriser uniquement des balises prises en charge lors de l'utilisation d'images Docker Official Images.

    Lorsque cette option est activée, les images utilisant des balises non prises en charge des images officielles comme image de base de base déclenchent une violation de politique. Les balises prises en charge pour les images officielles sont listées dans la section Balises prises en charge de la vue d'ensemble du référentiel sur Docker Hub.

    Activé par défaut.

  • Seules les distributions de système d'exploitation prises en charge

    Autoriser uniquement Docker Official Images des versions de distribution Linux prises en charge.

    Lorsque cette option est activée, les images utilisant des distributions Linux non prises en charge qui ont atteint la fin de vie (telles que ubuntu:18.04) déclenchent une violation de politique.

    L'activation de cette option peut causer la politique à signaler aucune donnée si la version du système d'exploitation ne peut être déterminée.

    Activé par défaut.

Vos images ont besoin d'attestations de provenance pour que cette politique s'évalue avec succès. Pour plus d'informations, voir Aucune donnée d'image de base.

Portes de Qualité SonarQube

La politique Portes de Qualité SonarQube vérifie la qualité de votre code source contre les intégrations SonarQube. Cette politique fonctionne en ingérant les résultats d'analyse de code SonarQube dans Docker Scout.

Vous définissez les critères pour cette politique en utilisant les portes de qualité de SonarQube. SonarQube évalue votre code source contre les portes de qualité que vous avez définies dans SonarQube. Docker Scout surface la réussite de l'évaluation SonarQube comme politique Docker Scout.

Docker Scout utilise provenance attestations ou l'annotation OCI org.opencontainers.image.revision pour lier les résultats d'analyse SonarQube avec des images de conteneur. En plus d'activer l'intégration SonarQube, vous devez également vous assurer que vos images ont soit l'attestation soit la balise.

Git commit SHA links image with SonarQube analysis

Une fois que vous poussez une image et que l'évaluation de politique est terminée, les résultats de la qualité de porte de SonarQube s'affichent comme politique dans le tableau de bord Docker Scout, et dans la CLI.

Note

Docker Scout ne peut accéder aux évaluations créées après l'activation de l'intégration. Docker Scout ne peut accéder aux évaluations historiques. Déclenchez une évaluation SonarQube et évaluation de politique après l'activation de l'intégration pour voir les résultats dans Docker Scout.

Aucune donnée d'image de base

Il existe des cas où il n'est pas possible de déterminer des informations sur les images de base utilisées dans vos constructions. Dans de tels cas, les politiques Images de Base à Jour et Images de Base Approuvées sont signalées comme Aucune donnée.

Cet état "aucune donnée" se produit lorsque :

  • Docker Scout ne sait pas quel tag d'image de base vous avez utilisé
  • La version d'image de base que vous avez utilisée a plusieurs balises, mais pas toutes les balises sont obsolètes

Pour vous assurer que Docker Scout connaisse toujours votre image de base, vous pouvez attacher attestations de provenance au moment de la construction. Docker Scout utilise des attestations de provenance pour déterminer la version d'image de base.