Aller au contenu

Quiz : Construire des images de conteneurs

100 Comprendre ⏱ 30 min dockerbuildkit

Ce quiz valide le niveau 100 (Comprendre) des notions du cours Construire des images de conteneurs. Visez au moins 16 bonnes réponses sur 20 ; chaque réponse renvoie à la leçon à relire.

Bases et multi-étapes

1. Debian 13 affiche 48 vulnérabilités hautes et Ubuntu 24.04 une seule. Que peut-on en conclure ?

  • a) Ubuntu est beaucoup plus sûre que Debian
  • b) Rien sans regarder les vulnérabilités corrigeables : chaque distribution publie ses vulnérabilités selon sa propre politique
  • c) Debian n'est pas maintenue
  • d) Trivy ne sait pas analyser Ubuntu
Réponse

b. Debian publie toutes les vulnérabilités connues de ses paquets, y compris celles qu'elle ne corrigera pas en version stable. Le chiffre utile est celui des vulnérabilités corrigeables (5 sur 48 pour debian:13-slim au moment de la mesure). Leçon 1.

2. Un binaire copié dans une image Alpine échoue avec exec /outil: no such file or directory, alors que le fichier existe. Quelle est la cause la plus probable ?

Réponse

Le binaire est lié dynamiquement à glibc et cherche son chargeur /lib64/ld-linux-x86-64.so.2, absent d'Alpine (musl). file ou readelf -l le confirment. Leçon 1.

3. Dans un Dockerfile multi-étapes, qu'est-ce qui se retrouve dans l'image livrée ?

Réponse

Uniquement les couches de l'étape finale (ou de celle désignée par --target) : son image de départ, ses instructions, et ce qu'elle copie explicitement avec COPY --from. Compilateurs et outils des étapes intermédiaires restent dans l'atelier. Leçon 2.

4. Un Dockerfile contient une étape test dont l'étape finale ne dépend pas. Est-elle exécutée par docker build . avec BuildKit ?

Réponse

Non : BuildKit ne construit que les étapes nécessaires à la cible. L'étape test ne s'exécute qu'avec --target test (l'ancien constructeur, lui, exécutait toutes les étapes). Leçon 2.

Cache et secrets

5. Pourquoi RUN --mount=type=cache,target=/root/.cache/pip pip install ... accélère-t-il une construction après l'ajout d'une dépendance, alors que l'instruction est de toute façon rejouée ?

Réponse

Le répertoire monté persiste d'une construction à l'autre : pip y retrouve les paquets déjà téléchargés et les roues déjà compilées (31,5 s ramenées à 4,8 s dans la leçon). Ce répertoire n'entre pas dans l'image. Leçon 3.

6. Un agent de CI neuf importe un cache exporté en mode=min pour un Dockerfile multi-étapes, et recompile tout. Pourquoi ?

Réponse

mode=min n'exporte que les couches de l'image finale ; celles des étapes intermédiaires (la compilation) n'y sont pas. Il faut mode=max. Leçon 3.

7. Un ARG DATE_CONSTRUCTION est déclaré en tête d'étape et reçoit l'heure courante. Quel effet sur le cache ?

Réponse

Toutes les instructions RUN qui suivent sa déclaration sont invalidées à chaque construction, même si elles n'utilisent pas l'argument : les arguments déclarés entrent dans leur clé de cache. Leçon 3.

8. Où se retrouve un mot de passe passé par --build-arg et utilisé dans un RUN ?

  • a) Nulle part, un ARG n'est pas un ENV
  • b) Dans l'historique de l'image, et dans l'attestation de provenance si elle est en mode=max
  • c) Seulement dans les journaux de la CI
  • d) Dans la couche produite par le RUN
Réponse

b. docker history montre RUN |1 VAR=valeur ... et la ligne ARG, et la provenance complète enregistre les arguments. La bonne méthode est le montage de secret. Leçon 4.

9. Avec RUN --mount=type=secret,id=pipconf,target=/etc/pip.conf, le secret change mais l'instruction reste CACHED. Pourquoi, et quel risque ?

Réponse

Le contenu d'un secret ne fait pas partie de la clé de cache. Un secret expiré peut donc passer inaperçu tant que le cache sert, jusqu'au jour où l'instruction doit être rejouée. Une construction périodique sans cache le détecte. Leçon 4.

