Supply chain et sécurité des images conteneur Kubernetes

TL;DR : La sécurité images Kubernetes commence bien avant le déploiement. Scannez vos images à chaque étape du pipeline CI/CD, signez-les avec Cosign, utilisez des images de base minimales (Alpine < 5 MB), et appliquez des admission controllers pour bloquer les images non conformes. Une supply chain conteneurs compromise peut exposer l'ensemble de votre infrastructure.

Pour maîtriser ces pratiques de sécurité en production, découvrez la formation LFS460 Principes Fondamentaux de la Sécurité Kubernetes.

Pourquoi la sécurité images Kubernetes est critique en 2026

La sécurité images Kubernetes représente aujourd'hui le premier vecteur d'attaque sur les infrastructures cloud-native. Selon le CNCF Annual Survey 2025, 82% des utilisateurs de conteneurs exécutent Kubernetes en production. Cette adoption massive fait de la supply chain conteneurs une cible privilégiée pour les attaquants.

À retenir : Une image compromise déployée dans votre cluster peut créer une backdoor persistante, exfiltrer des données, ou servir de point d'entrée pour des mouvements latéraux.

Les attaques sur la supply chain logicielle ont augmenté de 742% entre 2019 et 2024. L'incident SolarWinds, les compromissions npm, et les attaques ciblant les registres Docker publics démontrent que la sécurité ne peut plus se limiter au runtime.

Chris Aniszczyk, CTO de la CNCF, affirme : « Kubernetes is no longer experimental but foundational. Soon, it will be essential to AI as well. » (CNCF State of Cloud Native 2026). Cette position centrale exige une approche proactive de la sécurité Kubernetes.

Les 5 piliers de la sécurité images Kubernetes

1. Images de base minimales

Réduisez la surface d'attaque en choisissant des images de base légères. Selon Medium Docker Optimization, les différences sont significatives :

# ❌ Évitez
FROM ubuntu:22.04

# ✅ Préférez
FROM gcr.io/distroless/static-debian12:nonroot

L'objectif est de maintenir vos images microservices sous 200 MB (DevOpsCube Docker Guide). Cette pratique s'intègre dans les bonnes pratiques conteneurisation Docker.

2. Scan de vulnérabilités systématique

Intégrez le scanning à chaque étape de votre pipeline CI/CD :

# GitHub Actions - Scan avec Trivy
- name: Scan image
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: '${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}'
    format: 'sarif'
    severity: 'CRITICAL,HIGH'
    exit-code: '1'

Les outils de référence en 2026 :

• Trivy : Open source, rapide, intégration CI/CD native
• Grype : Anchore, base de données CVE exhaustive
• Snyk Container : Contexte développeur, fix automatiques
• Clair : CoreOS/Red Hat, scanner statique

À retenir : Scannez à trois moments : au build local, avant push au registry, et régulièrement en production pour détecter les nouvelles CVE.

3. Signature et vérification d'images

Signez chaque image pour garantir son intégrité et son origine. Cosign (projet Sigstore) est devenu le standard :

# Générer une clé
cosign generate-key-pair

# Signer une image
cosign sign --key cosign.key registry.example.com/app:v1.2.3

# Vérifier une signature
cosign verify --key cosign.pub registry.example.com/app:v1.2.3

L'intégration avec les admission controllers Kubernetes permet de bloquer automatiquement les images non signées :

apiVersion: policy.sigstore.dev/v1alpha1
kind: ClusterImagePolicy
metadata:
  name: require-signature
spec:
  images:
    - glob: "registry.example.com/**"
  authorities:
    - keyless:
        url: https://fulcio.sigstore.dev
        identities:
          - issuer: https://accounts.google.com
            subject: team@example.com

4. SBOM (Software Bill of Materials)

Générez un SBOM pour chaque image afin de tracer les dépendances et réagir rapidement aux nouvelles vulnérabilités :

# Générer un SBOM avec Syft
syft registry.example.com/app:v1.2.3 -o spdx-json > sbom.json

# Attacher le SBOM à l'image avec Cosign
cosign attach sbom --sbom sbom.json registry.example.com/app:v1.2.3

Le SBOM devient obligatoire dans de nombreux contextes réglementaires (Executive Order US, NIS2 en Europe). Il permet de répondre en heures plutôt qu'en jours à des incidents comme Log4Shell.

5. Registres privés et contrôle d'accès

Centralisez vos images dans un registry privé avec :

• Authentification OIDC/SSO
• RBAC granulaire par namespace/projet
• Politique de rétention automatique
• Réplication géographique
• Scanning intégré

# ImagePullSecrets dans Kubernetes
apiVersion: v1
kind: Secret
metadata:
  name: registry-credentials
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: <base64-encoded-config>
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-sa
imagePullSecrets:
  - name: registry-credentials

Sécurité images Kubernetes : le pipeline CI/CD sécurisé

Un pipeline robuste pour la supply chain conteneurs intègre la sécurité à chaque étape :

┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│   Commit    │───▶│    Build    │───▶│    Test     │───▶│   Deploy    │
│  (pre-hook) │    │ (scan deps) │    │ (scan img)  │    │  (verify)   │
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘
      │                  │                  │                  │
      ▼                  ▼                  ▼                  ▼
   Secrets           Trivy/Grype        Sign avec         Admission
   scanning          SBOM génération    Cosign            Controller

Étape 1 : Analyse des dépendances au build

