Gestion des Secrets : Protéger les Clés de Votre Royaume
Chaque système a des secrets : clés API, identifiants de base de données, certificats TLS, clés de chiffrement, tokens OAuth. La façon dont vous les gérez détermine si une seule compromission se propage en brèche totale. La gestion des secrets n'est pas un choix d'outil -- c'est une discipline architecturale.
Taxonomie des Types de Secrets
- Identifiants
- Mots de passe de bases de données
- Clés de comptes de service
- Clés SSH
- Clés / tokens d'API
- Certificats
- Certificats TLS/SSL
- Certificats clients mTLS
- Certificats de signature de code
- Clés privées d'AC
- Clés de chiffrement
- Clés de chiffrement des données (DEK)
- Clés de chiffrement de clés (KEK)
- Clés maîtres KMS
- Clés de chiffrement applicatives
- Tokens
- Tokens OAuth d'accès / de rafraîchissement
- Clés de signature JWT
- Secrets de webhook
- Secrets de session
- Secrets de configuration
- Chaînes de connexion
- Identifiants SMTP
- Secrets d'API tierces
- Clés de licence
Comparaison des Outils
| Capacité | HashiCorp Vault | AWS Secrets Manager | GCP Secret Manager | SOPS |
|---|---|---|---|---|
| Type | Plateforme complète | Service managé | Service managé | Chiffrement fichiers |
| Secrets dynamiques | Oui | Non | Non | Non |
| Rotation auto | Oui (intégrée) | Oui (via Lambda) | Oui (Cloud Functions) | N/A |
| Multi-cloud | Oui | AWS uniquement | GCP uniquement | Oui |
| Compatible GitOps | External Secrets Operator | External Secrets Operator | External Secrets Operator | Natif |
| Complexité | Haute | Basse | Basse | Basse |
- New secret needed
- → Can it be short-lived or dynamic (DB creds, cloud tokens, PKI)?
- Yes: Vault / OpenBao dynamic secrets with leases, or cloud IAM roles and OIDC federation: no static secret at all
- No: Consumed by a Kubernetes workload?
- Yes: Must the encrypted value be versioned in git (GitOps)?
- Yes: SOPS with age or cloud KMS keys (Flux native), or Sealed Secrets when cluster-bound is acceptable
- No: External Secrets Operator or Secrets Store CSI driver from the cloud manager or Vault
- No: Single cloud provider?
- Yes: Cloud secret manager (AWS Secrets Manager / SSM SecureString, Azure Key Vault, GCP Secret Manager) + managed identity
- No: Vault / OpenBao (multi-cloud, on-prem, transit encryption, PKI)
- Yes: Must the encrypted value be versioned in git (GitOps)?
- → Can it be short-lived or dynamic (DB creds, cloud tokens, PKI)?
Extrait de la fiche « Infrastructure as Code and Secrets » · Demander la fiche complète
Patterns de Rotation
| Pattern | Description | Fréquence | Risque de Coupure |
|---|---|---|---|
| Rotation manuelle | Humain change le secret, met à jour les consommateurs | Ad-hoc | Élevé |
| Rotation planifiée | Job automatisé sur une cadence | 30-90 jours | Faible |
| Secrets dynamiques | Secret généré par session, auto-expire | Par requête | Aucun |
| Rotation double-secret | Deux versions actives, rotation alternée | Continue | Aucun |
| Zero-standing-secrets | Pas de secrets persistants, génération JIT via OIDC | Par requête | Aucun |
Center: ≤ 90 days
- Generate — random, in the manager, never by hand
- Distribute — pulled at runtime by identity, not baked in
- Use — short time-to-live (TTL), scoped, audited access
- Monitor — alert on reads by new principals, on age
- Rotate — new version active while old still valid
- Revoke — old version disabled, then destroyed
↻ then back to step 1
Extrait de la fiche « Infrastructure as Code and Secrets » · Demander la fiche complète
Catalogue d'Anti-Patterns
| Anti-Pattern | Pourquoi c'est Dangereux | Que Faire à la Place |
|---|---|---|
| Secrets dans le code source | Fuites via historique git, forks, logs | Utiliser un gestionnaire de secrets, scanner avec truffleHog |
| Secrets en variables d'environnement | Visibles dans les listings de processus | Monter en fichiers, utiliser CSI driver ou sidecar |
| Comptes de service partagés | Pas d'attribution, rotation impossible | Identité par service, credentials éphémères |
| Clés API à longue durée | Large rayon d'impact si compromis | Secrets dynamiques, fédération OIDC, rotation auto |
| Secrets dans la config CI/CD | Accessibles à quiconque a accès au repo | Auth OIDC vers vault, zéro secret statique |
| Copier-coller de secrets via Slack | Pas de piste d'audit | Utiliser un gestionnaire de secrets avec UI |
Recommandations Stratégiques
Commencez par un scan. Avant de choisir un outil, comprenez votre exposition actuelle. Lancez truffleHog ou gitleaks sur tout votre historique git.
Adoptez la fédération OIDC. Les plateformes CI/CD modernes (GitHub Actions, GitLab CI) supportent les tokens OIDC qui s'authentifient directement auprès des fournisseurs cloud et de Vault -- éliminant totalement les secrets statiques de CI/CD.
Les secrets dynamiques sont l'objectif final. Les secrets dynamiques de Vault (identifiants BDD générés par pod, expirés après TTL) éliminent totalement le problème de rotation.
Chiffrez les secrets dans git pour le GitOps. SOPS avec age ou cloud KMS permet de stocker des secrets chiffrés à côté du code applicatif.
Actors: CI job, GitHub OIDC, AWS STS, AWS API
- CI job → GitHub OIDC request ID token (needs permissions: id-token: write)
- GitHub OIDC ⇠ CI job signed JWT: aud sts.amazonaws.com, sub repo:org/app:ref:refs/heads/main
- CI job → AWS STS AssumeRoleWithWebIdentity(role ARN, JWT)
- AWS STS: STS checks the signature, the audience and the sub condition of the role trust policy
- AWS STS ⇠ CI job temporary keys (ASIA...), 1 h by default
- CI job → AWS API deploy with the temporary keys
Extrait de la fiche « Secrets and Credential Hygiene for Developers » · Demander la fiche complète