Întărirea Kubernetes pentru Sarcini de Lucru de Apărare: Benchmark-uri CIS și Ghiduri NSA

Kubernetes a devenit platforma standard de implementare pentru aplicațiile containerizate în apărare, de la DoD Platform One la programele naționale de cloud de apărare din statele membre NATO. Adoptarea sa în mediile de apărare este determinată de aceleași avantaje operaționale care au impulsionat adoptarea comercială: implementare consecventă în toate mediile, scalare automată, sarcini de lucru cu auto-vindecare și managementul infrastructurii declarative. Dar o instalare implicită Kubernetes este concepută pentru ușurința utilizării, nu pentru securitate — iar diferența de securitate dintre o instalare implicită și o implementare întărită, de nivel de apărare, este semnificativă.

NSA și CISA au publicat Ghidul de Întărire Kubernetes (v1.2, august 2022) special pentru a aborda acest decalaj. Ghidul acoperă întărirea planului de control, securitatea rețelei, securitatea pod-urilor, jurnalizarea auditului și autentificarea și autorizarea — oferind un punct de plecare practic pentru implementările Kubernetes de apărare. Benchmark-ul Kubernetes CIS oferă un set complementar, mai granular de verificări de configurare notate. Împreună, aceste două documente definesc ce înseamnă „întărit" pentru Kubernetes în context de apărare.

Ghidul de Întărire Kubernetes NSA/CISA: Recomandări Cheie

Ghidul NSA/CISA organizează recomandările în șase categorii. Cele mai semnificative din punct de vedere operațional pentru apărare sunt:

Securitatea pod-urilor Kubernetes. Pod-urile ar trebui să folosească containere non-root, sisteme de fișiere root doar pentru citire și să aibă capacitățile reduse la minimul necesar. Containerele privilegiate — care au acces complet la sistemul gazdă — nu trebuie permise în sarcinile de lucru de producție.

Separarea și întărirea rețelei. Tot traficul inter-servicii ar trebui criptat folosind TLS (service mesh cu mTLS). Politicile de rețea ar trebui să restricționeze comunicarea pod-la-pod la căile explicit permise. Serverul API Kubernetes nu ar trebui să fie direct accesibil de pe internet sau din segmentele de rețea nesigure.

Autentificare și autorizare. Serverul API nu trebuie să permită autentificarea anonimă sau porturile nesecurizate. Controlul Accesului Bazat pe Roluri (RBAC) trebuie activat și configurat urmând principiile privilegiului minim. Token-urile conturilor de serviciu nu ar trebui montate automat pe pod-uri care nu necesită acces la serverul API.

Jurnalizarea auditului. Jurnalizarea auditului serverului API trebuie activată cu o politică care captează cel puțin operațiunile de creare, actualizare, ștergere și obținere pe tipurile de resurse sensibile. Jurnalele de audit trebuie transmise la un SIEM central sau sistem de management al jurnalelor unde nu pot fi modificate de administratorii clusterului.

Frecvența actualizărilor. Versiunile Kubernetes primesc patch-uri de securitate timp de aproximativ 14 luni după lansare. Rularea versiunilor Kubernetes nesuportate reprezintă un risc semnificativ de securitate care este inacceptabil în implementările de apărare.

Standarde de Securitate Pod: Profilul Restricted

Standardele de Securitate Pod Kubernetes (PSS) definesc trei profiluri de politică — Privileged, Baseline și Restricted — care reprezintă niveluri crescânde de restricție asupra configurației pod-urilor. Profilul Restricted este baza de referință corespunzătoare pentru sarcinile de lucru de apărare: aplică cele mai relevante constrângeri de configurare ale pod-urilor din perspectiva securității.

Profilul Restricted interzice: containerele privilegiate (containere cu indicatorul privileged setat la true), containerele care rulează ca root (aplicate prin runAsNonRoot: true), containerele care accesează rețeaua gazdă (hostNetwork: false), containerele care accesează PID-urile sau IPC-urile gazdei (hostPID: false, hostIPC: false), containerele care montează căi gazdă ca volume și containerele care adaugă capacități Linux dincolo de o listă de permisiuni definită.

Implementarea profilului Restricted într-un mediu Kubernetes existent necesită adesea modificări ale aplicațiilor: aplicațiile scrise presupunând acces root, acces de scriere la sistemul de fișiere sau acces la rețeaua gazdă trebuie refactorizate pentru a funcționa în profilul Restricted. Pentru noile proiecte de aplicații de apărare, conformitatea cu profilul Restricted ar trebui să fie o cerință de proiectare de la bun început — adaptarea retroactivă după implementare este semnificativ mai costisitoare.

Standardele de Securitate Pod sunt aplicate prin controlerul de admisie integrat PodSecurity (disponibil de la Kubernetes 1.25, înlocuind PodSecurityPolicy deprecat). Modurile de aplicare sunt Enforce (pod-urile care încalcă politica sunt respinse), Audit (încălcările sunt înregistrate, dar pod-urile sunt permise) și Warn (încălcările generează avertismente API, dar pod-urile sunt permise). Implementările de apărare ar trebui să utilizeze modul Enforce pentru profilul Restricted în toate spațiile de nume de producție.

Politici de Rețea: Microsegmentare cu Calico sau Cilium

Politicile de Rețea Kubernetes definesc ce pod-uri pot comunica cu ce alte pod-uri la nivelul IP/port. Fără Politici de Rețea, toate pod-urile dintr-un cluster pot comunica cu toate celelalte pod-uri — o topologie de rețea plată care este incompatibilă arhitectural cu principiile zero-trust. Politicile de Rețea implementează stratul de microsegmentare la nivelul rețelei de containere.