Images minimales et reproductibilité

10. Un binaire Go statique dans une image scratch échoue avec x509: certificate signed by unknown authority. Que manque-t-il ?

Réponse

Les certificats des autorités de confiance (/etc/ssl/certs/ca-certificates.crt), qu'il faut copier depuis l'étape de construction. Il faut souvent aussi les données de fuseaux horaires et un utilisateur non-root. Leçon 5.

11. Pourquoi un environnement virtuel construit avec python:3.14 ne fonctionne-t-il pas dans gcr.io/distroless/python3-debian13 ?

Réponse

L'image distroless embarque le Python de Debian 13, en version 3.13 et dans /usr/bin ; l'environnement pointe vers /usr/local/bin/python en 3.14, absent. Il faut construire avec le Python de la même distribution. Leçon 5.

12. Deux constructions sans cache des mêmes sources donnent deux empreintes différentes. Citez trois causes typiques.

Réponse

Les dates (création de l'image, dates des fichiers des couches), les fichiers volatils (journaux d'apt et de dpkg, cache de ldconfig), les .pyc horodatés, et les chemins temporaires aléatoires inscrits dans les binaires compilés. Leçon 6.

13. À quoi sert rewrite-timestamp=true en plus de SOURCE_DATE_EPOCH ?

Réponse

SOURCE_DATE_EPOCH seule fixe les dates de la configuration de l'image ; rewrite-timestamp=true réécrit aussi les dates des fichiers des couches, sans quoi un simple répertoire créé pendant la construction suffit à changer l'empreinte. Leçon 6.

14. Que garantit pip install --require-hashes ?

Réponse

Que chaque archive installée a l'une des empreintes listées dans le fichier de dépendances ; toute archive inconnue ou modifiée est refusée. Le fichier de verrouillage devient ainsi un document de sécurité, à relire. Leçon 6.

Multi-architecture, SBOM et signatures

15. Une construction --platform linux/amd64,linux/arm64 échoue sur exec /bin/sh: exec format error dans l'étape arm64. Quelles sont les trois solutions possibles ?

Réponse

Compiler en croisé (étape de construction en FROM --platform=$BUILDPLATFORM, étape finale sans RUN), installer l'émulation QEMU, ou utiliser un nœud de construction ARM natif. La première est à préférer. Leçon 7.

16. Dans un Dockerfile multi-plateformes, RUN GOARCH=$TARGETARCH go build ... produit un binaire amd64 dans la variante arm64. Quel oubli ?

Réponse

L'étape ne déclare pas ARG TARGETARCH : la variable est vide et Go compile pour l'architecture de la machine. Leçon 7.

17. Quelle différence entre un SBOM et une attestation de provenance ?

Réponse

Le SBOM dit ce que contient l'image (composants, versions, purl) ; la provenance dit comment elle a été construite (sources et commit, images de base par empreinte, paramètres, système de construction). Leçon 8.

18. Pourquoi la même image peut-elle donner 184, 20 ou 0 vulnérabilités selon le SBOM analysé ?

Réponse

Les producteurs de SBOM n'expriment pas tous de la même façon les informations dont l'analyseur a besoin pour relier un paquet aux avis de sécurité (paquet source, distribution, propriétés propres à l'outil). Il faut valider la chaîne producteur et consommateur. Leçon 8.

19. Une étiquette 1.0 signée est déplacée vers une autre image. Que répond cosign verify sur l'étiquette ?

Réponse

no signatures found : la signature porte sur une empreinte, pas sur l'étiquette ; la nouvelle image n'a jamais été signée. L'ancienne reste vérifiable par son empreinte. Leçon 9.

20. Dans un workflow GitHub Actions, pourquoi conditionner la publication et la signature à github.event_name == 'push' ?

Réponse

Pour qu'une demande de fusion, éventuellement venue d'un fork, construise et teste sans jamais publier, signer, ni accéder aux secrets ou écrire dans le cache de la branche principale. Leçon 10.

Pour valider les niveaux supérieurs

Le niveau 300 se valide par le lab « Une chaîne d'images de confiance », complété par une revue du Dockerfile et du workflow.

Plan du cours