Trivy, Cosign et supply chain security Kubernetes CKS 2026

📍 Article principal du cluster : CKS Certified Kubernetes Security Specialist — guide pratique 2026

Ce tutoriel fait partie du cluster certification CKS. Pour la vue d’ensemble, lisez d’abord le pilier.

Introduction

Le domaine 5 « Supply Chain Security » pèse 20 % de l’examen CKS. Il teste votre capacité à sécuriser tout le pipeline qui amène une image conteneur en production : minimisation de l’image de base, scan de vulnérabilités, signature cryptographique, et validation à l’admission. Ce tutoriel pratique Trivy (le scanner de référence en 2026 (informations vérifiées en avril 2026, susceptibles d’évoluer ; vérifier la source officielle avant toute décision technique)), Cosign (signature Sigstore keyless), et l’intégration des deux dans une pipeline CI/CD GitHub Actions ou GitLab CI. Toutes les commandes sont testées sur un cluster kind 1.34.

Prérequis

• Cluster kind 1.34 fonctionnel
• Docker installé localement
• Tutoriels CKS précédents terminés
• 40 minutes

Étape 1 — Installer Trivy et scanner une première image

Trivy est un scanner open-source d’Aqua Security. Détecte les CVE dans les couches d’images, les secrets accidentels, les misconfigurations Kubernetes, les licences problématiques. Le standard de fait en 2026.

curl -fsSL https://aquasecurity.github.io/trivy-repo/deb/public.key | gpg --dearmor -o /usr/share/keyrings/trivy.gpg
echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main" > /etc/apt/sources.list.d/trivy.list
apt update && apt install -y trivy
trivy --version

# Scanner nginx classique — beaucoup de CVE attendues
trivy image nginx:1.27 --severity HIGH,CRITICAL | head -30

La sortie liste chaque CVE avec son ID, son score CVSS, le package vulnérable, la version installée, et la version corrigée. Un nginx:1.27 récent affiche typiquement 5-15 CVE, principalement dans les libs glibc, openssl, libxml2.

Étape 2 — Comparer images standard vs distroless

Une stratégie clé pour réduire la surface d’attaque : utiliser des images distroless (Google) ou scratch qui ne contiennent que le binaire applicatif et ses dépendances strictement nécessaires.

trivy image --severity HIGH,CRITICAL gcr.io/distroless/python3-debian12 2>&1 | tail -5

trivy image --severity HIGH,CRITICAL python:3.13-slim 2>&1 | tail -5

L’image distroless affiche typiquement 0-3 CVE, alors que python:3.13-slim en compte 30-60. La différence est massive. La règle d’or : pour la production, partez d’un Dockerfile multi-stage qui compile dans une image build complète puis copie le binaire dans une distroless.

Étape 3 — Dockerfile multi-stage avec distroless

Démonstration du pattern recommandé pour réduire drastiquement la surface d’attaque. Application Go simple en exemple.

mkdir -p /tmp/secure-app
cat > /tmp/secure-app/main.go <<'EOF'
package main
import ("fmt"; "net/http")
func main() {
  http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintln(w, "Hello secure world")
  })
  http.ListenAndServe(":8080", nil)
}
EOF

cat > /tmp/secure-app/Dockerfile <<'EOF'
FROM golang:1.23 AS build
WORKDIR /src
COPY main.go .
RUN go mod init app && CGO_ENABLED=0 go build -o /out/app main.go

FROM gcr.io/distroless/static-debian12
COPY --from=build /out/app /app
USER nonroot
EXPOSE 8080
ENTRYPOINT ["/app"]
EOF

docker build -t secure-app:v1 /tmp/secure-app
trivy image secure-app:v1 --severity HIGH,CRITICAL

La nouvelle image affiche 0 CVE — la couche distroless contient un kernel minimal de la CA bundle et le binaire. C’est exactement la posture recommandée par les benchmarks SLSA et NIST SSDF.

Étape 4 — Trivy en mode Kubernetes — scanner les manifests

Trivy peut scanner non seulement les images mais aussi les manifests Kubernetes pour détecter les misconfigurations (privileged: true, hostNetwork, capabilities excessives).

cat > /tmp/bad-pod.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: dangerous-pod
spec:
  hostPID: true
  hostNetwork: true
  containers:
  - name: app
    image: nginx:1.27
    securityContext:
      privileged: true
      runAsUser: 0
EOF

trivy config /tmp/bad-pod.yaml | head -30

La sortie liste toutes les misconfigurations : hostPID, hostNetwork, privileged, runAsUser=0. Trivy categorise par sévérité (CRITICAL pour privileged et hostNetwork). Cette commande tombe directement à l’examen — savoir lire un manifest Kubernetes pour identifier les anti-patterns sécurité.

Étape 5 — Installer Cosign pour la signature d’images

Cosign est l’outil de signature de Sigstore. Permet de signer une image (ou un manifest) avec une clé privée — ou en mode keyless avec un OIDC token (GitHub, Google, GitLab).

curl -L https://github.com/sigstore/cosign/releases/download/v2.5.0/cosign-linux-amd64 -o /usr/local/bin/cosign
chmod +x /usr/local/bin/cosign
cosign version

# Générer une keypair locale
cd /tmp
cosign generate-key-pair  # mot de passe demandé
ls cosign.key cosign.pub

