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 doivent s'insérer dans une chaîne plus large incluant le CI/CD, le stockage d'artefacts et les contrôles d'admission.

Contexte CKS

La supply chain security est le domaine à 20% du CKS le plus large. Le programme officiel décrit des compétences et objectifs (réduction d'empreinte, sécurisation des artefacts, analyse statique, contrôle d'admission), pas un scanner imposé. Trivy reste un outil très présent dans les supports et démonstrations autour de la sécurité Kubernetes.

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 :

Une attaque supply chain compromet n'importe quel maillon : une dépendance malveillante, un build piraté, une image modifiée en transit, ou une registry non authentifiée.

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

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

Glissez pour voir

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 :

Dockerfile

# É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
COPY --from=builder /app/myapp /myapp
USER nonroot:nonroot
ENTRYPOINT ["/myapp"]

Distroless : utilisateur non privilégié

Quand l'image le permet, privilégiez une variante :nonroot ou définissez explicitement un utilisateur non privilégié. Pour les images distroless, le tag :nonroot fait tourner le conteneur avec l'UID 65532 au lieu de root, ce qui respecte le principe du moindre privilège.

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.

Incident supply chain Trivy, mars 2026

En mars 2026, l'écosystème Trivy a subi une compromission majeure : publication malveillante de trivy v0.69.4, compromission des tags de trivy-action, exposition de setup-trivy, puis images Docker Hub malveillantes v0.69.5 et v0.69.6. Aqua recommande de traiter comme compromis les secrets accessibles aux pipelines affectés.

Dans ce guide, je conserve Trivy pour la culture écosystème et la préparation, mais je privilégie désormais Grype comme scanner principal en production. Voir le guide Trivy pour les détails.

Scanner avec Grype, mon choix principal

Je le privilégie pour son intégration avec Syft, son accent sur EPSS, KEV, risk scoring et OpenVEX, et sa capacité à scanner images, file systems et SBOMs 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

Trivy dans les préparations CKS

Trivy reste un outil très présent dans les supports et démonstrations autour de la sécurité Kubernetes, mais le programme officiel du CKS décrit surtout des compétences et objectifs, pas un scanner unique imposé. Je conserve ses commandes pour la culture générale et la lecture de pipelines existants.

Le scan ne garantit pas l'intégrité

Une image peut être exempte de CVE critiques connues et rester non fiable : elle peut avoir été altérée, provenir d'une source compromise ou transporter du code malveillant non référencé. L'incident Trivy lui-même l'illustre. Le scan de vulnérabilités ne remplace ni la signature, ni la provenance, ni les politiques d'admission.

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.2
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é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.

L'intelligence est dans le backend

ImagePolicyWebhook ne prend pas de décision par lui-même. Il transmet la demande à un service backend TLS externe qui décide d'autoriser ou refuser. La sécurité réelle dépend donc de ce backend, pas du contrôleur Kubernetes seul.

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.

Drapeaux à ajouter au kube-apiserver

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

/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

defaultAllow: false en production

En production, préférez defaultAllow: false (comportement fail-closed) : une panne du backend laisse autrement passer toutes les images non vérifiées. En environnement de lab ou de bootstrap, vous pouvez temporairement opter pour defaultAllow: true, mais repassez en fail-closed avant la mise en production.

Signature keyless

Pour la production moderne, la signature keyless (via OIDC, GitHub Actions, GitLab CI) est souvent préférable car elle évite de gérer des clés longue durée. La signature par clé reste utile pour comprendre les mécanismes et pour les environnements isolés sans OIDC.

Pour aller plus loin sur la signature : Guide Cosign complet.

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.

Workflow supply chain complet

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

1. Build avec une image de base minimale (distroless/alpine) et build multi-stage

2. Scanner l'image avant le push : grype myapp:1.0.0 --fail-on high

3. Générer le SBOM et l'attacher à l'image : syft myapp:1.0.0 -o cyclonedx-json

4. Pinner par digest : référencer l'image par son SHA256 pour garantir l'immuabilité

5. Signer par digest : cosign sign --key cosign.key registry/myapp@sha256:abc123...

6. Pousser vers un artifact repository privé et contrôlé (registry interne approuvée)

7. 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

Glissez pour voir

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

10 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

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À 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

Prochaines étapes

Scanner les vulnérabilités (Grype) Guide approfondi sur le scanning d'images et l'analyse de CVE

Signer les images avec Cosign Signature keyless, attestations SBOM, intégration CI/CD

SBOM : Software Bill of Materials Générer, distribuer et exploiter un SBOM avec Syft

Kyverno, Politiques de sécurité Bloquer les images non conformes avec des politiques as code

×

📖 Voir la documentation →