Gestione di configurazioni e segreti

Gestione di configurazioni e segreti

1) Perché è necessario

• Prevedibili (schemi, convalida, versioni).
• Sicuro (crittografia, diritti minimi, rotazione).
• Gestiti (GitOps, verifiche, rimborsi).
• Dinamiche se giustificate (feature flags, parametrizzazione dei limiti).

2) Classificazione degli artefatti

Confighi pubblici: feci, soglie, timeout, feature flags (senza segreti).
Configi sensibili: parametri che cambiano il comportamento dei percorsi critici (ad esempio i limiti di pagamento).
I segreti sono password/chiavi/token/certificati/materiale di crittografia.
Gli artefatti di fiducia sono certificati radici/intermedi, criteri PKI, chiavi KMS.

Il principio della separazione dei diritti è un segreto pubblico e sensibile.

3) Gerarchia delle configurazioni

1. Global defaults (org-wide).

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

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

4. Tenant/Brand (per multi-tenenti).

5. Servizio (microservice specifico).

6. Override è un interruttore temporaneo.

Regole di fusione: «sotto vince», conflitto solo con MR/approval.

Esempio (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) Schemi e convalida

Ogni config è un contratto con uno schema (JSON Schema/OPA/convalidanti in CI).

Tipi, intervalli, campi obbligatori, valori predefiniti.
Regole guard (non è possibile impostare retry> 5 ',' p95 _ target <50ms ').
Controllo automatico in CI e durante l'applicazione (admision-webhook/KRM).

Frammento di 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) Modelli di spedizione configure

Static (immagine-baked): affidabile, ma richiede restart.
Push/Watch: agenti/sidecar ricevono aggiornamenti (stream/poll) e segnalano l'applicazione.
Pull on startup - Riceviamo un snap al lancio (semplificare hot-path).
Edge cache/proxy per carichi geo-distribuiti.

L'importante è l'atomatologia e la versionizzazione dei snapshot, il controllo della compatibilità e il rapido ritorno.

6) Strumenti e ruoli

Magazzini: Git (sorgente verità) + GitOps (Argo/Flux), Parameter Store/Config Service.
Archivi segreti: Vault, AWS Secret Manager/SSM, GCP Secret, Azure KV.
Crittografia: KMS/HSM, SOPS (age/GPG/KMS), Sealed Secret, Transit Crittografia (Vault).
Consegna: CSI Secret Store, Vault Agente Inquector/Sidecar, contenitori init.
Flag/altoparlanti - Piattaforma flag (kill-switch di emergenza).

7) Crittografia: modelli e pratiche

At rest: KMS di progetto/ambiente, crittografia envelope.
In transit, autenticazione reciproca.
At use: decodifica il più tardi possibile, preferibilmente nella memoria del processo/sidecar (senza scrittura su disco).
Gerarchia chiave: root (HSM) KMS CMK data keys (DEK).
Rotazione: calendario (90/180 giorni) + per evento (compromissione/ritiro del dipendente).

8) Gestione dei segreti: pattern

8. 1 GitOps + SOPS (snap statico)

Il Git contiene solo un cifrotexto.
Decodifica in CHI/CD o in un cluster (KMS/age).
Applicazione tramite controller (Flux/Argo) di Kubernets Secret.

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

8. 2 Vault Agente Inquector (rilascio dinamico)

L'account di servizio (JWT/SA) viene autenticato in Vault.
Sidecar mette credenziali in tmpfs e aggiorna con TTL.
Supporto dei crediti dinamici (DB, cloud - isolamento e breve durata).

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

Prima del segreto come volume, la rotazione è trasparente.
Per PKI, aggiornamento automatico dei certificati/chiavi.

9) Kubernets: aspetti pratici

Solo dati pubblici o insensibili.
Segreto - Sensibili (con base64 - non crittografia; attivare Encryption at Rest per etcd).
Annotazioni checksum - Restart Deployment quando il config viene modificato.
Admision Control: impedisce il montaggio di segreti non da «white list», impedisce le password «plain» nei manifesti.
NetworkPolicy Limita l'accesso ai provider di segreti (Vault/CSI).

Checksum esempio (Helm)

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

10) Criteri di accesso (RBAC/ABAC)

Least private: il servizio vede solo i suoi segreti; accesso a namespace/label/preferix.
Split duties: creazione di un segreto, lettura del contenuto Controllo di tutte le letture.
Crediti temporanei: login dinamici (DB, cloud) con TTL e rotazione automatica.
Segmentazione: prod/stage in diversi progetti/account/KMS.

