Cloud & Infrastructure

Secrets management dans le cloud : architectures 2025

Secrets management cloud : stores AWS/Azure/GCP, workload identity, External Secrets Operator, SOPS, rotation, audit, anti-patterns. Guide DevSecOps 2025.

Naim Aouaichia
16 min de lecture
  • Secrets management
  • Cloud security
  • AWS
  • Azure
  • GCP
  • Kubernetes
  • HashiCorp Vault

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

DimensionData center classiqueCloud moderne
Nombre d'instances10-500 VMs stables100-10 000 pods éphémères
Durée de vie d'une instanceMois-annéesMinutes-heures
IdentitéHostname statique (db01.prod)ServiceAccount + OIDC JWT éphémère
Rotation de secretTrimestrielle manuelleQuotidienne à horaire automatique
AuditLogs fichier localCloudTrail / Activity Log / CloudAudit
ConformitéPérimètre fixeScope 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

  1. Bootstrap d'identité sans credential statique — un pod ne peut pas stocker une clé AWS permanente.
  2. Centralisation du stockage des secrets — un seul endroit à auditer, à sauvegarder, à rotationner.
  3. Récupération juste-in-time — le secret n'entre en mémoire que le temps nécessaire.
  4. Audit traçable — chaque access à un secret génère un log CloudTrail / équivalent.
  5. 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 CI

3. 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 OIDC

Mé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.com

Binding 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-backend

3.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.sh

4. Couche 2 — Stores cloud natifs comparés

StoreÉditeurTarif 2025Rotation auto nativeRéplication cross-regionVersioning
AWS Secrets ManagerAWS0,40 $/secret/mois + 0,05 $/10k reqOui (Lambda hooks)Oui (cross-region replicas)Oui
AWS SSM Parameter Store (Standard)AWSGratuit, 0,05 $/10k reqNonNon nativeOui
AWS SSM Parameter Store (Advanced)AWS0,05 $/param/mois + reqLimitéeNon nativeOui
Azure Key Vault (Standard)Microsoft0,03 $/10k opsVia Event Grid + FunctionVia secondary vaultOui
Azure Key Vault (Premium, HSM FIPS 140-2 Level 2)Microsoft+ 1 $/mois/clé HSMOuiOuiOui
GCP Secret ManagerGoogle0,06 $/secret/mois + 0,03 $/10k accessLimitée (rotation via Cloud Functions)Auto (multi-régions)Oui
HashiCorp Vault OSSHashiCorpGratuit (self-hosted)Oui (dynamic secrets)Oui (Performance Replication Enterprise)Oui
HashiCorp Vault Enterprise (HCP)HashiCorp~0,50 $/session-hourOuiOuiOui

4.1 Critères de choix

  1. 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).
  2. Exigence rotation automatique : obligatoire pour credentials RDS / Aurora / SQL Server → AWS Secrets Manager ou Azure Key Vault avec Function dédiée.
  3. Exigence FIPS 140-2 Level 3 (secteur public, défense) : Azure Key Vault Premium HSM, AWS CloudHSM.
  4. 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:00

Avantages : 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 Manager

Avantages : 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-secrets

L'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.yaml

6. 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 : createSecretsetSecrettestSecretfinishSecret. 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 :

  1. Clés IAM long terme hardcodées en environnement CI (AWS_ACCESS_KEY_ID dans GitHub Secrets) → passer à OIDC federation.
  2. .env commité en Git même temporairement → gitleaks en pre-commit hook.
  3. Secrets en ConfigMap Kubernetes (Base64 n'est PAS du chiffrement) → toujours utiliser Secret + chiffrement at-rest etcd.
  4. Secret partagé entre tous les services (« DATABASE_PASSWORD » commun à 50 apps) → credential par service avec rotation indépendante.
  5. Credentials statiques dans Docker images → scan Trivy + injection runtime.
  6. Rotation manuelle trimestrielle « quand on y pense » → rotation automatique via Lambda / Function.
  7. Pas de distinction prod / staging (mêmes secrets dans les deux) → environnements cloisonnés, principe de moindre privilège.
  8. 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) :

StackCoût mensuel typiqueCoût annuel
AWS Secrets Manager full + Parameter Store config200-400 $2 400-4 800 $
Azure Key Vault Standard + Functions rotation100-250 $1 200-3 000 $
GCP Secret Manager100-200 $1 200-2 400 $
HashiCorp Vault OSS self-hosted (infra K8s)300-800 $ (infra)3 600-9 600 $
HashiCorp Vault HCP managed1 000-3 000 $12 000-36 000 $
Doppler Team400-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, .env en 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.

