Un pipeline complet : tests, image, analyse, publication

Tester ne suffit pas : pour livrer sur Kubernetes, le pipeline doit aussi construire une image, la vérifier (vulnérabilités, secrets oubliés), la publier dans un registre avec une étiquette traçable, et idéalement la signer. Cette leçon assemble ces étapes dans un pipeline réaliste. Elle est théorique : votre machine de lab n'a ni forge ni moteur de conteneurs.

Ce que vous saurez à la fin : organiser un pipeline en étapes, étiqueter les images de façon traçable, analyser une image avec Trivy, gérer les secrets du pipeline, signer une image et produire sa liste de composants (SBOM).

1. L'enchaînement

  tests ──▶ construction de l'image ──▶ analyse ──▶ publication ──▶ (signature, SBOM) ──▶ déploiement (D.3)
   │               │                       │              │
 go test       docker build            trivy image    docker push

Chaque étape ne démarre que si la précédente a réussi. Une image vulnérable ne doit jamais atteindre le registre de production.

2. Un exemple complet (GitHub Actions)

name: livraison
on:
  push: {branches: [main]}
permissions:
  contents: read
  packages: write                   # publier dans ghcr.io ; rien de plus
jobs:
  tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with: {go-version: '1.25'}
      - run: go test ./...

  image:
    needs: tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: construire
        run: docker build -t ghcr.io/${{ github.repository }}:${{ github.sha }} .
      - name: analyser
        uses: aquasecurity/[email protected]    # en production : épinglez l'empreinte complète du commit (section 5)
        with:
          image-ref: ghcr.io/${{ github.repository }}:${{ github.sha }}
          severity: CRITICAL,HIGH
          exit-code: '1'                          # le pipeline échoue s'il trouve une faille grave
          ignore-unfixed: true
      - name: publier
        run: |
          echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u "${{ github.actor }}" --password-stdin
          docker push ghcr.io/${{ github.repository }}:${{ github.sha }}

3. Étiqueter de façon traçable

Étiquette	Usage
empreinte du commit (a1b2c3d)	relie chaque image à un commit précis : toujours
version (1.4.2)	pour les versions publiées (tag Git v1.4.2)
latest, main	pratique pour tester, jamais pour la production : l'étiquette bouge

Le déploiement référence ensuite une étiquette immuable, ou mieux l'empreinte de l'image (@sha256:…, leçon 6.7).

4. Analyser l'image

trivy image compare les paquets et bibliothèques de l'image aux bases de vulnérabilités connues (CVE), et repère aussi les secrets et les mauvaises configurations. Règles pratiques : bloquer sur CRITICAL et HIGH corrigeables (--ignore-unfixed), documenter les exceptions dans un fichier .trivyignore avec une date d'expiration, et relancer l'analyse régulièrement sur les images déjà publiées : une image saine aujourd'hui aura des CVE dans trois mois. Une image finale minimale (leçon C.2) réduit fortement le bruit.

5. Les secrets du pipeline

• Stockez-les dans les secrets de la forge, jamais dans le dépôt ; ils sont masqués dans les journaux.
• Donnez au jeton du pipeline les droits minimaux (permissions: ci-dessus).
• Préférez l'OIDC aux secrets de longue durée : la forge émet un jeton court, que le cloud ou le registre échange contre un accès temporaire. Plus rien à faire tourner ni à fuiter.
• Épinglez les actions tierces sur l'empreinte complète d'un commit (uses: org/action@<40 caractères> # v1.2.3), pas seulement sur une étiquette : une étiquette Git peut être déplacée. En mars 2026, des identifiants volés ont permis de réécrire presque toutes les étiquettes de l'action trivy-action vers du code qui exfiltrait les secrets des pipelines ; seuls les dépôts épinglés sur une empreinte sûre ont été épargnés. Un outil comme Dependabot ou Renovate tient ces empreintes à jour.

6. Signer et décrire l'image

syft ghcr.io/org/api:a1b2c3d -o spdx-json > sbom.json      # SBOM : la liste de tous les composants de l'image
cosign sign ghcr.io/org/api@sha256:9f2c…                    # signature (sans clé avec l'OIDC du pipeline)
cosign verify ghcr.io/org/api@sha256:9f2c… \
  --certificate-identity-regexp 'https://github.com/org/api/' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Le SBOM permet de répondre en une minute à « sommes-nous touchés par la faille de telle bibliothèque ? ». La signature prouve que l'image vient bien de votre pipeline ; une politique d'admission dans le cluster (Kyverno, Sigstore policy-controller) peut refuser toute image non signée.

Validez la leçon avec le questionnaire.