Rotation et gestion avancée des secrets

Au-delà de Vault : l’écosystème complet de gestion des secrets

Vault est le pilier central de la gestion des secrets, mais un environnement de production réaliste combine plusieurs outils. AWS Secrets Manager offre une intégration native avec les services AWS. SOPS + age permet de stocker des secrets chiffrés directement dans Git pour le GitOps. cert-manager automatise les certificats TLS. Et le secret scanning empêche les fuites avant qu’elles n’arrivent en production.

Ce cours couvre ces briques complémentaires et surtout la rotation automatique — le processus qui transforme un secret statique (une bombe à retardement) en un secret éphémère (un risque maîtrisé).

🔥 Cas réel : En 2022, Heroku a détecté un accès non autorisé à ses systèmes qui avait exfiltré des tokens OAuth d’intégration GitHub. Le problème ? Certains de ces tokens n’avaient jamais été rotés depuis leur création. Heroku a dû révoquer tous les tokens OAuth de ses clients — une opération qui a pris des semaines et cassé des milliers de pipelines CI/CD. Si ces tokens avaient eu un TTL court avec rotation automatique, le blast radius aurait été limité à quelques heures.

AWS Secrets Manager : la gestion native pour AWS

Pour les workloads qui tournent sur AWS, Secrets Manager offre une alternative à Vault avec une intégration profonde dans l’écosystème — IAM pour le contrôle d’accès, KMS pour le chiffrement, CloudTrail pour l’audit, et surtout une rotation automatique intégrée avec Lambda.

La création et la lecture de secrets se font via l’API AWS ou le CLI :

# Créer un secret avec des credentials structurées en JSON
aws secretsmanager create-secret \
    --name "production/database/postgres" \
    --description "PostgreSQL credentials for production" \
    --secret-string '{"username":"app","password":"SecureP@ss123","host":"mydb.cluster-xyz.eu-west-1.rds.amazonaws.com","port":"5432"}'

# Lire un secret (en CLI, utile pour les scripts)
aws secretsmanager get-secret-value \
    --secret-id "production/database/postgres" \
    --query 'SecretString' --output text | jq .

# Configurer la rotation automatique via Lambda
aws secretsmanager rotate-secret \
    --secret-id "production/database/postgres" \
    --rotation-lambda-arn "arn:aws:lambda:eu-west-1:123456:function:SecretsRotation" \
    --rotation-rules '{"ScheduleExpression":"rate(30 days)"}'

Côté application, la lecture se fait via le SDK AWS. L’application n’a besoin d’aucun mot de passe pour accéder au secret — l’authentification passe par le rôle IAM du pod ou de l’instance :

# Python — lecture d'un secret via le SDK boto3
import boto3
import json
import psycopg2

def get_secret(secret_name: str) -> dict:
    """Récupère un secret depuis AWS Secrets Manager."""
    client = boto3.client('secretsmanager', region_name='eu-west-1')
    response = client.get_secret_value(SecretId=secret_name)
    return json.loads(response['SecretString'])

# L'app s'authentifie via son IAM Role, pas via un mot de passe
creds = get_secret('production/database/postgres')
connection = psycopg2.connect(
    host=creds['host'],
    port=creds['port'],
    user=creds['username'],
    password=creds['password'],
    database='payments'
)

💡 Tip DevOps : Vault vs AWS Secrets Manager ? Utilise Secrets Manager si tu es 100% AWS et que tu veux la simplicité. Utilise Vault si tu es multi-cloud, si tu as besoin de dynamic secrets ou si tu veux un contrôle total. Beaucoup d’organisations utilisent les deux : Vault pour les credentials dynamiques, Secrets Manager pour les secrets statiques avec rotation Lambda.

SOPS + age : des secrets chiffrés dans Git

Le GitOps pose un dilemme : tout doit vivre dans Git (y compris la configuration des secrets), mais les secrets ne doivent jamais être en clair dans Git. SOPS (Secrets OPerationS, créé par Mozilla) résout ce problème avec une approche élégante : il chiffre uniquement les valeurs, en laissant les clés visibles. Tu peux ainsi faire un git diff et voir quels secrets ont changé, sans voir leur contenu.

