Gestionați configurațiile și secretele

Gestionați configurațiile și secretele

1) De ce aveți nevoie de ea

• Previzibil (scheme, validare, versiuni).
• Secure (criptare, drepturi minime, rotație).
• Gestionat (GitOps, audit, rollback-uri).
• Dinamică în cazul în care este justificată (caracteristică steaguri, parametrizarea limitelor).

2) Clasificarea artefactelor

Configurații publice: caracteristici, praguri, timeout-uri, steaguri de caracteristici (fără secrete).
Configurații sensibile: parametrii care schimbă comportamentul căilor critice (de exemplu, limitele de plată).
Secrete: parole/chei/jetoane/certificate/materiale de criptare.
Artefacte de încredere: rădăcină/certificate intermediare, politici PKI, chei KMS.

Principiul stocării și drepturilor separate: secrete ≠ publice ≠ sensibile.

3) Ierarhia de configurare

1. Valori implicite globale (org-wide).

2. Mediu („prod/stage/dev”).

3. Regiune („eu-central-1”, „us-east-1”).

4. Chiriaș/Brand (pentru multi-chiriași).

5. Service (microservice specific).

6. Suprascriere (runtime) - comutatoare temporare.

Reguli de fuziune: „mai jos câștigă”, conflict - numai prin MR/aprobare.

Exemplu (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) Scheme și validare

Fiecare config este un contract cu o schemă (JSON Schema/OPA/validatori în CI).

Tipuri, intervale, câmpuri obligatorii, valori implicite.
"Reguli de pază" (nu poate fi setat la "încercați din nou> 5", "p95 _ target <50ms').
Verificarea automată în CI și atunci când se aplică (admitere-webhook/KRM).

JSON Schema Fragment

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) Config Modele de livrare

Static (copt imagine): fiabil, dar necesită reporniri.
Push/Watch :/agenții atașați primesc actualizări (stream/poll) și semnalizează aplicația.
Trageți la pornire: obținem un instantaneu la pornire (simplificați calea fierbinte).
Edge cache/proxy pentru sarcini geo-distribuite.

Principalul lucru: atomicitatea și versioning de instantanee, controlul compatibilității și rollback rapid.

6) Instrumente și roluri

Magazine de configurare: Git (sursa adevărului) + GitOps (Argo/Flux), Parametru Store/Config Service.
Depozite secrete: Vault, AWS Secrets Manager/SSM, Secretele GCP, Azure KV.
Criptare: KMS/HSM, SOPS (vârstă/GPG/KMS), secrete sigilate, criptare tranzit (Vault).
Livrare: CSI Secrets Store, Vault Agent Injector/Sidecar, init-containere.
Steaguri/dinamică: caracteristică platformă de pavilion (inclusiv kill-switch de urgență).

7) Criptare: Modele și practici

În rest: cheile KMS ale proiectului/mediului, criptarea plicului.
În tranzit: TLS/mTLS cu autentificare reciprocă.
La utilizare: decriptare cât mai târziu posibil, de preferință în memoria de proces/sidecar (fără a scrie pe disc).
Ierarhia cheie: rădăcină (HSM) → KMS CMK → taste de date (DEK).
Rotație: calendar (90/180 zile) + după eveniment (compromis angajat/plecare).

8) Managementul secret: Modele

8. 1 GitOps + SOPS (instantaneu static)

Git stochează doar cifrtext.
Decriptare în CI/CD sau pe un cluster (KMS/vârstă).
Aplicarea prin controler (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 Injector agent seif

Contul de serviciu (JWT/SA) este autentificat în Vault.
Sidecar pune credite în tmpfs și actualizări pe TTL.
Suport pentru credite dinamice (DB, cloud - izolare și pe termen scurt).

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 Secretele Magazin

Montați secretul ca volum, rotația este transparentă.
Pentru PKI - reînnoirea automată a certificatelor/cheilor.

9) Kubernete: practici

ConfigMap - numai date publice/insensibile.
Secret - sensibil (cu base64 - nu criptare; activați criptarea la Rest pentru etcd).
Adnotări Checksum: reporniți Implementarea la schimbarea configurației.
Controlul admiterii: interzicerea montării secretelor nu din „lista albă”, interzicerea parolelor „simple” în manifeste.
Politica de rețea: restricționați accesul la furnizorii secreți (Vault/CSI).

Exemplu de sumă de control (Helm)

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

10) Politici de acces (RBAC/ABAC)

Cel mai puțin privilegiu: serviciul își vede doar secretele; acces prin namespace/etichetă/prefix.
Sarcini împărțite: crearea unui conținut secret ≠ citire; audit orice citește.
Credite temporare: conectări dinamice (DB, cloud) cu TTL și rotație automată.
Segmentare: prod/etapă în diferite proiecte/conturi/taste KMS.

