La gestion des secrets dans le cloud (credentials base de données, API keys, OAuth2 client secrets, certificats, clés de signature JWT, tokens service-to-service) est un problème structurellement distinct du secrets management traditionnel en data center : échelle (milliers de pods éphémères vs dizaines de VMs statiques), identité bootstrappée (OIDC federation vs hostname fixe), rotation automatique obligatoire (impossible manuellement à l'échelle cloud). L'architecture de référence 2024-2025 repose sur 3 couches strictes : couche 1 identité (bootstrap d'une identité cloud éphémère via IRSA AWS, Workload Identity GKE, ou Azure Workload Identity, toutes OIDC-fédérées), couche 2 store (secrets centralisés dans AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, ou HashiCorp Vault), couche 3 consommation (pattern Kubernetes : External Secrets Operator, Secrets Store CSI Driver, Vault Agent Injector ; pattern serverless : SDK-native retrieval ; pattern GitOps : SOPS, sealed-secrets). Les anti-patterns à éliminer restent les mêmes : clés AWS long terme hardcodées en variables d'environnement, .env commités en Git (détectés typiquement par gitleaks dans 15-25 % des audits 2024), secrets dans ConfigMaps Kubernetes (Base64 ≠ chiffrement), credentials statiques dans images Docker. Cet article détaille l'architecture 3 couches avec exemples d'intégration AWS / Azure / GCP, les patterns Kubernetes dominants, la rotation automatique, la détection de fuites (gitleaks + CloudTrail + GuardDuty + Wiz), les coûts comparés 2025, et les cas de bascule cloud-native vers Workload Identity. Pour l'angle développeur hands-on, voir l'article complémentaire Secrets management pour développeurs.
1. Pourquoi le secrets management cloud est un problème distinct
Le modèle traditionnel — secret en fichier .conf sur un serveur pets — ne scale pas au cloud pour trois raisons fondamentales.
1.1 Les 3 différences structurelles cloud vs data center
| Dimension | Data center classique | Cloud moderne |
|---|---|---|
| Nombre d'instances | 10-500 VMs stables | 100-10 000 pods éphémères |
| Durée de vie d'une instance | Mois-années | Minutes-heures |
| Identité | Hostname statique (db01.prod) | ServiceAccount + OIDC JWT éphémère |
| Rotation de secret | Trimestrielle manuelle | Quotidienne à horaire automatique |
| Audit | Logs fichier local | CloudTrail / Activity Log / CloudAudit |
| Conformité | Périmètre fixe | Scope IAM à chaque requête |
À l'échelle cloud, chaque changement manuel d'un secret dans un fichier .env produit typiquement 5-50 pods qui tombent le temps du rollout. D'où la nécessité d'outils centralisés avec rotation transparente.
1.2 Ce que cette complexité impose
- Bootstrap d'identité sans credential statique — un pod ne peut pas stocker une clé AWS permanente.
- Centralisation du stockage des secrets — un seul endroit à auditer, à sauvegarder, à rotationner.
- Récupération juste-in-time — le secret n'entre en mémoire que le temps nécessaire.
- Audit traçable — chaque access à un secret génère un log CloudTrail / équivalent.
- Rotation automatique sans downtime — triggers côté store, propagation transparente.
2. Architecture 3 couches : identité → store → consommation
Le pattern de référence 2024-2025 pour un secrets management cloud robuste :
Architecture 3 couches secrets management cloud
────────────────────────────────────────────────
Couche 3 — CONSOMMATION
External Secrets Operator / Secrets Store CSI Driver / Vault Agent
SDK native retrieval (boto3, azure-keyvault, google-secretmanager)
SOPS pour fichiers de configuration infra
│
│ (lecture de secrets avec identité cloud)
▼
Couche 2 — STORE
AWS Secrets Manager ─┐
Azure Key Vault ├─► centralisation, rotation, audit, versioning
GCP Secret Manager ─┘
HashiCorp Vault (self-hosted ou HCP)
│
│ (autorisation via IAM policy)
▼
Couche 1 — IDENTITÉ
IRSA (AWS EKS)
Workload Identity (GKE)
Azure Workload Identity
Instance Profile / Managed Identity (VM)
OIDC federation CI/CD (GitHub Actions, GitLab CI)
│
│ (pas de credential statique stocké)
▼
Pods / Functions / VMs / Workflows CI3. Couche 1 — Identité bootstrappée (Workload Identity)
Toutes les plateformes cloud convergent vers le même pattern depuis 2020 : OIDC federation entre la plateforme qui exécute le workload (EKS, GKE, AKS, GitHub Actions, GitLab CI) et l'IAM cloud.
3.1 IRSA — IAM Roles for Service Accounts (AWS EKS)
# ServiceAccount Kubernetes annoté avec le rôle IAM à assumer
apiVersion: v1
kind: ServiceAccount
metadata:
name: api-backend
namespace: production
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/ApiBackendRole
---
# Deployment qui utilise le ServiceAccount
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-backend
namespace: production
spec:
template:
spec:
serviceAccountName: api-backend
containers:
- name: api
image: 123456789012.dkr.ecr.eu-west-3.amazonaws.com/api:v1.2.3
# Aucune variable AWS_ACCESS_KEY_ID ou AWS_SECRET_ACCESS_KEY
# Les credentials AWS sont injectés automatiquement via token OIDCMécanique interne : le pod reçoit un projected volume contenant un JWT OIDC signé par EKS. Le SDK AWS (boto3, aws-sdk-go v2, etc.) détecte automatiquement les variables AWS_ROLE_ARN et AWS_WEB_IDENTITY_TOKEN_FILE injectées, et appelle STS AssumeRoleWithWebIdentity pour obtenir des credentials temporaires (durée 1h par défaut, rafraîchis automatiquement).
3.2 Workload Identity GKE (Google)
# ServiceAccount Kubernetes lié à un Google Service Account
apiVersion: v1
kind: ServiceAccount
metadata:
name: api-backend
namespace: production
annotations:
iam.gke.io/gcp-service-account: api-backend@my-project.iam.gserviceaccount.comBinding côté GCP :
gcloud iam service-accounts add-iam-policy-binding \
api-backend@my-project.iam.gserviceaccount.com \
--role roles/iam.workloadIdentityUser \
--member "serviceAccount:my-project.svc.id.goog[production/api-backend]"3.3 Azure Workload Identity (successeur AAD Pod Identity)
Même modèle OIDC depuis la GA en 2023 :
apiVersion: v1
kind: ServiceAccount
metadata:
name: api-backend
namespace: production
annotations:
azure.workload.identity/client-id: 00000000-0000-0000-0000-000000000000
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-backend
spec:
template:
metadata:
labels:
azure.workload.identity/use: "true"
spec:
serviceAccountName: api-backend3.4 OIDC federation pour CI/CD
Le même mécanisme s'applique à GitHub Actions / GitLab CI :
# .github/workflows/deploy.yml — zéro credential AWS stocké dans les secrets GitHub
name: Deploy
on:
push:
branches: [main]
permissions:
id-token: write # autorise la création de JWT OIDC par GitHub
contents: read
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Configure AWS credentials via OIDC
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsDeployRole
aws-region: eu-west-3
# Pas de aws-access-key-id / aws-secret-access-key — OIDC federation
- name: Deploy
run: ./scripts/deploy.sh4. Couche 2 — Stores cloud natifs comparés
| Store | Éditeur | Tarif 2025 | Rotation auto native | Réplication cross-region | Versioning |
|---|---|---|---|---|---|
| AWS Secrets Manager | AWS | 0,40 $/secret/mois + 0,05 $/10k req | Oui (Lambda hooks) | Oui (cross-region replicas) | Oui |
| AWS SSM Parameter Store (Standard) | AWS | Gratuit, 0,05 $/10k req | Non | Non native | Oui |
| AWS SSM Parameter Store (Advanced) | AWS | 0,05 $/param/mois + req | Limitée | Non native | Oui |
| Azure Key Vault (Standard) | Microsoft | 0,03 $/10k ops | Via Event Grid + Function | Via secondary vault | Oui |
| Azure Key Vault (Premium, HSM FIPS 140-2 Level 2) | Microsoft | + 1 $/mois/clé HSM | Oui | Oui | Oui |
| GCP Secret Manager | 0,06 $/secret/mois + 0,03 $/10k access | Limitée (rotation via Cloud Functions) | Auto (multi-régions) | Oui | |
| HashiCorp Vault OSS | HashiCorp | Gratuit (self-hosted) | Oui (dynamic secrets) | Oui (Performance Replication Enterprise) | Oui |
| HashiCorp Vault Enterprise (HCP) | HashiCorp | ~0,50 $/session-hour | Oui | Oui | Oui |
4.1 Critères de choix
- Mono-cloud vs multi-cloud : mono-cloud → secrets manager natif de l'hyperscaler (intégration IAM simplifiée). Multi-cloud → HashiCorp Vault (abstraction unique). ETI françaises : 65 % choisissent le natif, 35 % Vault (observations terrain 2024).
- Exigence rotation automatique : obligatoire pour credentials RDS / Aurora / SQL Server → AWS Secrets Manager ou Azure Key Vault avec Function dédiée.
- Exigence FIPS 140-2 Level 3 (secteur public, défense) : Azure Key Vault Premium HSM, AWS CloudHSM.
- Budget : < 500 secrets actifs → Parameter Store Standard (gratuit). > 500 secrets ou rotation critique → Secrets Manager.
4.2 HashiCorp Vault — dynamic secrets
La killer feature de Vault que les secrets managers cloud ne remplacent pas : les dynamic secrets. Vault génère à la demande un credential éphémère (typiquement 1-24h de durée de vie) pour une base de données, SSH, PKI X.509, etc.
# Enable du moteur database Vault
vault secrets enable database
# Configuration du backend PostgreSQL
vault write database/config/prod-postgres \
plugin_name=postgresql-database-plugin \
allowed_roles="api-readonly" \
connection_url="postgresql://{{username}}:{{password}}@prod-db:5432/" \
username="vault-root" \
password="redacted"
# Configuration du rôle avec TTL 1h
vault write database/roles/api-readonly \
db_name=prod-postgres \
creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; \
GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
default_ttl="1h" \
max_ttl="24h"
# Une application authentifiée demande un credential éphémère
vault read database/creds/api-readonly
# Retourne : username="v-token-api-readonly-abc123def456", password=..., expiration=2026-04-24T10:00:00+02:00Avantages : chaque pod obtient son propre credential, auto-expiré, traçable en logs. Compromission d'un credential = impact limité à la TTL.
5. Couche 3 — Patterns de consommation Kubernetes
Quatre patterns coexistent en production 2024-2025. Aucun n'est parfait, chacun adapté à un cas.
5.1 External Secrets Operator (ESO)
Le pattern dominant : ESO synchronise un secret depuis le store vers un Secret Kubernetes standard, consommé classiquement par les pods.
# SecretStore : connexion au backend AWS Secrets Manager via IRSA
apiVersion: external-secrets.io/v1
kind: SecretStore
metadata:
name: aws-secrets-manager
namespace: production
spec:
provider:
aws:
service: SecretsManager
region: eu-west-3
auth:
jwt:
serviceAccountRef:
name: external-secrets-sa # lié à un rôle IAM avec secretsmanager:GetSecretValue
---
# ExternalSecret : déclaration d'un secret à synchroniser
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
name: api-backend-db
namespace: production
spec:
refreshInterval: 1h # re-lecture toutes les heures
secretStoreRef:
name: aws-secrets-manager
kind: SecretStore
target:
name: api-backend-db # nom du Secret Kubernetes créé
dataFrom:
- extract:
key: prod/api-backend/db # clé dans AWS Secrets ManagerAvantages : simple à comprendre, debug facile (kubectl get secret), compatible avec tous les workloads existants. Inconvénient : le secret transite en clair dans etcd (chiffré au repos sur EKS/GKE/AKS modernes, mais accessible via Kubernetes API).
5.2 Secrets Store CSI Driver (SSCD)
Alternative plus sûre : le secret est monté directement en volume dans le pod, sans Kubernetes Secret persistant.
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: api-backend-secrets
namespace: production
spec:
provider: aws
parameters:
objects: |
- objectName: "prod/api-backend/db"
objectType: "secretsmanager"
jmesPath:
- path: "password"
objectAlias: "db_password"
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-backend
spec:
template:
spec:
serviceAccountName: api-backend # IRSA
containers:
- name: api
volumeMounts:
- name: secrets
mountPath: /mnt/secrets
readOnly: true
volumes:
- name: secrets
csi:
driver: secrets-store.csi.k8s.io
readOnly: true
volumeAttributes:
secretProviderClass: api-backend-secretsL'application lit /mnt/secrets/db_password. Avantage : secret non-persistant dans etcd, disparaît à la suppression du pod. Inconvénient : plus complexe à debugger, plus rare comme pattern (adoption minoritaire en 2024).
5.3 Vault Agent Injector (HashiCorp)
Pour les environnements Vault, un sidecar injection récupère les secrets et les place dans un volume éphémère :
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-backend
spec:
template:
metadata:
annotations:
vault.hashicorp.com/agent-inject: "true"
vault.hashicorp.com/role: "api-backend"
vault.hashicorp.com/agent-inject-secret-db: "database/creds/api-readonly"
vault.hashicorp.com/agent-inject-template-db: |
{{- with secret "database/creds/api-readonly" -}}
export DB_USER="{{ .Data.username }}"
export DB_PASS="{{ .Data.password }}"
{{- end }}5.4 SOPS pour configuration infrastructure
SOPS ne synchronise pas, il chiffre des fichiers versionnés en Git. Adapté aux secrets d'infrastructure (Terraform variables, Helm values, Ansible vault) pas aux secrets d'application pods.
# Configuration .sops.yaml
cat > .sops.yaml <<'EOF'
creation_rules:
- path_regex: \.enc\.yaml$
kms: arn:aws:kms:eu-west-3:123456789012:alias/sops-infra
encrypted_regex: "^(password|secret|key|token|credentials)$"
EOF
# Chiffrement d'un fichier
sops --encrypt values.prod.yaml > values.prod.enc.yaml
# Edition in-place
sops values.prod.enc.yaml
# Utilisation dans Helm via helm-secrets plugin
helm secrets upgrade --install myapp ./chart -f values.prod.enc.yaml6. Rotation automatique
6.1 Rotation AWS Secrets Manager via Lambda
AWS Secrets Manager intègre un mécanisme de rotation via Lambda. Pour RDS :
# Terraform — rotation auto d'un secret RDS tous les 30 jours
resource "aws_secretsmanager_secret" "db_credentials" {
name = "prod/api-backend/db"
recovery_window_in_days = 7
}
resource "aws_secretsmanager_secret_rotation" "db_credentials" {
secret_id = aws_secretsmanager_secret.db_credentials.id
rotation_lambda_arn = aws_lambda_function.rotate_db_creds.arn
rotation_rules {
automatically_after_days = 30
}
}
resource "aws_lambda_function" "rotate_db_creds" {
function_name = "rotate-db-credentials"
runtime = "python3.12"
# Code basé sur AWS-provided PostgreSQL single-user rotation template
# https://github.com/aws-samples/aws-secrets-manager-rotation-lambdas
filename = "rotation_lambda.zip"
role = aws_iam_role.rotation_lambda.arn
handler = "lambda_function.lambda_handler"
timeout = 30
}Le Lambda suit le 4-step rotation standardisé par AWS : createSecret → setSecret → testSecret → finishSecret. Les applications utilisant le SDK AWS récupèrent toujours AWSCURRENT — la rotation est transparente.
6.2 Fréquences recommandées par type
Fréquences de rotation recommandées — ETI typique 2025
──────────────────────────────────────────────────────
Credentials DB production (RDS, Aurora, Cloud SQL) 30-90 jours
API keys partenaires critiques 90-180 jours
OAuth2 client secrets 6-12 mois
JWT signing keys 3-6 mois
TLS certificates internal 90 jours (Let's Encrypt 90j, ACM auto-renew)
TLS certificates public (EV/OV) 1 an max (CAB Forum 398j)
Tokens service-to-service Éphémères (Workload Identity) — pas de rotation
Cryptographic keys data-at-rest 1-2 ans (NIST SP 800-57)7. Audit et détection de fuites
7.1 Détection proactive de secrets en Git
Le scan régulier de l'historique Git est non-optionnel en 2025. GitGuardian State of Secrets Sprawl 2024 rapporte que 23,8 millions de nouveaux secrets ont été détectés dans des repos publics en 2023 — croissance +28 % vs 2022.
Outils :
# gitleaks — scan historique complet avec config .gitleaks.toml
gitleaks detect --source . --redact --report-path leaks.json
# truffleHog — détection IA-assistée de patterns
trufflehog git file://. --only-verified --json > leaks.json
# Trivy — scan état courant (pas historique)
trivy fs --scanners secret .Intégration CI/CD obligatoire : scan sur chaque PR, blocage en cas de détection. Voir Trivy : à quoi ça sert pour les patterns CI.
7.2 Audit de consommation via logs cloud
Chaque accès à un secret dans AWS Secrets Manager génère un event CloudTrail :
{
"eventSource": "secretsmanager.amazonaws.com",
"eventName": "GetSecretValue",
"userIdentity": {
"type": "AssumedRole",
"arn": "arn:aws:sts::123456789012:assumed-role/ApiBackendRole/i-0a1b2c3d"
},
"requestParameters": {
"secretId": "arn:aws:secretsmanager:eu-west-3:123456789012:secret:prod/api-backend/db"
},
"sourceIPAddress": "172.16.1.42",
"eventTime": "2026-04-24T09:15:42Z"
}Intégration SIEM / Datadog / Splunk pour détecter :
- Accès depuis une IP inattendue.
- Accès en-dehors des heures ouvrées.
- Accès à un secret par un rôle non-autorisé normalement.
- Pic anomalique de
GetSecretValue(exfiltration potentielle).
7.3 Détection de posture via CSPM
Les outils de Cloud Security Posture Management (Wiz, Prisma Cloud, Scout Suite, Prowler) détectent automatiquement :
- Secrets hardcodés dans les images Docker en ECR/ACR/GCR (double-checkage avec Trivy).
- Secrets dans les user-data des VM.
- Clés IAM avec permissions excessives (principe least privilege violé).
- Secrets avec rotation désactivée alors que le tag compliance le requiert.
8. Anti-patterns à éliminer absolument
Les 8 anti-patterns observés régulièrement en audit DevSecOps 2024-2025 :
- Clés IAM long terme hardcodées en environnement CI (
AWS_ACCESS_KEY_IDdans GitHub Secrets) → passer à OIDC federation. .envcommité en Git même temporairement → gitleaks en pre-commit hook.- Secrets en ConfigMap Kubernetes (Base64 n'est PAS du chiffrement) → toujours utiliser
Secret+ chiffrement at-rest etcd. - Secret partagé entre tous les services (« DATABASE_PASSWORD » commun à 50 apps) → credential par service avec rotation indépendante.
- Credentials statiques dans Docker images → scan Trivy + injection runtime.
- Rotation manuelle trimestrielle « quand on y pense » → rotation automatique via Lambda / Function.
- Pas de distinction prod / staging (mêmes secrets dans les deux) → environnements cloisonnés, principe de moindre privilège.
- Credentials dans messages Slack / emails → jamais, utiliser 1Password / Vault share-link avec TTL.
9. Coûts comparés ETI 2025
Pour une ETI française avec périmètre typique (500 secrets actifs, 200 workloads Kubernetes, 10M accès / mois) :
| Stack | Coût mensuel typique | Coût annuel |
|---|---|---|
| AWS Secrets Manager full + Parameter Store config | 200-400 $ | 2 400-4 800 $ |
| Azure Key Vault Standard + Functions rotation | 100-250 $ | 1 200-3 000 $ |
| GCP Secret Manager | 100-200 $ | 1 200-2 400 $ |
| HashiCorp Vault OSS self-hosted (infra K8s) | 300-800 $ (infra) | 3 600-9 600 $ |
| HashiCorp Vault HCP managed | 1 000-3 000 $ | 12 000-36 000 $ |
| Doppler Team | 400-900 $ | 4 800-10 800 $ |
| 1Password for Teams (secrets dev) | 150-500 $ | 1 800-6 000 $ |
Le coût licence est marginal vs le coût humain — un DevSecOps consacrant 2-3 jours/mois à la gestion manuelle des secrets représente 5-10 k€/an à lui seul. L'investissement dans un secrets management automatisé se rentabilise en quelques mois.
Points clés à retenir
- 3 couches : identité (IRSA/Workload Identity/OIDC) → store (Secrets Manager / Key Vault / Secret Manager / Vault) → consommation (External Secrets Operator / CSI Driver / Vault Agent / SOPS).
- Workload Identity obligatoire en 2025 : fin des clés IAM long terme stockées dans Kubernetes Secrets ou GitHub Secrets. Migration OIDC federation = quick win sécurité majeur.
- External Secrets Operator : standard de facto pour Kubernetes. Complété par Secrets Store CSI Driver pour secrets très sensibles.
- HashiCorp Vault : pertinent si multi-cloud réel ou besoin de dynamic secrets (credentials DB éphémères par pod).
- SOPS : adapté aux secrets d'infrastructure versionnés en Git (Terraform, Helm), pas aux secrets runtime pods.
- Rotation auto obligatoire : 30-90j pour DB prod, 90-180j pour API keys partenaires, éphémère pour service-to-service (Workload Identity).
- 8 anti-patterns à éliminer : clés long terme en CI,
.enven Git, secrets en ConfigMaps, credentials partagés, rotation manuelle. - Coût licence marginal : 1 200-4 800 $/an pour une ETI, largement inférieur au coût humain d'une gestion manuelle.
Pour le pendant développeur avec code d'intégration concret, voir Secrets management pour développeurs. Pour l'outillage de scan en pipeline, Trivy : à quoi ça sert. Pour la trajectoire métier, Roadmap Cloud Security.







