Kubernetes pentru sarcini de lucru de apărare: orchestrarea aplicațiilor containerizate clasificate

Orchestrarea containerelor a devenit tiparul dominant de implementare pentru software-ul modern de apărare, însă cerințele de securitate operațională ale mediilor clasificate impun constrângeri pe care configurațiile standard Kubernetes nu le abordează implicit. Un cluster bootstrapat standard cu kubeadm expune API-uri kubelet neautentificate, stochează Secretele în text simplu în etcd, nu aplică nicio politică de rețea între pod-uri și generează jurnale de audit care nu sunt nici transmise, nici protejate împotriva alterării. Fiecare dintre aceste valori implicite constituie o constatare în orice revizuire serioasă de securitate. Acest articol acoperă ce este necesar pentru a rula Kubernetes corect într-un mediu clasificat: de la întărirea nodurilor față de liniile de bază CIS și STIG, prin gestionarea secretelor susținută de HSM, microsegmentarea rețelei, arhitectura jurnalelor de audit, controalele lanțului de aprovizionare al imaginilor, și calea documentară către o Autoritate de Operare.

De ce orchestrarea containerelor contează pentru implementarea software-ului modern de apărare

Software-ul de apărare a fost implementat în mod tradițional ca aplicații monolitice pe servere fizice dedicate, fiecare actualizare de sistem necesitând coordonare manuală între mai multe domenii de securitate și retestare extensivă înainte ca orice modificare să ajungă într-un mediu operațional. Orchestrarea containerelor inversează acest model: aplicațiile sunt împachetate ca imagini imutabile, infrastructura este declarată ca și cod, iar orchestratorul gestionează programarea, verificarea stării de sănătate și actualizările continue pe o flotă de noduri. Pentru programele care trebuie să transmită actualizări de capabilitate operatorilor în săptămâni, nu în ani, această schimbare nu este opțională.

Kubernetes aduce beneficii suplimentare care sunt relevante în mod specific pentru sarcinile de lucru clasificate. Izolarea resurselor la nivel de spațiu de nume permite mai multor aplicații la același nivel de clasificare să partajeze infrastructura nodurilor fără a interfera cu resursele CPU, memorie sau rețea ale celorlalte. Cotele de resurse previn ca o sarcină de lucru defectă să consume toată capacitatea clusterului. Bugetele de întrerupere a pod-urilor impun constrângeri de disponibilitate în perioadele de mentenanță. Aceste controale corespund direct cerințelor de fiabilitate și izolare pe care responsabilii cu autorizarea se așteaptă să le vadă documentate într-un Plan de Securitate a Sistemului.

Provocarea este că proiectul Kubernetes este conceput pentru medii cloud comerciale cu acces la internet, iar configurația sa implicită reflectă această moștenire. Programele de apărare care adoptă Kubernetes trebuie să trateze configurația implicită ca punct de plecare pentru întărire, nu ca o linie de bază acceptabilă. Decalajul dintre un cluster implicit și un cluster pregătit pentru acreditare este substanțial, dar este bine documentat de DISA și Center for Internet Security și poate fi eliminat printr-o muncă deliberată de configurare.

Întărirea nodurilor: conformitatea CIS benchmark și STIG pentru nodurile de lucru Kubernetes

Întărirea nodurilor începe la nivelul sistemului de operare înainte ca orice componentă Kubernetes să fie instalată. Nodurile de lucru trebuie construite dintr-o imagine de bază întărită STIG sau CIS Nivel 2 -- Red Hat Enterprise Linux CoreOS (RHCOS) pentru clusterele bazate pe OpenShift, sau un build Ubuntu sau Rocky Linux întărit pentru Kubernetes upstream. Configurația OS de bază acoperă partiționarea sistemului de fișiere (montaje separate /tmp, /var, /var/log), întărirea parametrilor de kernel (dezactivarea redirecționării IP cu excepția locurilor unde este necesară de CNI, activarea syncookies, dezactivarea rutării sursă IP), controlul accesului obligatoriu (modul de aplicare SELinux sau profiluri AppArmor) și eliminarea pachetelor și serviciilor inutile.

