Supply Chain Security Kubernetes - Sécuriser la chaîne d'approvisionnement

La supply chain security représente 20% du CKS et couvre la réduction de l'empreinte des images, la compréhension de la chaîne d'approvisionnement, la sécurisation des artefacts et l'analyse statique des workloads et images. Ce guide se concentre sur cinq pratiques concrètes : images minimales, scan de vulnérabilités, SBOM, signature d'images et contrôle d'admission.

Ces cinq pratiques couvrent le socle, mais elles n'ont de valeur qu'insérées dans une chaîne plus large : l'intégration continue, le stockage d'artefacts et les contrôles d'admission.

La sécurité de la chaîne d'approvisionnement est le domaine le plus large de la CKS, avec 20 % de l'épreuve. Un point de méthode compte pour bien réviser : le programme officiel décrit des compétences, réduire l'empreinte des images, sécuriser les artefacts, analyser statiquement, contrôler l'admission, et n'impose aucun outil. Ce guide suit donc cette structure par objectif, et les outils qui y apparaissent sont des moyens interchangeables.

Prérequis

Cluster Kubernetes fonctionnel avec accès cluster-admin
Bases Docker/conteneurs (build d'images)
kubectl configuré
Notions de sécurité (CVE, vulnérabilités)

Qu'est-ce que la supply chain d'une image ?

La chaîne d'approvisionnement d'une image conteneur couvre tout le cycle de vie avant déploiement :

Chaîne d'approvisionnement d'une image conteneur, étapes et contrôles de sécurité

Une attaque sur la chaîne d'approvisionnement compromet n'importe quel maillon : une dépendance malveillante, une construction piratée, une image modifiée en transit, ou un registre non authentifié.

Règle d'or : ne jamais faire confiance à une image simplement parce qu'elle « fonctionne ». Une image qui fonctionne peut quand même contenir des CVE critiques ou avoir été altérée.

1. Minimiser l'empreinte des images de base

C'est la première étape parce que c'est la seule qui retire du risque au lieu d'en ajouter la détection. Toutes les mesures qui suivent, signature, analyse, SBOM, s'appliquent à ce que contient l'image ; réduire ce contenu réduit d'autant ce qu'elles ont à couvrir.

Le gain se mesure immédiatement : un paquet absent de l'image ne génère aucune alerte de vulnérabilité, ne demande aucune mise à jour, et ne sert d'aucun levier à qui parvient à exécuter du code dans le conteneur.

Pourquoi les images légères réduisent la surface d'attaque

Une image contenant apt, bash, curl et des outils système offre à un attaquant de nombreux leviers s'il parvient à s'exécuter dans le conteneur. Une image distroless ne contient que le runtime et votre binaire.

Type d'image	Taille	Surface d'attaque	Cas d'usage
`ubuntu:22.04`	~70 Mo	Élevée (shell, apt, utils)	Développement
`alpine:3.19`	~7 Mo	Modérée (shell BusyBox)	Usage général
`gcr.io/distroless/static`	~2 Mo	Minimale (pas de shell)	Go, binaires statiques
`gcr.io/distroless/base`	~20 Mo	Très faible (glibc seulement)	C, C++, Java
`scratch`	0 Mo	Minimale côté base image (la sécurité dépend toujours du binaire embarqué)	Binaires entièrement statiques

Build multi-stage : compiler sans embarquer les outils

Le build multi-stage permet de compiler dans une image "build" complète et de ne copier que le binaire final dans une image minimale :

# Étape 1 : compilation (image complète)
FROM golang:1.23 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o myapp .

# Étape 2 : image finale minimale (distroless)
FROM gcr.io/distroless/static-debian12:nonroot@sha256:afa5c872c891853ca7fcf1f12c3edb23f7eeef36189728842dd51042ff57f7ab
COPY --from=builder /app/myapp /myapp
USER nonroot:nonroot
ENTRYPOINT ["/myapp"]

Bonnes pratiques images

Ces quatre règles portent toutes sur la même question : à quel point l'image que vous déployez aujourd'hui sera-t-elle identique à celle que vous avez testée hier. Un tag est un pointeur mutable côté registry, il peut être réaffecté sans que rien ne change dans votre manifeste ; un digest est le condensat du contenu, il ne peut pas mentir. Retenez la hiérarchie : latest ne garantit rien, un tag de version garantit une intention, un digest garantit le contenu.

PIN les versions : nginx:1.25.3 plutôt que nginx:latest, une mise à jour peut introduire des CVE
Utiliser le digest SHA256 pour garantir l'immuabilité : nginx@sha256:abc123...
Ne pas installer de debuggers dans les images de production (gdb, strace, tcpdump)
Nettoyer le cache dans le même RUN : apt-get install -y curl && rm -rf /var/lib/apt/lists/*

# Recommandé : image référencée par digest, donc immuable
FROM nginx@sha256:67f9a4f10d147a6e04629340e6493c9703300ca23a2f7f3aa56fe615d75d31ca

# À proscrire : latest n'est pas reproductible
FROM nginx:1.31.3

2. Scanner les vulnérabilités

Avant toute chose : scanner vos images pour détecter les CVE (Common Vulnerabilities and Exposures) connues.

L'incident Trivy de mars 2026, et ce qu'il change ici

En mars 2026, l'écosystème Trivy a subi une compromission en plusieurs vagues : publication d'un trivy v0.69.4 malveillant, compromission des tags de trivy-action, exposition de setup-trivy, puis images Docker Hub malveillantes v0.69.5 et v0.69.6. Aqua a recommandé de considérer comme compromis tous les secrets accessibles aux pipelines touchés.

L'épisode illustre exactement ce que ce chapitre enseigne : un outil de sécurité de la chaîne d'approvisionnement fait partie de cette chaîne, et se compromet comme n'importe quel autre maillon. Il justifie aussi la position retenue ici. Les commandes Trivy restent dans ce guide, parce qu'elles servent à lire les pipelines existants et qu'elles sont omniprésentes dans les supports de préparation, mais le chemin recommandé pour un nouveau déploiement passe par un autre scanner.

Scanner avec Grype, mon choix principal

Je le privilégie pour son intégration avec Syft, pour sa priorisation du risque réel, appuyée sur EPSS, KEV et OpenVEX, et pour sa capacité à scanner images, systèmes de fichiers et SBOM indifféremment.

# Installation par binaire officiel vérifié (empreinte SHA256)
GRYPE_VERSION=0.111.0
base="https://github.com/anchore/grype/releases/download/v${GRYPE_VERSION}"
curl -sSfLO "${base}/grype_${GRYPE_VERSION}_linux_amd64.tar.gz"
curl -sSfLO "${base}/grype_${GRYPE_VERSION}_checksums.txt"
grep "grype_${GRYPE_VERSION}_linux_amd64.tar.gz" "grype_${GRYPE_VERSION}_checksums.txt" | sha256sum -c -
sudo tar -C /usr/local/bin -xzf "grype_${GRYPE_VERSION}_linux_amd64.tar.gz" grype

# Scanner une image
grype nginx:1.25.3

# Scanner avec seuil de sévérité (fail si CRITICAL détecté)
grype nginx:1.25.3 --fail-on critical

# Format JSON pour CI/CD
grype nginx:1.25.3 -o json > results.json

Scanner avec Trivy, culture écosystème

Vous croiserez ces commandes dans la quasi-totalité des pipelines existants et des supports de préparation au CKS, ce qui suffit à justifier de les connaître. Deux options méritent une explication : --ignore-unfixed masque les CVE pour lesquelles aucun correctif n'est publié, utile pour ne pas bloquer un build sur un problème que personne ne peut résoudre, mais dangereux si vous l'activez sans suivre ces vulnérabilités par ailleurs. --exit-code 1 est ce qui transforme le scan en garde-fou : sans lui, Trivy affiche les CVE et le job reste vert.

# Scanner une image
trivy image nginx:1.25.3

# Ignorer les CVE non fixées
trivy image --ignore-unfixed nginx:1.25.3

# Format pour CI/CD
trivy image --exit-code 1 --severity CRITICAL nginx:1.25.3

Une précision utile si vous révisez sur plusieurs supports : vous y verrez Trivy presque partout, et vous pourriez en conclure qu'il est au programme. Il ne l'est pas. Le curriculum officiel décrit la compétence, analyser une image et statuer sur le résultat, sans désigner d'outil. Savoir lire une sortie Trivy reste utile, en faire le seul scanner que vous connaissez serait une erreur de révision.

La limite à retenir avant de passer à la suite : une image sans CVE connue n'est pas une image fiable. Elle peut avoir été altérée, venir d'une source compromise, ou transporter du code malveillant qu'aucune base ne référence, l'incident Trivy en étant la démonstration directe. Le scan répond à une question précise, « quelles failles connues contient cette image », et il ne remplace ni la signature, qui établit l'intégrité, ni la provenance, qui établit l'origine, ni la politique d'admission, qui décide de ce qui entre dans le cluster.

Pour approfondir le scanning et comprendre les scores CVE : Comprendre les CVE, CVSS et EPSS.

3. Générer et exploiter un SBOM

Un SBOM (Software Bill of Materials) est l'inventaire exhaustif de tous les composants d'une image : packages OS, bibliothèques, versions, licences. C'est la liste d'ingrédients de votre logiciel.

# Générer un SBOM avec Syft
syft nginx:1.25.3 -o cyclonedx-json > nginx-sbom.json

# Utiliser le SBOM pour scanner avec Grype
grype sbom:nginx-sbom.json

# Générer et scanner en une commande
syft nginx:1.25.3 | grype

Voir le guide SBOM complet pour les formats SPDX/CycloneDX et l'intégration CI/CD.

4. Signer et vérifier les images avec Cosign

La signature d'images garantit l'authenticité (l'image provient bien du build attendu) et l'intégrité (elle n'a pas été modifiée). Cosign de Sigstore est l'outil standard.

Signer une image

Un guide de supply chain qui installerait son propre outil sans vérification serait contradictoire : le bloc ci-dessous épingle donc une version précise et contrôle l'empreinte SHA256 publiée par le projet avant de rendre le binaire exécutable. Sigstore publie ce fichier sous le nom cosign_checksums.txt dans chaque release. La commande cosign generate-key-pair demande ensuite une passphrase : elle protège cosign.key, qui est la seule chose à ne jamais laisser sortir de votre coffre.

# Installation Cosign : version épinglée + vérification d'empreinte
COSIGN_VERSION=3.1.3
base="https://github.com/sigstore/cosign/releases/download/v${COSIGN_VERSION}"
curl -sSfLO "${base}/cosign-linux-amd64"
curl -sSfLO "${base}/cosign_checksums.txt"
grep " cosign-linux-amd64$" cosign_checksums.txt | sha256sum -c -
chmod +x cosign-linux-amd64 && sudo mv cosign-linux-amd64 /usr/local/bin/cosign

# Générer une paire de clés
cosign generate-key-pair
# Produit cosign.key (privée) et cosign.pub (publique)

# Signer par digest (recommandé : le tag peut être réaffecté)
cosign sign --key cosign.key registry.example.com/myapp@sha256:abc123...

# Signer par tag (acceptable mais moins robuste)
cosign sign --key cosign.key registry.example.com/myapp:1.0.0

# Vérifier la signature
cosign verify --key cosign.pub registry.example.com/myapp:1.0.0

Vérifier que la signature protège vraiment

Une signature qui se vérifie ne prouve rien : il faut voir la vérification échouer quand elle doit échouer. Les trois cas ci-dessous ont été joués sur un registre local avec cosign 3.1.3, et ils rendent trois codes de retour différents.

Avec la bonne clé, cosign détaille ce qu'il a contrôlé :

Verification for localhost:5555/lab-signe:1.0.0 --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The signatures were verified against the specified public key

Situation	Code de retour	Message
Signature valide	0	le détail des contrôles ci-dessus
Mauvaise clé publique	1	`no matching attestations: failed to verify log inclusion`
Image non signée	10	`no signatures found`

La distinction entre 1 et 10 est exploitable : une image non signée signale un oubli dans la chaîne de build, une signature qui ne correspond pas signale un problème d'identité, et ces deux incidents n'appellent pas la même réaction.

Où vit la signature

Elle n'est pas dans l'image : c'est un artefact distinct, poussé dans le même dépôt sous un tag dérivé du digest. Après signature, le dépôt contient deux tags :

curl -s http://localhost:5555/v2/lab-signe/tags/list

{"name":"lab-signe","tags":["sha256-7c38f24774e3cbd906d2d33c38354ccf787635581c122965132c9bd309754d4a","1.0.0"]}

Deux conséquences pratiques. Copier une image d'un registre à l'autre ne transporte pas sa signature, sauf à copier aussi cet artefact : c'est la cause la plus fréquente d'une vérification qui échoue après une migration de registre. Et le tag étant dérivé du digest, resigner une image reconstruite produit un nouvel artefact, l'ancien restant en place.

Vérification dans Kubernetes avec ImagePolicyWebhook

L'ImagePolicyWebhook est un admission controller historique, désactivé par défaut, qui délègue la décision d'autorisation à un backend webhook externe. Il reste documenté et utile pour comprendre les mécanismes de contrôle d'images, mais sur les clusters récents on rencontre davantage des admission webhooks génériques (ValidatingAdmissionWebhook) ou des moteurs de policy comme Kyverno.

Un point d'architecture qui change la façon d'évaluer ce mécanisme : ImagePolicyWebhook ne décide de rien par lui-même. Il transmet la demande à un service externe joignable en TLS, qui autorise ou refuse. La sécurité réelle du dispositif est donc celle de ce backend, de sa disponibilité et des règles qu'il applique, pas celle du contrôleur Kubernetes qui se contente de relayer.

La mise en place se fait en deux fichiers. D'abord les drapeaux du kube-apiserver, à ajouter dans /etc/kubernetes/manifests/kube-apiserver.yaml sur chaque nœud du plan de contrôle : le premier active le plugin, le second indique où lire sa configuration. Une erreur ici empêche l'apiserver de redémarrer, gardez une copie du manifeste avant de le modifier.

--enable-admission-plugins=...,ImagePolicyWebhook
--admission-control-config-file=/etc/kubernetes/admission/admission-config.yaml

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: ImagePolicyWebhook
    configuration:
      imagePolicy:
        kubeConfigFile: /etc/kubernetes/admission/webhook-kubeconfig.yaml
        allowTTL: 50
        denyTTL: 50
        retryBackoff: 500
        defaultAllow: false  # Bloquer si le webhook est inaccessible

Un mot sur le choix du mode de signature, puisque deux existent et que le second n'est pas toujours présenté. La signature par clé, celle que ce guide détaille, a l'avantage d'être explicite : vous voyez ce que vous générez et ce que vous vérifiez. Elle vous laisse cependant avec une clé privée longue durée à protéger et à faire tourner, ce qui est précisément la matière des incidents de chaîne d'approvisionnement.

La signature keyless supprime ce problème en s'appuyant sur une identité OIDC, celle de votre exécution GitHub Actions ou GitLab CI, et sur un certificat éphémère. C'est ce qu'il faut viser pour une chaîne moderne. Gardez la signature par clé pour comprendre les mécanismes et pour les environnements isolés, où aucun fournisseur OIDC n'est joignable. Le guide Cosign détaille les deux.

5. Limiter les registries autorisées

En plus de la signature, on peut restreindre Kubernetes pour n'accepter que des images venant de registries approuvées. C'est la voie moderne et recommandée : les controllers de policy comme Kyverno ou Gatekeeper sont activés par défaut et offrent plus de flexibilité qu'ImagePolicyWebhook.

Avec Kyverno (recommandé)

La politique ci-dessous s'écrit avec l'API policies.kyverno.io/v1, disponible depuis Kyverno 1.14 et servie par les versions 1.18.x. Deux champs portent tout le comportement : validationActions: [Deny] refuse la création plutôt que de se contenter d'un rapport, et l'expression CEL parcourt tous les conteneurs du Pod avec all(...), ce qui bloque aussi un Pod dont un seul conteneur viendrait d'ailleurs. Attention, matchConstraints ne cible ici que les Pods : un Deployment passera, puis son Pod sera refusé, avec un message d'erreur qui apparaîtra dans le ReplicaSet et non dans le Deployment.

apiVersion: policies.kyverno.io/v1
kind: ValidatingPolicy
metadata:
  name: restrict-registries
spec:
  validationActions: [Deny]
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  validations:
    - expression: >-
        object.spec.containers.all(c,
          c.image.startsWith('registry.example.com/')
        )
      message: "Seules les images de registry.example.com sont autorisées."

Avec Gatekeeper (OPA)

Gatekeeper sépare le code de la politique de son paramétrage. Le manifeste ci-dessous est une Constraint, c'est-à-dire une instance : il suppose que le ConstraintTemplate K8sAllowedRepos, fourni par la bibliothèque officielle gatekeeper-library, a déjà été appliqué au cluster. Sans lui, l'API rejette le manifeste avec une erreur de ressource inconnue. Le champ repos fonctionne par préfixe de chaîne, pas par expression régulière : une entrée sans barre oblique finale autoriserait aussi un registry dont le nom commence pareil.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: allowed-repos
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    repos:
      - "registry.example.com/"
      - "gcr.io/distroless/"

→ Voir Guide Kyverno et Guide Gatekeeper.

6. Analyser les manifestes avant de les appliquer

Scanner une image cherche des vulnérabilités connues dans des paquets. Cela ne dit rien d'un manifeste qui déclare privileged: true ou monte la racine du nœud : le paquet peut être parfaitement à jour, le déploiement reste dangereux. Le syllabus CKS nomme les deux outils de référence, Kubesec et KubeLinter.

Ils ne font pas le même travail. Le démontrer sur un manifeste volontairement faible, portant privileged: true, runAsUser: 0, une image en latest et un hostPath sur la racine, suffit à comprendre lequel choisir :

Outil	Ce qu'il rend	Sur le manifeste faible	Une fois durci
kube-linter 0.8.3	une liste de défauts nommés, avec la remédiation	8 erreurs, sortie 1	2 erreurs restantes
kubesec 2.14.2	une note chiffrée et un verdict	-30 points, sortie 2	+13, « Passed », sortie 0

kube-linter lint deployment.yaml
kubesec scan deployment.yaml

Retenez la différence d'usage : kube-linter énumère, ce qui sert à corriger ; kubesec note, ce qui sert à poser un seuil en intégration continue.

Deux outils voisins font le même travail sous un autre angle : kube-score, pensé pour l'intégration continue, et Polaris, qui surveille en continu un cluster vivant.

7. Vérifier les binaires de la plateforme

La chaîne d'approvisionnement ne s'arrête pas aux images : le kubectl que vous installez sur un poste d'administration en fait partie. Le syllabus CKS le demande explicitement, « vérifier les binaires de la plateforme avant déploiement ».

Kubernetes publie la somme de contrôle de chaque binaire à côté du binaire :

VER=v1.37.0
curl -LO "https://dl.k8s.io/release/${VER}/bin/linux/amd64/kubectl"
curl -LO "https://dl.k8s.io/release/${VER}/bin/linux/amd64/kubectl.sha256"
echo "$(cat kubectl.sha256)  kubectl" | sha256sum --check

kubectl: OK

C'est le code de sortie qui compte, pas le message. Mesuré sur le binaire 1.37.0 : 0 quand le fichier est intact, 1 dès qu'il est altéré, et un seul octet ajouté à un binaire de 61 Mo suffit à le faire basculer. Dans un script, testez ce code plutôt que de chercher le mot OK dans la sortie.

Workflow supply chain complet

En production et pour le CKS, voici le cycle recommandé :

Build avec une image de base minimale (distroless/alpine) et build multi-stage
Scanner l'image avant le push : grype myapp:1.0.0 --fail-on high
Générer le SBOM et l'attacher à l'image : syft myapp:1.0.0 -o cyclonedx-json
Pinner par digest : référencer l'image par son SHA256 pour garantir l'immuabilité
Signer par digest : cosign sign --key cosign.key registry/myapp@sha256:abc123...
Pousser vers un artifact repository privé et contrôlé (registry interne approuvée)
Vérifier à l'admission : politique Kyverno/Gatekeeper ou ImagePolicyWebhook

Dépannage

Les quatre situations ci-dessous ont un point commun : le cluster se comporte exactement comme il a été configuré, et c'est la configuration qui pose problème. Les deux premières lignes concernent des blocages visibles, les deux dernières sont plus pernicieuses car rien n'échoue : le pipeline reste vert alors que le contrôle attendu n'a jamais eu lieu. Vérifiez ces deux-là en priorité si votre chaîne semble « trop » silencieuse.

Symptôme	Cause probable	Solution
Pod bloqué par ImagePolicyWebhook	Webhook inaccessible avec `defaultAllow: false`	Vérifier la disponibilité du webhook
Signature non vérifiée	Mauvaise clé publique ou image re-taguée	Re-signer ou utiliser le digest SHA256
CVE CRITICAL non bloquantes	Seuil pas configuré	Ajouter `--fail-on critical` dans le CI/CD
Images `latest` en production	Convention de tag permissive	Politique Kyverno pour interdire `latest`

Testez vos connaissances

Les dix questions ci-dessous sont tirées de la banque CKS et couvrent uniquement le domaine supply chain. Elles insistent volontairement sur les distinctions que l'examen exploite : scan contre signature, tag contre digest, et contrôle d'admission contre contrôle en CI.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

8 min.

70% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin

À retenir

Images minimales : distroless > alpine > ubuntu, build multi-stage ; scratch réduit l'empreinte base mais la sécurité dépend du binaire embarqué
Scanner avant push : Grype (mon choix prod, EPSS, KEV, OpenVEX) ou Trivy (culture écosystème)
Le scan ne suffit pas : une image sans CVE peut rester malveillante ou compromise, compléter avec signature et admission
SBOM : inventaire exhaustif avec Syft, re-scannable séparément sans rebuild
Signature : Cosign, de préférence par digest et keyless en production
Contrôle admission : Kyverno/Gatekeeper comme voie moderne ; ImagePolicyWebhook comme mécanisme historique
Registries : restreindre aux sources de confiance, préférer un artifact repository interne
CI/CD : évitez les installations d'outils à la volée depuis Internet en production

Pour aller plus loin

Audit Logs : La trace des déploiements d'images, utile dès qu'un artefact se révèle compromis.
Falco : La détection à l'exécution quand une image malveillante a franchi les contrôles amont.