SOPS și Sealed Secrets: țineți textul clar în afara Git pentru Kubernetes MSP

Două proiecte open-source consacrate, getsops/sops și bitnami/sealed-secrets, acoperă o lacună comună în pipeline-urile GitOps: menținerea valorilor secrete în afara textului clar din controlul versiunilor, permițând totuși clusterului potrivit să le decripteze automat.

Ce face fiecare instrument

SOPS, cu aproximativ 22.000 de stele pe GitHub, criptează fișierele de configurare și secrete înainte de a fi comise, folosind age, PGP sau backend-uri de tip cloud KMS. Accesul la decriptare este controlat de cine deține cheia, separat de cine are acces de citire la repository. Sealed Secrets, menținut cu aproximativ 9.000 de stele, adoptă o abordare legată de cluster: un instrument client-side criptează un Secret Kubernetes împotriva cheii publice a clusterului țintă, producând o resursă personalizată SealedSecret care poate fi stocată în siguranță în Git. Doar controlerul din cluster, care deține cheia privată corespunzătoare, îl poate transforma înapoi într-un Secret utilizabil.

Unde se potrivesc și ce nu înlocuiesc

Folosite împreună, cele două instrumente acoperă jumătăți complementare ale aceleiași probleme: SOPS protejează fișiere arbitrare înainte de a ajunge în Git, iar Sealed Secrets protejează cazul specific al unui Secret Kubernetes legat de un singur cluster. Niciunul nu înlocuiește rotația credențialelor, controlul accesului bazat pe roluri sau izolarea rețelei – un SealedSecret este sigur de comis, dar rămâne totuși text cifrat pentru o limită specifică de decriptare, nu un substitut pentru accesul cu privilegii minime. Igiena practică contează aici: restricționați cine poate rula o operațiune de decriptare în CI, nu afișați niciodată valorile decriptate în jurnalele de build și monitorizați sănătatea controlerului Sealed Secrets și programul său de rotație a cheilor de sigilare. Validați orice modificare a pipeline-ului într-un cluster non-producție înainte de a-l implementa.

Obiceiul care merită adoptat

Valoarea fiecărui instrument constă în controlul pe care îl impune – un build care eșuează când un secret în text clar se strecoară într-un commit sau o limită de decriptare pe care o poate traversa doar un singur cluster – nu numele instrumentului pe un slide. Fixați versiunile, păstrați fișierele criptate revizuibile în pull request-uri și tratați rotația cheilor ca pe o sarcină programată, nu ca pe un răspuns la incident.

Surse: getsops/sops, bitnami/sealed-secrets.