Gestion des configurations et des secrets

Gestion des configurations et des secrets

1) Pourquoi est-ce nécessaire

• Prévisibles (schémas, validation, versions).
• Sécurisé (cryptage, droits minimums, rotation).
• Gérés (GitOps, audit, annulations).
• Dynamique lorsque cela est justifié (flags de fonction, paramétrage des limites).

2) Classification des artefacts

Configurations publiques : fiches, seuils, taimautes, flags (pas de secrets).
Configues sensibles : paramètres qui modifient le comportement des chemins critiques (par exemple, limites de paiement).
Secrets : mots de passe/clés/tokens/certificats/matériaux de cryptage.
Artefacts de confiance : certificats racine/intermédiaire, stratégies PKI, clés KMS.

Le principe du stockage séparé et des droits : secrets publics ≠ sensibles ≠.

3) Hiérarchie des configurations

1. Global defaults (org-wide).

2. Environment (`prod/stage/dev`).

3. Region (`eu-central-1`, `us-east-1`).

4. Tenant/Brand (pour multi-tenants).

5. Service (microservices spécifiques).

6. Override (runtime) - commutateurs temporaires.

Règles de fusion : « ci dessous gagne », le conflit ne passe que par MR/approval.

Exemple (YAML)

yaml defaults:
http:
timeout_ms: 800 retry: 2 prod:
http:
timeout_ms: 1200 service: payments-api overrides:
eu-central-1:
http:
timeout_ms: 1500

4) Schémas et validation

Chaque config est un contrat avec un schéma (JSON Schema/OPA/validateurs en CI).

Types, plages, champs obligatoires, valeurs par défaut.
Règles de garde (vous ne pouvez pas mettre « retry> 5 », « p95 _ target <50ms »).
Vérification automatique en IC et en application (admission-webhook/KRM).

Fragment JSON Schema

json
{
"type":"object",
"properties":{
"http":{"type":"object","properties":{"timeout_ms":{"type":"integer","minimum":100,"maximum":10000},"retry":{"type":"integer","minimum":0,"maximum":5}},"required":["timeout_ms"]},
"feature_flags":{"type":"object","additionalProperties":{"type":"boolean"}}
},
"required":["http"]
}

5) Modèles de livraison de configues

Statique (image-baked) : fiable, mais nécessite des restarts.
Push/Watch : les agents/sidecar reçoivent des mises à jour (stream/bou) et signalent à l'application.
Pull on startup : on obtient un snapshot au démarrage (simplifier le hot-path).
Edge cache/proxy pour les charges géo-distribuées.

L'essentiel : l'atomicité et la versionation des snapshots, le contrôle de compatibilité et le retour rapide.

6) Outils et rôles

Configues : Git (source de vérité) + GitOps (Argo/Flux), Parameter Store/Bou Service.
Entrepôts de secrets : Vault, AWS Secrets Manager/SSM, GCP Secrets, Azure KV.
Cryptage : KMS/HSM, SOPS (age/GPG/KMS), Sealed Secrets, cryptage Transit (Vault).
Livraison : CSI Secrets Store, Vault Agent Injecteur/Sidecar, conteneurs init.
Drapeaux/haut-parleurs : plate-forme de drapeaux de ficha (activé kill-switch d'urgence).

7) Cryptage : modèles et pratiques

At rest : Clés KMS du projet/environnement, encodage.
En transit : TLS/mTLS avec authentification mutuelle.
A utiliser : déchiffrement le plus tard possible, de préférence en mémoire de processus/sidecar (pas d'écriture sur disque).
Hiérarchie clé : root (HSM) → KMS CMK → data keys (DEK).
Rotation : calendrier (90/180 jours) + par événement (compromission/départ de l'employé).

8) Gestion des secrets : modèles

8. 1 GitOps + SOPS (snapshot statique)

Seul le chiffrement est stocké dans Git.
Décryptage dans CI/CD ou sur un cluster (KMS/age).
Application via le contrôleur (Flux/Argo) → Kubernetes Secret.

yaml apiVersion: v1 kind: Secret metadata: { name: psp-keys, namespace: payments }
type: Opaque data:
apiKey: ENC[AES256_GCM,data:...,sops]

8. 2 Vault Agent Injecteur (émission dynamique)

Le compte de service (JWT/SA) est authentifié dans Vault.
Sidecar met les crédits dans tmpfs et met à jour par TTL.
Support des crédits dynamiques (DB, cloud - isolation et courte durée).

yaml annotations:
vault. hashicorp. com/agent-inject: "true"
vault. hashicorp. com/role: "payments-api"
vault. hashicorp. com/agent-inject-secret-db: "database/creds/payments"

8. 3 CSI Secrets Store

Apparier un secret comme un volume, la rotation est transparente.
Pour PKI - Mise à jour automatique des certificats/clés.

9) Kubernetes : aspects pratiques

BouMap - données publiques/insensibles uniquement.
Secret - sensibles (avec base64 - pas de cryptage ; activer Encryption at Rest pour etcd).
Annotations checksum : Restart Deployment lorsque vous modifiez un config.
Admission-contrôle : interdiction de monter des secrets non de la « liste blanche », interdiction des mots de passe « plain » dans les manifestes.
Politique de réseau : limiter l'accès aux fournisseurs de secrets (Vault/CSI).

Checksum exemple (Helm)

yaml annotations:
checksum/config: {{ include (print $.Template. BasePath "/configmap. yaml"). sha256sum }}