Vous avez maintenant une clé privée (cosign.key, à ne JAMAIS commit) et une clé publique (cosign.pub, à distribuer). En production, on préfère le mode keyless basé sur OIDC pour éviter la gestion manuelle des clés.

Étape 6 — Signer une image et la vérifier

La signature s’attache à l’image via OCI artifact. La vérification consulte le registry pour récupérer la signature et la valider contre la clé publique.

# Tag l'image vers un registry local kind
docker tag secure-app:v1 localhost:5001/secure-app:v1

# Pour un registry interne kind
docker run -d -p 5001:5000 --restart=always --name registry registry:2
docker push localhost:5001/secure-app:v1

# Signer
COSIGN_PASSWORD="" cosign sign --key /tmp/cosign.key localhost:5001/secure-app:v1

# Vérifier
cosign verify --key /tmp/cosign.pub localhost:5001/secure-app:v1

La vérification doit retourner « Verified OK ». Toute modification de l’image après signature invalide cette vérification — c’est ce qui garantit l’intégrité.

Étape 7 — Gatekeeper policy pour exiger des images signées

Couplé à Gatekeeper, cosign devient un outil d’admission : on bloque toute image qui ne fournit pas une signature valide.

# Cosign policy controller installation
kubectl apply -f https://github.com/sigstore/policy-controller/releases/download/v0.13.0/policy-controller.yaml
sleep 30

cat > /tmp/cluster-image-policy.yaml <<'EOF'
apiVersion: policy.sigstore.dev/v1alpha1
kind: ClusterImagePolicy
metadata:
  name: signed-images-only
spec:
  images:
  - glob: "localhost:5001/**"
  authorities:
  - key:
      data: |
        -----BEGIN PUBLIC KEY-----
        # Coller ici le contenu de /tmp/cosign.pub
        -----END PUBLIC KEY-----
EOF

kubectl apply -f /tmp/cluster-image-policy.yaml

Une fois la policy active, tout Pod qui demande une image non-signée est rejeté à l’admission. C’est exactement la posture supply chain end-to-end qu’attend la CKS.

Étape 8 — Pipeline GitHub Actions sécurisée

Pour clôturer le tutoriel, voici un workflow GitHub Actions qui scan + sign automatiquement à chaque commit. C’est le pattern standard 2026.

name: secure-build
on: push

jobs:
  build:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
      id-token: write
      packages: write
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
      - uses: aquasecurity/trivy-action@0.28.0
        with:
          image-ref: ghcr.io/${{ github.repository }}:${{ github.sha }}
          severity: HIGH,CRITICAL
          exit-code: 1
      - uses: sigstore/cosign-installer@v3
      - run: cosign sign --yes ghcr.io/${{ github.repository }}:${{ github.sha }}

Ce workflow refuse de pousser une image avec des CVE HIGH/CRITICAL non patchées (`exit-code: 1`), et signe en keyless via le token OIDC GitHub. C’est la posture de référence en 2026 chez les pure players cloud.

Comprendre la différence keyless vs keyed signing

Cosign supporte deux modes. Keyed : vous générez une keypair, signez avec la privée, vérifiez avec la publique. Simple mais demande une gestion sécurisée de la clé privée. Keyless : pas de clé persistante. Cosign utilise un OIDC token (GitHub Actions, Google Cloud, GitLab) pour s’identifier auprès de Sigstore Fulcio qui émet un certificat éphémère valide quelques minutes. La signature est attachée à cette identité OIDC. Avantages : aucune clé à protéger, audit centralisé via Sigstore Rekor (transparency log).

Pour la CKS v1.34, attendez-vous à des questions sur les deux modes. Le keyless est de plus en plus la norme pour les workflows CI/CD modernes.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour les startups dakaroises et abidjanaises qui montent leur premier pipeline CI/CD sécurisé, le combo Trivy + Cosign keyless est gratuit et opérationnel en quelques heures. GitHub Actions est gratuit jusqu’à 2 000 minutes/mois pour les comptes individuels — largement suffisant pour 5-10 services applicatifs en CI. Pour les équipes plus matures qui ont besoin d’un registry privé, Harbor self-hosté sur Hostinger Cloud Startup à 9,99 USD/mois fait le travail. L’investissement total pour atteindre une supply chain conforme aux bonnes pratiques industrielles : moins de 30 USD/mois.

Tutoriels frères

• Pod Security Standards et OPA Gatekeeper
• Durcir un cluster Kubernetes avec kube-bench et CIS

Pour aller plus loin

• 🔝 Retour au pilier : CKS — guide pratique 2026
• Trivy : aquasecurity.github.io/trivy
• Cosign et Sigstore : docs.sigstore.dev/cosign/overview
• Distroless images : github.com/GoogleContainerTools/distroless

FAQ

Trivy ou Grype, lequel choisir ?
Les deux scanners sont valides. Trivy est dans le syllabus officiel CKS et c’est le standard de l’industrie. Grype (Anchore) est une alternative open-source rapide.

Cosign keyless est-il sécurisé sans clé persistante ?
Oui, parce que la chaîne de confiance se déplace vers le provider OIDC (GitHub, Google) et le transparency log Sigstore Rekor. Toutes les signatures sont publiquement auditables.

Mots-clés secondaires : trivy cks, cosign sigstore, image signing kubernetes, distroless dockerfile, supply chain security, sbom kubernetes