age est l’outil de chiffrement moderne qui remplace GPG — plus simple, plus rapide, sans le cauchemar de la gestion de clés GPG.

# Installer les outils
brew install age sops   # macOS
# apt install age sops  # Debian/Ubuntu

# Générer une clé age
age-keygen -o ~/.config/sops/age/keys.txt
# Public key: age1abc123...

# Configurer SOPS pour le repo (.sops.yaml à la racine)
cat > .sops.yaml << 'EOF'
creation_rules:
  # Production → chiffré avec 2 clés age + AWS KMS (redondance)
  - path_regex: environments/production/.*\.yaml$
    age: >-
      age1abc123...,
      age1def456...
    kms: "arn:aws:kms:eu-west-1:123456:key/mrk-xyz"

  # Staging → une seule clé age suffit
  - path_regex: environments/staging/.*\.yaml$
    age: age1abc123...
EOF

L’utilisation au quotidien est transparente. Tu crées ton fichier de secrets en clair, tu le chiffres avec SOPS, et tu le commites dans Git :

# Créer un fichier de secrets Kubernetes
cat > environments/production/secrets.yaml << 'EOF'
apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
  namespace: production
stringData:
  DB_PASSWORD: "SuperSecretPassword123!"
  API_KEY: "sk-live-abc123def456"
  JWT_SECRET: "my-jwt-signing-key"
EOF

# Chiffrer (seules les valeurs sont chiffrées, les clés restent lisibles)
sops --encrypt --in-place environments/production/secrets.yaml

# Le résultat dans Git — les clés sont lisibles, les valeurs chiffrées :
# stringData:
#   DB_PASSWORD: ENC[AES256_GCM,data:abc123...,iv:...,tag:...]
#   API_KEY: ENC[AES256_GCM,data:def456...,iv:...,tag:...]

# Éditer un secret (déchiffre → ouvre l'éditeur → re-chiffre)
sops environments/production/secrets.yaml

# Git diff utile — tu vois QUELS secrets ont changé
git diff environments/production/secrets.yaml
# -  DB_PASSWORD: ENC[AES256_GCM,data:abc123...]
# +  DB_PASSWORD: ENC[AES256_GCM,data:xyz789...]

Pour l’intégration avec ArgoCD, le plugin ksops déchiffre automatiquement les secrets SOPS avant de les appliquer dans Kubernetes :

# kustomization.yaml avec ksops
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
generators:
  - secret-generator.yaml

---
# secret-generator.yaml
apiVersion: viaduct.ai/v1
kind: ksops
metadata:
  name: app-secrets
files:
  - secrets.yaml  # fichier chiffré par SOPS, déchiffré par ksops