10) Politiques d'accès (RBAC/ABAC)

Least privilège : le service ne voit que ses secrets ; accès par namespace/label/prefix.
Split duties : créer un secret ≠ lire le contenu ; audit de toute lecture.
Crédits temporels : logins dynamiques (DB, cloud) avec TTL et rotation automatique.
Segmentation : prod/stage dans différents projets/comptes/clés KMS.

11) Audit, journal, observabilité

Logs de lecture/émission de secrets : qui/quand/quoi/d'où ; corrélation avec les rejets et les incidents.
Métriques : taux d'appels, secrets expirés, certificats périmés, proportion de crédits dynamiques.
Événements de sécurité : dépassement des quotas, anomalies IP/temporelles, plusieurs erreurs d'authentification.

12) Rotation des secrets et des certificats

Normalisez les délais : clés API - 90 jours, mots de passe DB - 30 jours, TLS-serts - 60-90 jours.
Contour de rotation : génération → test → double publication (grace) → commutation → révocation de l'ancienne → de vérification.
Disponibilité : double enregistrement des configues/secrets, compatibilité client (accept new + old).
PKI : Propre CA ou intégration avec externe ; mise à jour automatique des matériaux mTLS via CSI/Vault.

13) Configis dynamiques et flags de fonction

Les paramètres « chauds » (limites, délais) sont pris à partir du service config/flag-platform.
Cache local et stick....( calcul de l'option par hachage), TTL courts.
Les gardes SLO modifient les paramètres sensibles (auto-retour et kill-switch).

14) Intégration avec CI/CD et GitOps

Pré-commit/CI : circuits linters, contrôles SOPS, interdiction des secrets « nus » (scanners : gitleaks/trufflehog).
Policy Gate : OPA/Conftest - Interdiction des configues sans schéma/sans annotations de propriétaire/sans étiquettes d'environnement.
Livraison progressive : promotion des configues comme artefacts (semver), canary pour modifier les paramètres.
Annotations de sortie : qui/quel config/secret a changé ; corrélation rapide avec p95/5xx.

15) Exemples

15. 1 Politique de l'OPA : interdire les SG ouverts dans le config

rego package policy. config

deny[msg] {
input. kind == "SecurityGroupRule"
input. cidr == "0. 0. 0. 0/0"
input. port = = 5432 msg: = "Postgres open internet banned"
}

15. 2 Exemple de « snapshot » configh (versionable)

yaml version: 1. 12. 0 owner: payments-team appliesTo: [ "payments-api@prod" ]
http:
timeout_ms: 1200 retry: 2 withdraw:
limits:
per_txn_eur: 5000 per_day_eur: 20000 flags:
new_withdrawal_flow: false

15. 3 Vault - Crédits DB dynamiques

hcl path "database/creds/payments" {
capabilities = ["read"]
}
role issues user/password with TTL = 1h and auto-rollover

16) Anti-modèles

Les secrets dans Git sont ouverts/dans les variables Helm/Ansible sans chiffrement.
Un « méga-secret » unique pour tous les services/environnements.
Des jetons de longue durée sans TTL/rotation ; certificats « immortels ».
Configurations dynamiques sans schémas/validation et sans vérification des modifications.
Aucun Encryption at Rest pour etcd/KMS et réseau sans mTLS.
Édition manuelle des configues dans la vente (contournement de GitOps).
L'accès des développeurs aux secrets « au cas où ».

17) Chèque de mise en œuvre (0-60 jours)

0-15 jours

Activer les schémas/validateurs pour les configues ; créer un repo « configs » et un flux GitOps.
Soulevez KMS et cryptage : SOPS/Sealed Secrets/Encryption at Rest dans etcd.
Interdire les secrets de playtext dans le CI (scanners), entrer owners/approvals.

16-30 jours

Diviser les coffres : configi publics vs sensibles vs secrets.
Mettre en œuvre Vault/Secrets Manager, sélectionner le chemin de livraison (Agent/CSI/SOPS).
Configurer la rotation des crédits TLS/DB/PSP ; dashboards « durée de vie/expirant ».

31-60 jours

Configues dynamiques et drapeaux avec SLO-Gate et auto-retour.
Politiques OPA/Conftest ; zero-trust (namespace/label-scoped access).
Game-day : simulation de fuite de secret et de rotation de force.

18) Métriques de maturité

% de secrets sous cryptage et sans accès direct depuis Git = 100 %.
Couverture des fligs par schémas/validation ≥ 95 %.
Temps moyen de rotation des secrets critiques (objectif : heures, pas jours).
Part des crédits dynamiques (DB/cloud) ≥ 80 %.
0 incidents dus à « plain secrets « /certificats périmés.
MTTR en cas d'erreur de configh avec un retour en arrière <5 minutes.

19) Rôles et processus d'équipe

Bou Owner : propriétaire du domaine/schémas/stratégies.
Sécurité : politiques, hiérarchie clé, audit d'accès.
Plateforme/SRE : GitOps, approvisionnement/injection, télémétrie.
App Teams : consommation de configues/secrets, tests de compatibilité.

20) Conclusion

Les schémas + GitOps + cryptage + rotation + politique constituent un circuit fiable de configurations et de secrets. Séparez le public et le secret, chiffrez tout, appliquez les configis de manière atomique et versionable, réduisez les droits et la durée de vie des creds, automatisez les rotations et les audits. Les changements deviendront alors rapides et sûrs, et le risque de fuites et de chutes sera minime.