Calico este implementarea de politici de rețea Kubernetes cea mai larg utilizată, suportând atât resursele standard Kubernetes NetworkPolicy, cât și resursele GlobalNetworkPolicy și NetworkPolicy specifice Calico cu capacități suplimentare. Calico poate fi implementat în mai multe moduri (rutare BGP, suprapunere VXLAN sau plan de date eBPF) și se integrează cu firewall-uri externe prin publicarea rutelor BGP. Pentru mediile de apărare air-gapped, modelul de implementare on-premises al Calico și lipsa dependențelor de planul de control cloud îl fac operațional adecvat.

Cilium folosește eBPF (Extended Berkeley Packet Filter) pentru aplicarea politicii de rețea în kernelul Linux, oferind performanțe superioare soluțiilor bazate pe iptables și suportând politici de rețea de Strat 7 (strat aplicație) — de exemplu, permițând cererile HTTP GET dar blocând cererile POST pe o cale API specifică. Componenta de observabilitate Hubble a Cilium oferă vizibilitate detaliată în fluxurile de rețea, suportând atât monitorizarea securității, cât și depanarea. Integrarea Cilium cu SPIFFE/SPIRE pentru identitatea sarcinilor de lucru oferă o cale spre microsegmentarea bazată pe mTLS fără o implementare completă de service mesh.

Principiul cheie pentru proiectarea Politicii de Rețea de apărare este blocare implicită: noile spații de nume ar trebui să aibă o NetworkPolicy implicită de blocare care blochează toate intrările și ieșirile până la crearea de reguli de permisiune explicite. Aceasta asigură că noile sarcini de lucru sunt izolate până când cerințele lor de acces la rețea sunt documentate și aprobate explicit, în loc să moștenească valoarea implicită permisivă.

Controlere de Admisie: Politică-ca-Cod cu OPA/Gatekeeper și Kyverno

Controlerele de admisie sunt plugin-uri care interceptează cererile serverului API înainte de a fi persistate în etcd, permițând aplicarea politicilor la nivelul API al clusterului. OPA/Gatekeeper și Kyverno sunt cele două cadre dominante de politică-ca-cod pentru controlul admisiei Kubernetes.

OPA/Gatekeeper folosește motorul de politici OPA (Open Policy Agent) cu limbajul de politici Rego. Gatekeeper se înregistrează ca ValidatingAdmissionWebhook care apelează motorul de politici OPA pentru fiecare cerere API relevantă. Șabloanele de Constrângere definesc structura politicii; Constrângerile instanțiază șablonul pentru resurse specifice. Ecosistemul OPA/Gatekeeper are o bibliotecă mare de politici pre-construite acoperind cerințele de securitate comune, iar politicile personalizate pot fi scrise în Rego pentru cerințele specifice organizației.

Kyverno folosește YAML nativ Kubernetes pentru a exprima politici, ceea ce îl face mai accesibil echipelor familiare cu definițiile de resurse Kubernetes dar neconfortabile cu Rego. Kyverno suportă atât validarea (blocarea resurselor neconforme), cât și mutația (adăugarea automată a etichetelor necesare sau a câmpurilor de context de securitate la resursele care le lipsesc). Capacitatea webhook de admisie mutantă a Kyverno este deosebit de utilă pentru aplicarea automată a valorilor implicite de securitate, reducând sarcina pentru dezvoltatorii de aplicații.

Pentru implementările de apărare, politicile de control al admisiei ar trebui să aplice cel puțin: proveniența imaginilor (imaginile trebuie să provină din registre aprobate), semnarea imaginilor (imaginile trebuie să aibă semnături cosign valide), cerințele contextului de securitate (non-root, fără privilegii, fără spații de nume gazdă), etichetele necesare (pentru urmărirea activelor și raportarea conformității) și limitele de resurse (toate containerele trebuie să aibă limite CPU și memorie definite).

Securitate Runtime: Falco, seccomp și AppArmor

Falco (certificat CNCF) este instrumentul standard de securitate runtime pentru Kubernetes: monitorizează apelurile de sistem kernel în timp real și generează alerte când comportamentul corespunde modelelor suspecte. Regulile Falco acoperă execuția proceselor (executabile neașteptate care rulează în interiorul containerelor), accesul la fișiere (scrieri în directoare de sistem, citiri ale fișierelor sensibile), activitatea de rețea (conexiuni de ieșire neașteptate din containere) și activitatea API Kubernetes (apeluri API neautorizate, tentative de furt de credențiale). Falco se integrează cu sistemele SIEM prin ieșire syslog sau Webhook, alimentând evenimentele de runtime ale containerelor în infrastructura mai largă de monitorizare a securității.

Profilurile seccomp (mod de calcul securizat) restricționează apelurile de sistem disponibile proceselor containerizate. Un proces dintr-un container care rulează cu un profil seccomp poate efectua doar apelurile de sistem explicit permise de acel profil — toate celelalte sunt blocate. Kubernetes furnizează un profil seccomp implicit (RuntimeDefault) care blochează cele mai periculoase apeluri de sistem permițând operarea normală a aplicației. Sarcinile de lucru de apărare ar trebui să utilizeze cel puțin profilul RuntimeDefault; sarcinile de lucru cu risc ridicat ar trebui să folosească profiluri personalizate chiar mai restrictive.

AppArmor (pe distribuțiile Linux care îl suportă) oferă un strat de Control de Acces Obligatoriu care restricționează ce fișiere, capacități și operațiuni de rețea poate accesa fiecare proces. Profilurile AppArmor pentru containerele Kubernetes definesc ce poate face procesul containerizat, adăugând un strat de apărare în profunzime sub runtime-ul containerului și deasupra kernelului.