⚠️ Attention : Le piège classique avec SOPS est d’oublier de chiffrer un fichier avant de le commiter. Le .sops.yaml configure le chiffrement pour les nouvelles opérations SOPS, mais il ne bloque pas un git add d’un fichier en clair. Ajoute un pre-commit hook qui vérifie que tous les fichiers dans environments/*/secrets*.yaml sont bien chiffrés.

Rotation automatique : le principe du dual-secret

La rotation sans downtime suit le pattern du dual-secret en quatre temps. D’abord, le secret A est actif. On génère un secret B (nouveau). L’application est configurée pour accepter A et B. On bascule vers B comme secret primaire. On révoque A après une période de grâce.

Pour les certificats TLS, cert-manager automatise tout le cycle de vie avec Let’s Encrypt :

# cert-manager — rotation automatique des certificats TLS
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: ops@company.com
    privateKeySecretRef:
      name: letsencrypt-prod-key
    solvers:
      - http01:
          ingress:
            class: nginx

---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: app-tls
  namespace: production
spec:
  secretName: app-tls-secret
  duration: 2160h    # 90 jours
  renewBefore: 360h  # Renouveler 15 jours avant expiration
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - app.company.com
    - api.company.com

Les fréquences de rotation recommandées dépendent du type de secret : mots de passe DB tous les 30 jours (ou dynamic secrets Vault avec TTL 1h), clés API tous les 90 jours, certificats TLS tous les 90 jours (cert-manager), tokens de service account avec un TTL de 1 heure, et unseal keys Vault annuellement.

🧠 À retenir : La rotation n’est pas un événement — c’est un processus continu. Si tu dois faire une rotation manuelle, tu la feras un jour trop tard. Automatise ou meurs (en termes de sécurité).

Secret scanning : la dernière ligne de défense

Même avec Vault et SOPS, un développeur pressé peut accidentellement commiter un secret en clair. Le secret scanning est ta dernière ligne de défense — il détecte les secrets dans le code avant qu’ils n’atteignent la production.

# Pre-commit hook avec gitleaks — bloque le commit si secret détecté
# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

# Scanner l'historique complet d'un repo (audit)
gitleaks detect --source . --verbose

# trufflehog — scan plus profond, vérifie si les secrets sont actifs
trufflehog git https://github.com/org/repo --only-verified

# GitHub Push Protection (natif, gratuit)
# Bloque le push si un secret connu est détecté
# Activé dans Settings > Code security > Secret scanning

💡 Tip DevOps : Combine trois niveaux de défense. Niveau 1 : pre-commit hook avec gitleaks (bloque avant le commit local). Niveau 2 : GitHub/GitLab secret scanning (bloque avant le merge). Niveau 3 : scan périodique de l’historique complet avec trufflehog (détecte les secrets anciens). Un secret qui passe les trois niveaux est exceptionnellement rare.

Bonnes pratiques et pièges à éviter

Les secrets Kubernetes sont en base64, PAS chiffrés. Un kubectl get secret -o yaml affiche les secrets en base64 — n’importe qui avec un accès RBAC get sur les secrets peut les lire. Active le chiffrement etcd (EncryptionConfiguration) ou utilise un KMS provider.

SOPS sans .sops.yaml est dangereux. Sans le fichier de configuration, un sops --encrypt peut échouer silencieusement ou utiliser la mauvaise clé. Toujours commiter .sops.yaml dans le repo et le vérifier en CI.

Teste la rotation AVANT de la lancer en production. Une rotation qui échoue à mi-chemin peut laisser un service avec des credentials invalides. Le pattern dual-secret existe pour ça : l’ancien secret reste valide pendant la transition.

Ne stocke jamais la clé de déchiffrement SOPS dans le même repo que les secrets chiffrés. C’est l’équivalent de mettre le coffre-fort et la combinaison dans le même tiroir. La clé age doit être dans un outil de gestion séparé (Vault, Secrets Manager, ou KMS).

🔥 Cas réel : Chez Stripe, les clés API publiables (pk_live_) et secrètes (sk_live_) suivent un cycle de rotation strict. Les clés secrètes sont rotées tous les 90 jours automatiquement. Quand GitHub détecte une clé Stripe dans un repo public, Stripe est notifié en temps réel et peut révoquer la clé en moins de 60 secondes — un partenariat direct entre les deux plateformes.

Résumé — Ce qu’il faut retenir

🧠 À retenir :

• AWS Secrets Manager complète Vault pour les workloads AWS avec rotation Lambda intégrée et authentification IAM native
• SOPS + age est la solution GitOps pour les secrets dans Git — chiffrement sélectif des valeurs, diffs lisibles, intégration ArgoCD via ksops
• La rotation dual-secret garantit zéro downtime : nouveau secret créé → app accepte les deux → bascule → révocation de l’ancien
• cert-manager automatise le cycle de vie complet des certificats TLS avec Let’s Encrypt — rotation sans intervention humaine
• Le secret scanning (gitleaks, trufflehog, GitHub Push Protection) est ta dernière ligne de défense contre les fuites accidentelles
• Combine les outils : Vault pour les dynamic secrets, Secrets Manager pour les secrets AWS, SOPS pour le GitOps, cert-manager pour les certificats