La nivelul Kubernetes, DISA STIG pentru Kubernetes și CIS Kubernetes Benchmark Nivel 2 converg pe un set de bază de cerințe de configurare kubelet. Portul de citire al kubelet trebuie dezactivat (--read-only-port=0). Autentificarea anonimă trebuie dezactivată (--anonymous-auth=false). Modul de autorizare trebuie setat la Webhook, delegând toate deciziile de autorizare motorului RBAC al serverului API, mai degrabă decât să aibă încredere în deciziile locale ale nodului. Rotația certificatelor trebuie activată astfel încât certificatele client kubelet să fie reînnoite automat înainte de expirare. Runtime-ul de containere -- containerd sau CRI-O -- trebuie configurat cu un profil seccomp implicit (RuntimeDefault) aplicat tuturor pod-urilor, cu excepția cazului în care acestea necesită explicit un profil mai permisiv sau personalizat.

Rularea kube-bench, auditorul open-source al benchmark-ului CIS, împotriva unui cluster configurat produce un raport de conformitate structurat în format XCCDF. Acest raport este un atașament obligatoriu în majoritatea pachetelor de acreditare. Constatările de Categoria I (severitate ridicată) trebuie remediate înainte de depunere; constatările de Categoria II trebuie remediate sau documentate cu controale compensatorii. Manualele de remediere automată -- Ansible sau similare -- care aplică controalele benchmark în mod reproductibil pe toate nodurile sunt preferate cu tărie față de configurarea manuală, atât pentru că reduc driftul de configurație, cât și pentru că produc înregistrări auditabile ale modificărilor.

Aplicarea politicilor de rețea: microsegmentarea între sarcinile de lucru clasificate

În mod implicit, toate pod-urile dintr-un cluster Kubernetes pot comunica cu toate celelalte pod-uri, indiferent de spațiul de nume. Acest model de rețea plată este adecvat pentru mediile de dezvoltare, dar inacceptabil pentru sarcinile de lucru clasificate, unde principiul accesului cu privilegii minime trebuie să se aplice traficului de rețea la fel cum se aplică permisiunilor RBAC. Aplicarea segmentării rețelei necesită două lucruri: un plugin CNI care implementează specificația Kubernetes NetworkPolicy și un set de obiecte NetworkPolicy care definesc căile de comunicare permise.

Tiparul de bază de întărire este o politică deny-all implicită aplicată fiecărui spațiu de nume la bootstrap-ul clusterului. Această politică refuză tot traficul de intrare și ieșire, cu excepția cazului în care o regulă explicită de permisiune îl permite. Regulile explicite de permisiune sunt apoi adăugate pentru fiecare cale de trafic necesară: rezoluție DNS (TCP și UDP port 53 către CoreDNS în kube-system), traficul de verificare a stării de sănătate de la kubelet la containerele aplicației și comunicarea specifică aplicației între servicii. Fiecare regulă de permisiune trebuie să fie cât mai restrânsă posibil -- prin selector de etichete pod, selector de etichete spațiu de nume și port -- mai degrabă decât să folosească intervale CIDR largi care vor trece revizuirea unui auditor, dar vor eșua în a constrânge efectiv mișcarea laterală.

Pentru sarcinile de lucru care operează la niveluri diferite de clasificare care trebuie să coexiste pe infrastructură partajată, NetworkPolicy bazată pe etichete singură este insuficientă. Plugin-ul CNI aplică politicile în stratul netfilter al kernel-ului Linux, iar un container compromis cu suficiente privilegii poate ocoli netfilter. Programele de apărare care găzduiesc sarcini de lucru la mai multe niveluri de sensibilitate pe un singur cluster trebuie să plaseze fiecare nivel de sensibilitate într-un grup de noduri dedicat cu interfețe de rețea sau VLAN-uri dedicate și să aplice controale de trafic inter-nivel la nivelul hardware sau hypervisor. Arhitectura de interconectare cloud pentru apărare oferă separarea fizică și logică pe care controalele bazate exclusiv pe politici nu o pot garanta pe infrastructură de kernel partajată.

Gestionarea secretelor: integrarea Kubernetes cu depozite de chei susținute de HSM

Secretele Kubernetes sunt stocate în mod implicit în etcd ca valori codificate base64, fără criptare. Orice utilizator sau proces cu acces de citire la etcd -- sau cu suficiente permisiuni RBAC pentru a apela kubectl get secret -- poate recupera valoarea în text simplu. Pentru mediile clasificate, aceasta nu este o lacună de configurare; este o problemă arhitecturală fundamentală care trebuie rezolvată înainte ca orice date sensibile să fie stocate în cluster. Soluția este criptarea etcd în repaus folosind un furnizor KMS care deleagă gestionarea cheilor la un depozit de chei susținut de HSM.

