Sécurité : pipelines, secrets, production

L'offre cite trois choses : sécuriser les pipelines, gérer les secrets, protéger la prod. En entretien, la question sur la fuite de secret tombe presque à coup sûr.

Gestion des secrets

Les règles de base

Jamais de secret dans le dépôt Git, même privé, même « temporairement ». L'historique garde tout.
Pas de secret dans une image Docker (ENV, COPY .env) : n'importe qui avec l'image le lit via docker history ou en extrayant les couches.
Pas de secret dans les logs de CI. Attention à set -x en Bash qui affiche les commandes avec leurs valeurs.
Préférer des identifiants courts (tokens qui expirent) aux identifiants longs (clés, mots de passe fixes).
Rotation régulière, et immédiate en cas de doute.
Chaque accès à un secret doit être tracé.

Où les stocker

Outil	Usage
Variables CI/CD GitLab	Masquées (cachées dans les logs) et protégées (seulement sur branches protégées). Simple, limité.
GCP Secret Manager	Secrets versionnés, IAM, audit. Lu par les applis ou le pipeline au moment du besoin.
HashiCorp Vault	Le plus complet : secrets dynamiques (un identifiant de base de données créé à la demande, avec une durée de vie), PKI, chiffrement en service.
ansible-vault	Chiffre des fichiers de variables dans le dépôt Ansible. Le mot de passe du vault reste hors du dépôt.
SOPS	Chiffre des fichiers YAML/JSON avec une clé KMS. Les clés restent lisibles, seules les valeurs sont chiffrées, le diff Git reste exploitable.

Secret commité : la procédure

Ordre à respecter, et à réciter en entretien :

Révoquer ou faire tourner le secret immédiatement. À partir du moment où il a été poussé, il faut le considérer comme compromis. Des robots scannent les dépôts publics en quelques minutes.
Vérifier l'usage : logs d'audit du service concerné (Cloud Audit Logs, logs de la base). Y a-t-il eu des accès anormaux ?
Purger l'historique avec git filter-repo (ou BFG), puis force push coordonné avec l'équipe. Sur GitLab, les anciennes références peuvent rester dans les MR : contacter l'admin si besoin.
Empêcher la récidive : gitleaks ou le Secret Detection de GitLab dans la CI, et en hook pre-commit.
Documenter l'incident.

La plupart des candidats commencent par l'étape 3. C'est une erreur : purger l'historique ne rend pas le secret de nouveau confidentiel.

Sécuriser le pipeline CI/CD

Le pipeline a accès à la prod. S'il est compromis, la prod l'est aussi.

Contrôles à mettre dans le pipeline

Contrôle	Outil	Ce qu'il trouve
Détection de secrets	gitleaks, GitLab Secret Detection	Clés, tokens, mots de passe dans le code
SAST	Semgrep, GitLab SAST	Failles dans le code source
Analyse des dépendances	GitLab Dependency Scanning, Trivy	Bibliothèques avec CVE connues
Scan d'images	Trivy, Grype	CVE dans les paquets de l'image
Scan IaC	Checkov, tfsec, KICS	Bucket public, pare-feu ouvert à 0.0.0.0/0, chiffrement absent
Lint	tflint, ansible-lint, hadolint, shellcheck	Mauvaises pratiques

Protéger la chaîne elle-même

Branches protégées : personne ne pousse directement sur main, tout passe par merge request avec approbation.
Environnements protégés : seules certaines personnes peuvent déclencher le déploiement en prod.
Jobs de prod en when: manual.
Runners : un runner dédié à la prod, avec des droits limités, qui n'exécute pas les jobs des branches de feature. Éviter les runners partagés en mode privileged.
Variables protégées : elles ne sont pas injectées dans les pipelines des branches non protégées. Un développeur ne peut pas les exfiltrer depuis sa branche.
Épingler les versions : images de base par digest (image@sha256:...), actions et templates à une version fixe.
Signer les images (cosign) et vérifier la signature au déploiement.
Workload Identity Federation plutôt que des clés stockées dans les variables.

Protéger la production

Accès

Moindre privilège sur IAM : pas d'Editor ni d'Owner pour le quotidien.
Accès humains en lecture par défaut. Les droits d'écriture en prod passent par le pipeline, ou par une élévation temporaire et tracée (break glass).
Pas d'IP publique sur les VM : IAP ou bastion.
MFA pour tout le monde.
Revue régulière des accès.

Réseau

Segmentation : prod et hors-prod dans des projets et des VPC séparés.
Pare-feu en liste blanche, jamais 0.0.0.0/0 sur SSH ou une base de données.
Chiffrement en transit (TLS partout, mTLS entre services sensibles) et au repos (activé par défaut sur GCP, clés CMEK si exigé).

Système

Durcissement selon les benchmarks CIS : services inutiles désactivés, SSH sans mot de passe ni root, PermitRootLogin no, PasswordAuthentication no.
Patching régulier et suivi des CVE.
SELinux en enforcing.
fail2ban ou équivalent sur ce qui est exposé.

Détection et reprise

Audit logs activés et centralisés, alertes sur les actions sensibles (modification IAM, suppression de ressource).
Sauvegardes testées : une sauvegarde jamais restaurée n'est pas une sauvegarde. Garder au moins une copie hors du compte principal (règle 3-2-1 : 3 copies, 2 supports, 1 hors site).
PRA documenté et exercé.

Sécurité des conteneurs

Image de base minimale (distroless, alpine, slim).
USER non root dans le Dockerfile.
Système de fichiers en lecture seule quand c'est possible.
Pas de --privileged.
Scanner les images à chaque build et régulièrement en registry.

Questions d'entretien à préparer

Un secret a été commité, que fais-tu ? (révoquer d'abord)
Où stockes-tu les secrets de ton pipeline ?
Comment empêcher un développeur de lire les secrets de prod via sa branche ? (variables protégées, environnements protégés)
Quels contrôles de sécurité mets-tu dans un pipeline d'infra ?
Comment accèdes-tu aux serveurs de prod ?
Différence entre SAST et DAST ? (SAST analyse le code sans l'exécuter, DAST attaque l'appli qui tourne)
C'est quoi le principe du moindre privilège, avec un exemple concret ?