Questions fréquentes

  • Pourquoi le secrets management cloud est-il un problème distinct du secrets management traditionnel ?
    Trois différences structurelles. 1) Échelle : un cluster Kubernetes gère typiquement des centaines à des milliers de pods éphémères qui ont tous besoin de secrets, contre quelques dizaines de VMs statiques dans un data center traditionnel. 2) Identité éphémère : les workloads cloud n'ont pas d'identité persistante type « server01.prod » — il faut bootstrapper dynamiquement via IAM cloud (IRSA AWS, Workload Identity GKE, Azure Workload Identity). 3) Rotation automatique : un secret hardcodé en data center se gère manuellement, en cloud avec 500+ services dépendant d'un même secret, la rotation manuelle est impossible. Les architectures cloud modernes imposent donc trois couches — identité bootstrappée, secrets store centralisé, consommation courte durée — qui n'existent pas en infrastructure statique.
  • IRSA, Workload Identity, Azure Workload Identity : quelle différence ?
    Trois implémentations du même concept : OIDC federation entre cluster Kubernetes et IAM cloud, permettant aux pods d'obtenir des credentials IAM sans stocker de clé long terme. IRSA (IAM Roles for Service Accounts, AWS EKS, depuis 2019) utilise un ServiceAccount annoté, EKS expose un OIDC provider, le pod récupère un token JWT via projected volume et échange contre des credentials AWS STS. Workload Identity GKE (Google, depuis 2020) utilise un mapping ServiceAccount Kubernetes ↔ Google Service Account, fedération OIDC similaire. Azure Workload Identity (GA 2023) remplace l'ancien AAD Pod Identity avec le même pattern OIDC. Dans les trois cas : zéro credential long terme stocké dans le cluster, rotation automatique, audit trail centralisé. C'est l'approche de référence 2024-2025 pour tout pod Kubernetes qui accède à un service cloud.
  • AWS Secrets Manager ou SSM Parameter Store : lequel choisir ?
    Parameter Store pour configuration non-sensible et secrets à budget contraint (gratuit pour Standard tier, 0,05 $/10k requêtes, pas de rotation auto sur Standard). Secrets Manager pour secrets sensibles nécessitant rotation automatique, tags riches, réplication multi-région, versionning natif (0,40 $/secret/mois + 0,05 $/10k API calls). Règle pragmatique : Parameter Store pour connection strings staging, feature flags, config values. Secrets Manager pour credentials RDS production, API keys partenaires, clés OAuth2 client. Pour une ETI française typique (100-500 secrets actifs), la facture Secrets Manager tombe autour de 50-250 $/mois, Parameter Store < 20 $/mois. Le coût n'est jamais le vrai critère — la rotation automatique native l'est.
  • External Secrets Operator est-il obligatoire sur Kubernetes ?
    Non, mais c'est devenu le standard de facto 2024-2025 pour synchroniser des secrets depuis un store cloud (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, Vault) vers des Kubernetes Secrets consommables par les pods. Alternatives : Secrets Store CSI Driver (monte le secret directement en volume, pas de Secret Kubernetes persistant — modèle plus sûr en théorie, plus complexe à debugger), Vault Agent Injector (HashiCorp), SOPS + sealed-secrets pour secrets versionnés en Git. Un cluster Kubernetes mature 2025 utilise External Secrets Operator pour la majorité des cas + Secrets Store CSI Driver pour les secrets très sensibles (root credentials RDS, clés privées signing). SOPS reste utile pour les secrets de configuration infrastructure versionnés en Git (ex: Terraform variables).
  • Peut-on stocker des secrets dans Git avec SOPS ou sealed-secrets en 2025 ?
    Oui, c'est un pattern GitOps mature et robuste depuis 2020, à condition d'utiliser le chiffrement correctement. SOPS (Secrets OPerationS, maintenu Mozilla/getsops) chiffre les valeurs YAML/JSON avec AWS KMS, Azure Key Vault, GCP KMS, age ou PGP, laissant les clés en clair — parfait pour review Git. sealed-secrets (Bitnami, maintenu VMware) est spécifique Kubernetes : chiffre un Secret avec la clé publique du controller, seul le controller peut déchiffrer. Les deux sont sûrs si le secret de chiffrement racine (clé KMS, âge key, PGP key) est lui-même bien géré — c'est là que beaucoup d'équipes échouent. Anti-pattern : chiffrer avec une clé symétrique partagée dans un mot de passe gestionnaire sans rotation. Pattern correct : KMS cloud avec rotation, accès IAM restreint, audit CloudTrail.
  • Quelle fréquence de rotation recommandée par type de secret ?
    PCI-DSS v4.0 exige rotation minimum annuelle pour les cryptographic keys de systèmes paiement. NIST SP 800-57 recommande 1-2 ans pour clés de chiffrement de données au repos, 1 an pour signing keys. En pratique 2025 : credentials base de données production 30-90 jours (rotation via AWS Secrets Manager rotation lambda), API keys partenaires 90-180 jours selon criticité, OAuth2 client secrets 12 mois, clés de signature JWT 3-6 mois, tokens service-to-service 24h (passage à Workload Identity recommandé plutôt que rotation). Une fréquence trop courte sans automatisation génère des incidents de rotation rompue ; une fréquence trop longue laisse une fenêtre d'exploitation post-compromission. La bonne valeur est celle que ton outillage de rotation peut tenir sans intervention humaine.

Écrit par

Naim Aouaichia

Expert cybersécurité et fondateur de Zeroday Cyber Academy

Expert cybersécurité avec un master spécialisé et un parcours hybride : développement, DevOps, DevSecOps, SOC, GRC. Fondateur de Hash24Security et Zeroday Cyber Academy. Formateur et créateur de contenu technique sur la cybersécurité appliquée, la sécurité des LLM et le DevSecOps.