Resursa EncryptionConfiguration a kube-apiserver specifică o listă de furnizori de criptare pentru fiecare tip de resursă. Pentru furnizorul kms, configurația indică un soclu Unix unde ascultă un proces plugin KMS. Plugin-ul traduce protocolul KMS gRPC al Kubernetes în apeluri către HSM sau serviciul de gestionare a cheilor -- de obicei prin PKCS#11 pentru un HSM conectat la rețea, sau prin API-ul de gestionare a cheilor al unui KMS cloud de grad de apărare. Când serverul API scrie un Secret în etcd, apelează plugin-ul KMS pentru a cripta cheia de criptare a datelor (DEK) sub cheia de criptare a cheilor (KEK) deținută de HSM. Doar DEK-ul împachetat este stocat în etcd alături de textul cifrat. Decriptarea necesită un drum dus-întors la HSM. HSM trebuie validat FIPS 140-2 Nivel 3 pentru sarcinile de lucru de nivel SECRET; Nivelul 2 este acceptabil în general numai pentru materialul SENSIBIL DAR NECLASIFICAT.

Jurnalizarea auditului: capturarea evenimentelor serverului API pentru conformitate și criminalistică

Serverul API Kubernetes generează un jurnal de audit al fiecărei cereri pe care o procesează: cine a făcut cererea, ce verb și resursă au fost implicate, ce spațiu de nume, dacă cererea a reușit și -- în funcție de nivelul de audit configurat -- corpul complet al cererii și răspunsului. Acest jurnal este înregistrarea autoritativă pentru a răspunde la întrebarea „cine a făcut ce în acest cluster și când." Pentru mediile clasificate, jurnalizarea completă a auditului nu este opțională; este o cerință specifică de control în RMF, JSIG și cadre echivalente, iar absența unor jurnale de audit adecvate este de obicei o constatare care blochează o revizuire de acreditare.

Politica de audit este un fișier YAML transmis kube-apiserver la pornire, care mapează tipurile de resurse și verbele la niveluri de audit. Cele patru niveluri sunt: None (fără jurnalizare), Metadata (utilizator, verb, resursă, stare -- fără corp), Request (adaugă corpul cererii) și RequestResponse (adaugă atât corpurile cererii, cât și ale răspunsului). O politică de grad de conformitate capturează RequestResponse pentru Secrets, ConfigMaps, Roles, RoleBindings, ClusterRoles, ClusterRoleBindings și ServiceAccounts -- resursele a căror modificare ar putea indica escaladarea privilegiilor sau furtul de credențiale. Apelurile exec și attach la pod-uri trebuie, de asemenea, capturate la nivelul RequestResponse, deoarece acestea sunt vectorii principali pentru mișcarea laterală interactivă într-un cluster compromis. Toate celelalte resurse pot fi jurnalizate la nivelul Metadata, care produce o înregistrare completă a accesului fără costul de stocare al capturării fiecărui payload al aplicației.

Jurnalele de audit stocate doar pe nodul planului de control sunt vulnerabile la alterare de către un administrator de cluster compromis. O arhitectură de audit de grad de apărare transmite jurnalele la o destinație externă la care clusterul însuși nu poate scrie sau șterge: un SIEM (sistem de gestionare a informațiilor și evenimentelor de securitate), un depozit de obiecte compatibil S3 cu retenție object-lock, sau un forwarder syslog dedicat către o infrastructură de agregare a jurnalelor în regim air-gapped. Expeditorul de jurnale -- un DaemonSet Fluentd sau Fluent Bit pe nodurile planului de control -- trebuie să ruleze cu un cont de serviciu Kubernetes care nu are permisiuni asupra obiectelor clusterului care sunt jurnalizate, astfel încât un expeditor compromis să nu-și poată acoperi urmele modificând politica de audit sau ștergând fișierele de jurnal.

Scanarea imaginilor și securitatea lanțului de aprovizionare în registrele de containere clasificate

Fiecare imagine de container implementată într-un cluster clasificat este o potențială suprafață de atac a lanțului de aprovizionare. O imagine extrasă dintr-un registru public fără inspecție poate conține versiuni de biblioteci cu vulnerabilități cunoscute, credențiale integrate sau cod malițios introdus în timpul pipeline-ului de build. Programele de apărare trebuie să opereze un registru privat de containere care este izolat de internetul public, necesită acces autentificat și aplică scanarea vulnerabilităților și semnarea imaginilor înainte ca orice imagine să fie admisă în cluster.

