Aller au contenu principal

Images de conteneurs

S'applique à :
Conteneurs en cours d'exécutionRegistres OCI v2 (Docker Hub, Harbor, Nexus, ECR, ACR, GAR, GHCR, Quay...)Navigation dans les projets HarborImages basées sur Debian / Ubuntu / Alpine

Vue d'ensemble​

Le Docker CBOM Scan reconstitue le système de fichiers d'un conteneur ou d'une image et y exécute le moteur de détection de services du scanner. Il répond à la question : quels services porteurs de cryptographie sont livrés dans cette image, et comment leur TLS est-il configuré ?

Trois façons d'analyser​

ModeFonctionnementPrérequis
Conteneurs en cours d'exécutionListe les conteneurs qui tournent sur l'hôte Docker et récupère le système de fichiers de ceux que vous sélectionnez.La CLI Docker disponible là où tourne le Cockpit (déploiements auto-hébergés).
Récupérer et analyser une imageRécupère une image, démarre un conteneur jetable sans exécuter son point d'entrée habituel, l'analyse puis l'arrête.Le même hôte Docker ; fonctionne avec tout registre accessible depuis cet hôte (les identifiants éventuels servent à la connexion de cet hôte au registre).
Analyser depuis un registre (sans Docker)Télécharge les couches de l'image directement via l'API OCI Distribution v2, les applique dans l'ordre (y compris les marqueurs de fichiers supprimés) et analyse le résultat. Les images multi-architectures sont résolues en linux/amd64.Un accès réseau au registre. Aucun démon Docker requis : adapté aux analyses par lot et aux runners de CI.

Pour un registre Harbor, l'assistant peut lister ce qu'un compte robot voit (projets > dépôts > tags) : vous sélectionnez les images à analyser au lieu de saisir leurs références. Les images sélectionnées sont analysées par lot, l'une après l'autre.

Authentification au registre​

Les images publiques ne demandent aucun identifiant. Pour des dépôts privés, indiquez un nom d'utilisateur et un mot de passe ou jeton (par exemple un compte robot Harbor ou un jeton d'accès au registre). Mots de passe et jetons ne sont pas conservés avec la tâche d'analyse ; seul le nom d'utilisateur est enregistré. Pour un registre derrière une autorité de certification interne, les analyses de registre via l'API acceptent une option, par analyse, qui assouplit la vérification TLS.

Ce qui est détecté​

ÉlémentDétails
Système et paquetsLa distribution de l'image et le nombre de paquets installés, lus dans les bases de paquets Debian / Ubuntu (dpkg) et Alpine (apk).
Services porteurs de cryptographieEnviron 80 définitions de services : serveurs web et proxys (nginx, Apache, HAProxy, Traefik, Caddy...), SSH et VPN (OpenSSH, Dropbear, OpenVPN, strongSwan, WireGuard), messagerie (Postfix, Exim, Dovecot), annuaires, bases de données (PostgreSQL, MySQL / MariaDB, MongoDB, Redis, Cassandra, Elasticsearch...), brokers de messages (Kafka, RabbitMQ, ActiveMQ, Mosquitto), runtimes de conteneurs et d'orchestration, et services embarqués / IoT. Chaque détection indique comment elle a été obtenue (binaire, fichier de configuration ou paquet) et avec quelles preuves.
Configuration cryptographiquePour chaque service détecté, les directives cryptographiques de ses fichiers de configuration : versions de protocole TLS, suites de chiffrement, préférence de chiffrement du serveur, agrafage OCSP, paramètres de session, et les emplacements des fichiers de certificat, de clé privée et d'AC qu'elles référencent. Chaque directive est rattachée à une propriété normalisée pour comparer les services entre eux.

Les résultats s'affichent par conteneur ou par image (paquets, services détectés, directives extraites, preuves, avertissements d'analyse) et se téléchargent en JSON. Les analyses tournent comme des tâches côté serveur : vous pouvez quitter la page et revenir au résultat.

Limites​

Artefacts compilés : voir l'analyse des binaires

La détection de services décrite ci-dessus lit les bases de paquets et les fichiers de configuration. La cryptographie contenue dans les artefacts compilés de l'image (exécutables et bibliothèques ELF, PE et Mach-O, assemblies .NET, classes Java et archives JAR / WAR / EAR) est inventoriée par l'analyse des binaires, que chaque analyse d'image exécute aussi sur le système de fichiers de l'image ; ses résultats apparaissent par conteneur sous Crypto in compiled artefacts. Consultez cette page pour ce qu'elle lit, ses niveaux de confiance et ses limites. Les fichiers de certificats et de clés sont localisés via la configuration qui les référence ; leur contenu n'est pas lu par la détection de services.

LimiteDétails
Inventaire des paquetsBases de paquets Debian / Ubuntu et Alpine. Les services restent détectés sur les autres distributions, mais le nombre de paquets n'est pas lu.
Taille d'imageLes analyses de registre s’arrêtent au-delà d’un plafond de téléchargement des couches (500 Mio par défaut, ajustable par analyse).
SignaturesLes signatures d'images (cosign, Notary) ne sont pas vérifiées par cette analyse.
Réseaux privésLes registres sur des adresses privées sont bloqués, sauf si l'administrateur de votre plateforme les autorise pour votre déploiement.
Astuce

Pour inventorier les certificats et keystores eux-mêmes (PEM, DER, PKCS#12, JKS), utilisez l'analyse du système de fichiers sur l'hôte ou sur une image montée. Pour les artefacts stockés dans JFrog Artifactory, y compris les images de conteneurs et les dépendances Java, utilisez la source JFrog Artifactory.

Comment lancer l'analyse​

1

Ouvrir le Docker Scan

Dans le Cockpit, ouvrez le module PQC Readiness et son onglet Docker Scan. Il requiert la permission de créer des analyses PQC.

2

Choisir le mode

Choisissez Conteneurs en cours d'exécution, Récupérer et analyser une image ou Analyser depuis un registre (sans Docker).

3

Sélectionner ce qu'il faut analyser

Cochez des conteneurs en cours d'exécution, ou saisissez une référence d'image comme harbor.example.com/team/api:1.0 ou nginx:alpine avec d'éventuels identifiants, ou parcourez un registre Harbor et sélectionnez des tags.

4

Consulter le résultat

Examinez les services et directives détectés par image, et téléchargez le rapport JSON.