11) Controllo, registrazione, osservazione

Fogli di lettura/rilascio di segreti: chi/quando/cosa/da dove; correlazione con comunicati e incidenti.
Metriche: frequenza di accessi, segreti scaduti, certificati scaduti, percentuale di crediti dinamici.
Eventi di protezione: eccesso di quote, anomalie IP/tempo, autenticazione multipla non riuscita.

12) Rotazione di segreti e certificati

Standard: chiavi API di 90 giorni, password DB di 30 giorni, serti TLS di 60-90 giorni.

Tracciato di rotazione - Generazione di test di , doppia pubblicazione (grace),

Disabilitazione: doppia scrittura di configuri/segreti, compatibilità client (accept new + old).
PKI: propria CA o integrazione con l'esterno aggiornamento automatico dei materiali mTLS tramite CSI/Vault.

13) Confighi dinamici e feature flags

Le opzioni hot (limiti, timeout) vengono prese dal servizio config/flag.
Cache locale e stickava, TTL brevi.
Protettori SLO per la modifica di parametri sensibili (auto-reimpostazione e kill-switch).

14) Integrazione con CI/CD e GitOps

Pre-commit/CI: lenti di schema, controlli SOPS, proibizione di segreti «nudi» (scanner: gitleaks/trofflehog).
Policy Gate: OPA/Conftest - Proibisce configurazioni senza schema/senza annotazioni del proprietario/senza etichette dell'ambiente.
Progressive delivery - Promozione di configurazioni come manufatti (semver), canary per la modifica dei parametri.
Annotazioni di rilascio: chi/quale config/segreto ha cambiato; correlazione rapida con p95/5xx.

15) Esempi

15. 1 Criterio OPA - Proibire SG aperti in configure

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 Esempio di «snapshot» config (versionabile)

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 - credenze dinamiche del database

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

16) Anti-pattern

I segreti in Git in pubblico/nelle variabili Helm/Ansible senza crittografia.
Un unico mega-segreto per tutti i servizi/ambienti.
Token a lunga vita senza TTL/rotazione; certificati «immortali».
Configli dinamici senza diagrammi/convalida e senza controllo delle modifiche.
Nessuna Encryption at Rest per etcd/KMS e rete senza mTLS.
Modifica manuale dei configli in vendita (giro di GitOps).
Accesso agli sviluppatori ai segreti prod per sicurezza.

17) Assegno foglio di implementazione (0-60 giorni)

0-15 giorni

Attivare diagrammi/validatori per configure attivare il repo «configs» e il flusso GitOps.
Alza KMS e crittografia: SOPS/Sealed Secret/Encryption at Rest in etcd.
Disattiva i segreti plintest in CI (scanner), inserisci owners/approvals.

16-30 giorni

Separare il magazzino: configi pubblici vs sensibili vs segreti.
Implementare Vault/Secret Manager, selezionare il percorso di consegna (Agente/CSI/SOPS).
Configura la rotazione TLS/DB/PSP; I dashboard sono in scadenza.

31-60 giorni

Confighi dinamici e bandiere con SLO-gating e auto-recupero.
Criteri OPA/Conftest; zero-trust (namespace/label-scoped access).
Game-day - Simulazione di una perdita di segreto e di una rotazione di forza.

18) Metriche di maturità

% di segreti crittografati e senza accesso diretto da Git = 100%.
La copertura delle configure con schemi/convalida è pari al 95%.
Tempo medio di rotazione dei segreti critici (obiettivo: orologi, non giorni).
La percentuale di crediti dinamici (DB/cloud) è pari all '80%.
0 incidenti dovuti a «plain secret «/certificati scaduti.
MTTR in caso di errore di config con disattivazione <5 minuti.

19) Ruoli di comando e processi

Config Owner - Proprietario di dominio/diagrammi/regole.
Sicurezza: criteri, gerarchia chiave, controllo dell'accesso.
Platform/SRE: GitOps, spedizione/iniezione, telemetria.
App Teams: uso di configure/segreti, test di compatibilità.

20) Conclusione

Un tracciato affidabile di configurazioni e segreti sono schemi + GitOps + crittografia + rotazione + criteri. Separare pubblico e segreto, cifrare tutto, applicare configi atomaro e versionabile, ridurre al minimo i diritti e la durata dei crediti, automatizzare le rotazioni e le verifiche. Allora il cambiamento diventerà rapido e sicuro, e il rischio di perdite e cadute sarà minimo.