Instrumentele de scanare a vulnerabilităților imaginilor, cum ar fi Trivy sau Grype, analizează fiecare strat al imaginii față de baza de date de consultanță OSV și buletinele de securitate ale furnizorilor, producând o listă de CVE-uri cu scoruri de severitate și versiunile de pachete afectate. Într-un pipeline CI clasificat, scanarea rulează ca parte a procesului de build al imaginii; imaginile care conțin CVE-uri de severitate Critică sau Ridicată sunt blocate de la împingerea în registrul de producție până când vulnerabilitățile sunt remediate sau formal acceptate ca riscuri. Rezultatele scanării sunt stocate alături de imagine în metadatele registrului și referențiate în pachetul de dovezi de acreditare ca dovadă că inventarul de software este cunoscut și revizuit.

Semnarea imaginilor adaugă o afirmație criptografică că un anumit digest de imagine a fost produs de un anumit pipeline de build și nu a fost modificat de la semnare. Instrumentul cosign al proiectului Sigstore suportă semnarea cu o cheie stocată într-un HSM sau KMS, producând o atestare de semnătură care este stocată în registru alături de imagine. Webhook-ul de admisie Kubernetes -- folosind un motor de politici precum Kyverno sau OPA Gatekeeper -- verifică semnătura înainte ca orice pod să fie programat. Acest lanț de custodie de la build la implementare este exact ceea ce cer cadrele de securitate a lanțului de aprovizionare: fiecare sarcină de lucru care rulează în cluster poate fi urmărită la un artifact de build semnat specific, iar imaginile nesemnate sau alterate sunt respinse la nivelul de admisie, mai degrabă decât descoperite în timpul unei revizuiri criminalistice post-incident.

Calea de acreditare: obținerea unui ATO sau echivalent pentru un cluster Kubernetes

O Autoritate de Operare pentru un cluster Kubernetes nu este un singur document, ci un pachet de dovezi asamblat pentru a demonstra că sistemul îndeplinește controalele de securitate specificate în cadrul aplicabil -- Risk Management Framework (RMF) pentru programele federale americane, JSIG pentru sistemele de informații comune, sau echivalente specifice programului pentru achizițiile de apărare ale națiunilor aliate. Responsabilul cu autorizarea revizuiește acest pachet și ia o decizie de acceptare a riscului. Înțelegerea a ceea ce trebuie să conțină pachetul este esențială pentru planificarea calendarului de acreditare, deoarece lacunele descoperite târziu în procesul de revizuire pot întârzia punerea în funcțiune cu luni de zile.

Planul de Securitate a Sistemului este documentul central. Pentru un cluster Kubernetes, SSP trebuie să descrie arhitectura clusterului (numărul și plasarea nodurilor planului de control, topologia etcd, grupurile de noduri de lucru, topologia rețelei), configurația de întărire a nodurilor cu referințe la raportul de conformitate kube-bench, configurația de criptare pentru etcd, modelul RBAC (care conturi de serviciu au ce permisiuni și de ce), arhitectura politicii de rețea, proveniența imaginilor și lanțul de semnare, și arhitectura de transmitere a jurnalelor de audit. Fiecare control din linia de bază aplicabilă este fie satisfăcut (cu o referință la dovadă), fie neaplicabil (cu o justificare), fie deschis (cu un control compensatoriu sau o intrare POA&M).

Monitorizarea continuă este o condiție a majorității ATO-urilor, mai degrabă decât o poartă unică. Clusterul trebuie înregistrat într-un sistem de gestionare a configurației care detectează driftul față de linia de bază întărită, un proces de gestionare a vulnerabilităților care urmărește CVE-urile din imaginile implementate și pachetele OS ale nodurilor față de SLA-urile de remediere, și un proces de revizuire a jurnalelor care monitorizează evenimentele de audit pentru anomalii. Instrumentele automate -- kube-bench programat ca un Kubernetes CronJob, re-scanarea imaginilor pe un program nocturn, reguli de alertare SIEM pentru tipare suspecte ale serverului API -- produc dovezile de monitorizare continuă fără a necesita efort manual pentru fiecare ciclu de revizuire. Programele care construiesc această automatizare înainte de depunerea inițială ATO sunt într-o poziție mult mai puternică pentru reautorizare decât cele care tratează monitorizarea continuă ca un aspect post-autorizare de rezolvat ulterior.