# GitLab CI example
build:
  stage: build
  script:
    - docker build -t $IMAGE_TAG .
    - trivy fs --severity HIGH,CRITICAL --exit-code 1 .
    - syft $IMAGE_TAG -o cyclonedx-json > sbom.json

Étape 2 : Scan et signature post-build

sign:
  stage: sign
  script:
    - trivy image --exit-code 1 --severity CRITICAL $IMAGE_TAG
    - cosign sign --key $COSIGN_KEY $IMAGE_TAG
    - cosign attach sbom --sbom sbom.json $IMAGE_TAG

Étape 3 : Vérification au déploiement

Utilisez Kyverno ou OPA Gatekeeper pour appliquer des politiques :

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signature
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-signature
      match:
        resources:
          kinds:
            - Pod
      verifyImages:
        - imageReferences:
            - "registry.example.com/*"
          attestors:
            - entries:
                - keys:
                    publicKeys: |
                      -----BEGIN PUBLIC KEY-----
                      ...
                      -----END PUBLIC KEY-----

Cette approche s'aligne avec les principes du déploiement production Kubernetes et les stratégies de monitoring et dépannage.

Admission controllers pour la sécurité images

Les admission controllers sont votre dernière ligne de défense.

Politiques essentielles à implémenter

# Pod Security Standards - Restricted
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

À retenir : Combinez Pod Security Standards (natif Kubernetes) avec Kyverno ou Gatekeeper pour des politiques personnalisées sur les images.

Sécuriser la supply chain conteneurs en runtime

La sécurité ne s'arrête pas au déploiement. Le runtime monitoring détecte les comportements anormaux :

Falco pour la détection d'intrusion

# Règle Falco personnalisée
- rule: Unexpected process in container
  desc: Detect shell spawned in container
  condition: >
    spawned_process and container and
    shell_procs and proc.pname != "entrypoint.sh"
  output: >
    Shell spawned in container (user=%user.name container=%container.name
    image=%container.image.repository command=%proc.cmdline)
  priority: WARNING

Sysdig Secure et Tetragon

Pour les environnements critiques, ces outils offrent :

• Analyse comportementale basée sur eBPF
• Blocage en temps réel
• Forensics post-incident
• Intégration SIEM

Ces pratiques complètent la configuration ConfigMaps et Secrets et le RBAC Kubernetes.

Checklist sécurité images Kubernetes

Avant le build :

• [ ] Utiliser une image de base minimale (distroless, Alpine)
• [ ] Scanner les dépendances applicatives
• [ ] Configurer les secrets via variables d'environnement CI (jamais en dur)

Au build :

• [ ] Multi-stage build pour réduire la taille
• [ ] Utilisateur non-root dans le Dockerfile
• [ ] Labels OCI pour traçabilité

FROM golang:1.22 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o /app/bin

FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder /app/bin /app
USER nonroot:nonroot
ENTRYPOINT ["/app"]

Après le build :

• [ ] Scan de vulnérabilités (Trivy/Grype)
• [ ] Génération SBOM
• [ ] Signature avec Cosign
• [ ] Push vers registry privé

Au déploiement :

• [ ] Admission controller vérifie signature
• [ ] Pod Security Standards appliqués
• [ ] ImagePullPolicy: Always
• [ ] Pas de :latest en production

En production :

• [ ] Monitoring runtime (Falco)
• [ ] Re-scan périodique des images déployées
• [ ] Alertes sur nouvelles CVE critiques

Cette checklist s'applique aux workflows de pipeline CI/CD Kubernetes et aux stratégies GitOps.

Formation et certification pour maîtriser la sécurité images

La complexité de la supply chain conteneurs exige une formation structurée. Selon 70% des organisations utilisent Kubernetes dans des environnements cloud, la plupart avec Helm. Cette adoption massive crée un besoin urgent de professionnels certifiés.

La certification CKS (Certified Kubernetes Security Specialist) valide les compétences en :

• Supply chain security et image scanning
• Runtime security et detection
• Cluster hardening et network policies
• Minimisation de la surface d'attaque

À retenir : La CKS exige le CKA comme prérequis. Préparez-vous avec la formation LFS460 sur 4 jours.

Pour les développeurs, la préparation au CKAD inclut les bonnes pratiques de containerisation. Les administrateurs commenceront par la préparation au CKA.

Outils et ressources pour la sécurité images

Le guide complet Formation Kubernetes détaille les parcours d'apprentissage adaptés à chaque profil.

Passez à l'action : sécurisez votre supply chain

La sécurité images Kubernetes n'est plus optionnelle. Avec 71 % des entreprises Fortune 100 utilisant Kubernetes en production (CNCF Project Journey Report), les attaquants ciblent activement ces infrastructures.

Vos prochaines étapes :

1. Auditez votre pipeline actuel avec la checklist ci-dessus
2. Implémentez le scanning automatisé en CI/CD
3. Déployez des admission controllers pour bloquer les images non conformes
4. Formez vos équipes aux pratiques de sécurité cloud-native

Formations SFEIR Institute recommandées

• LFS460 Principes Fondamentaux de la Sécurité Kubernetes : 4 jours pour maîtriser la sécurité des clusters, des images, et préparer la certification CKS
• LFS458 Administration Kubernetes : Les fondations pour comprendre l'architecture avant de sécuriser
• LFD459 Kubernetes pour les développeurs : Bonnes pratiques de containerisation pour les développeurs

Contactez nos conseillers pour construire un parcours adapté à votre équipe et explorer les possibilités de financement OPCO.