11) Audit, exploatare forestieră, observabilitate

Jurnalele de lectură/eliberare secrete: cine/când/ce/unde; corelație cu eliberările și incidentele.
Valori: frecvența apelurilor, secretele expirate, certificatele expirate, cota de credite dinamice.
Evenimente de securitate - cotă depășită, anomalii IP/time, mai multe autentificări eșuate.

12) Rotația secretelor și certificatelor

Standardizarea termenilor: chei API - 90 de zile, parole DB - 30 de zile, serturi TLS - 60-90 de zile.
Schița de rotație: generarea → testul → publicarea dublă (grație) → comutarea → revocarea verificării → vechi.
Fiabilitate: intrare dublă de configurații/secrete, compatibilitate client (accepta nou + vechi).
PKI: propriul AC sau integrarea cu unul extern; Actualizați automat conținutul mTLS prin CSI/Vault.

13) Configurații dinamice și steaguri de caracteristici

Luați parametrii „fierbinți” (limite, timeout-uri) de pe platforma de servicii/pavilion de configurare.
Cache-ul local și lipiciozitatea (calculul variantei prin hash), TTL scurt.
Garda SLO pentru a schimba parametrii sensibili (auto-rollback și kill-switch).

14) Integrarea cu CI/CD și GitOps

Pre-comite/CI: lintere de circuit, controale SOPS, interzicerea secretelor „goale” (scanere: gitleaks/trufflehog).
Policy Gate: OPA/Conftest - dezactivați configurațiile fără schemă/fără adnotări ale proprietarului/fără etichete de mediu.
Livrare progresivă: promovarea configurațiilor ca artefacte (semver), canar pentru schimbarea parametrilor.
Eliberați adnotări: cine/ce config/secret schimbat; corelație rapidă cu p95/5xx.

15) Exemple

15. 1 Politica OPA: Interzicerea SG-urilor deschise în configurații

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 Exemplu de instantaneu de configurare (versionat)

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 - credite dinamice pentru baze de date

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

16) Anti-modele

Secretele în Git în text clar/în Helm/variabile Ansible fără criptare.
Un singur „mega-secret” pentru toate serviciile/mediile.
Jetoane cu durată lungă de viață fără TTL/rotație; certificate „nemuritoare”.
Configurații dinamice fără scheme/validare și fără modificări de audit.
Nu există criptare în Rest pentru rețeaua etcd/KMS și non-mTLS.
Editarea manuală a configurațiilor din produs (ocolind GitOps).
Accesul dezvoltatorilor la secrete comerciale „pentru orice eventualitate”.

17) Lista de verificare a implementării (0-60 zile)

0-15 zile

Include diagrame/validatoare pentru configurații; start repo „configs” și fluxul GitOps.
Ridicați KMS și criptare: SOPS/Secrete sigilate/Criptare la odihnă în etcd.
Interziceți secretele textului clar în CI (scanere), introduceți proprietarii/aprobările.

16-30 zile

Împărțiți bolțile: configurații publice vs secrete sensibile vs.
Implementați Vault/Secrets Manager, selectați calea de livrare (Agent/CSI/SOPS).
Configurați rotația creditelor TLS/DB/PSP; tablouri de bord „durata de viață/expirarea”.

31-60 zile

Configurații dinamice și steaguri cu SLO-gating și auto-rollback.
politici OPA/Conftest; zero-trust (namespace/label-scoped access).
Joc-zi: simularea scurgerilor secrete și rotația forței.

18) Valorile maturității

% din secretele sub criptare și fără acces direct de la Git = 100%.
Acoperirea de configurare/validare ≥ de 95%.
Timpul mediu de rotire a secretelor critice (țintă: ore, nu zile).
Ponderea creditelor dinamice (DB/cloud) ≥ de 80%.
0 incidente datorate „secretelor simple „/certificatelor expirate.
MTTR pe eroare de configurare cu rollback <5 minute.

19) Roluri și procese de comandă

Proprietar de configurații: Proprietar de domenii/scheme/politici.
Securitate: politici, ierarhie cheie, audit de acces.
Platformă/SRE: GitOps, alimentare/injectare, telemetrie.
Echipe de aplicații: config/consum secret, teste de compatibilitate.

20) Concluzie

Un contur fiabil de configurații și secrete sunt + GitOps + criptare + rotație + scheme de politici. Separat public și secret, criptați totul, aplicați configurații atomic și versional, minimizați drepturile și durata de viață a creditelor, automatizați rotațiile și auditurile. Apoi, schimbările vor deveni rapide și sigure, iar riscul de scurgeri și căderi va fi minim.