Container Hardening – Deo 6: Bezbednost etcd skladišta

Prethodni delovi serije o Kubernetes-u bavili su se time ko sme šta preko API-ja (RBAC), i šta pod-ovi smeju na nivou operativnog sistema i mreže (Pod Security Standards, NetworkPolicy). Ovaj deo ide na mesto koje sve to zapravo čuva — etcd, raspoređenu bazu ključ-vrednost u kojoj Kubernetes drži apsolutno sve što opisuje stanje klastera: definicije pod-ova, konfiguracije, RBAC pravila iz ranijeg dela serije, i, što je posebno bitno, sve Secrets objekte. Ko god ima nekontrolisan pristup etcd-u, u praksi ima pristup ekvivalentan punoj kompromitaciji celog klastera — bez obzira na to koliko su pažljivo postavljeni RBAC i mrežne politike iznad njega.

Zašto etcd zaslužuje poseban tretman u odnosu na ostatak klastera

Sve prethodne mere iz ove serije — RBAC, Pod Security Standards, NetworkPolicy — deluju na nivou Kubernetes API-ja. One kontrolišu kako se do podataka dolazi kroz taj API. Etcd je, međutim, sistem ispod tog API-ja — mesto gde su podaci stvarno, fizički zapisani na disku. Neko ko zaobiđe API sloj i pristupi etcd-u direktno (npr. sa pristupom fajl sistemu control plane čvora, ili mrežnim pristupom samom etcd portu) potpuno zaobilazi RBAC proveru u celini, jer RBAC kontroliše API server, ne sam etcd. Ovo je isti princip koji smo videli kod Docker socket-a u ranijem delu serije — sloj ispod aplikativnog API-ja, ako nije zaštićen, čini sve iznad njega irelevantnim.

Kritičan, često pogrešno shvaćen detalj — base64 nije enkripcija

Ovo zaslužuje eksplicitno, tehnički precizno objašnjenje, jer je izvor jedne od najčešćih pogrešnih pretpostavki o Kubernetes bezbednosti. Kad se kreira Secret objekat (npr. lozinka za bazu podataka), Kubernetes tu vrednost po difoltu čuva u etcd-u kodiranu u base64 formatu — ne enkriptovanu. Base64 je metod kodiranja, ne kriptografske zaštite: to je isti mehanizam koji se koristi za bezopasno prenošenje binarnih podataka kroz tekstualne formate, i njegovo "dekodiranje" nazad u čitljiv oblik ne zahteva nikakav ključ, lozinku niti poseban alat — samo standardnu, javno poznatu operaciju dekodiranja koju svaki programski jezik i većina komandnih alata podržava u jednoj liniji.

Praktična posledica: bilo ko sa direktnim pristupom etcd podacima — bilo kroz fajl sistem na disku, kroz backup fajl etcd baze, ili kroz mrežni pristup samom etcd API-ju — može pročitati svaki Secret u klasteru u čitljivom, izvornom obliku, u svega par sekundi, bez potrebe da ikad probije bilo kakvu stvarnu kriptografsku zaštitu. Ovo nije teoretski, rub-slučaj rizik; ovo je podrazumevano ponašanje svakog Kubernetes klastera dok se eksplicitno ne uključi enkripcija u mirovanju.

Šta treba uraditi

• Uključiti enkripciju u mirovanju (encryption at rest) za etcd kroz Kubernetes-ov EncryptionConfiguration mehanizam — ovo govori API serveru da pre upisa u etcd stvarno kriptografski enkriptuje sadržaj Secret objekata (i, od novijih verzija Kubernetes-a, opciono i prilagođenih resursa definisanih kroz CustomResourceDefinition), ne samo da ih base64 kodira
• Nakon uključivanja enkripcije, imati na umu da se ona ne primenjuje retroaktivno na već postojeće Secrets automatski — potrebno je izvršiti ponovni zapis (npr. kroz odgovarajuću `kubectl` operaciju nad svim postojećim Secret objektima) da bi i oni koji su kreirani pre uključivanja enkripcije zaista postali enkriptovani na disku
• Upravljati ključem za enkripciju sa istom ozbiljnošću kao i TDE sertifikatom opisanim u MSSQL hardening seriji — čuvati ga odvojeno od samih etcd podataka, imati proveren postupak rotacije ključa, i nikad ne pretpostaviti da je "uključena enkripcija" trajno rešen problem bez daljeg održavanja
• Za posebno osetljive slučajeve, razmotriti integraciju sa spoljnim sistemom za upravljanje ključevima (KMS provider), gde sam ključ za enkripciju uopšte ne mora biti trajno uskladišten unutar samog klastera

Napomena o riziku: uključivanje enkripcije u mirovanju je operacija koja zahteva restart API servera i pažljivo praćenje da proces prođe bez greške na svakom control plane čvoru — greška u konfiguraciji (npr. neispravna putanja do ključa) može sprečiti API server da se uopšte pokrene. Testirati ovu promenu prvo u odvojenom, ne-produkcionom klasteru, i imati proveren backup etcd podataka pre primene na produkciji, po istom principu opreza koji se provlači kroz svaku ozbiljniju izmenu opisanu u ovoj seriji.

Enkripcija u prenosu — ko sme da razgovara sa etcd-om

Nezavisno od toga šta je enkriptovano na disku, komunikacija između etcd-a i onoga što sa njim razgovara — API servera, i drugih etcd instanci u istom klasteru (peer-to-peer saobraćaj, kad etcd radi u više-čvornoj, otpornoj na otkaz konfiguraciji) — mora takođe biti zaštićena, inače nezaštićen mrežni saobraćaj otkriva sadržaj čak i ako je sam disk enkriptovan.

Standardan mehanizam je uzajamna TLS autentifikacija (mutual TLS) — i klijent (API server) i sam etcd server prezentuju sertifikate jedan drugom, i komunikacija se odvija isključivo ako oba sertifikata potiču od poverljivog izdavaoca sertifikata (CA). Vredi napomenuti tehničko ograničenje ovog pristupa, na koje CIS Benchmark eksplicitno upozorava: standardna etcd autentifikacija proverava samo da je sertifikat izdat od poverljivog CA, ne i konkretne atribute tog sertifikata (npr. common name ili subject alternative name) protiv liste dozvoljenih klijenata. Praktična posledica: ako napadač uspe da pribavi bilo koji sertifikat izdat od tog istog, poverljivog CA — čak i sertifikat koji je originalno bio namenjen za sasvim drugu svrhu — taj sertifikat će etcd prihvatiti kao validan za pristup.

Šta treba uraditi

• Uključiti TLS za sve tipove etcd komunikacije — klijent-server (API server prema etcd-u) i peer-to-peer (etcd instance međusobno, u više-čvornim konfiguracijama), sa client-cert-auth uključenim da se zahteva sertifikat sa obe strane, ne samo jednosmerna provera
• Imati u vidu ranije opisano ograničenje CA-baziranog poverenja i primenjivati strogu kontrolu nad tim ko uopšte sme da izdaje sertifikate iz tog istog CA lanca — kompromitacija same sertifikacione infrastrukture podriva celu TLS zaštitu etcd-a, bez obzira na to koliko je sama TLS konfiguracija ispravno postavljena
• Redovno pratiti datume isteka etcd sertifikata i imati automatizovan ili bar dobro dokumentovan proces obnavljanja — istekao sertifikat na etcd-u može prekinuti rad celog control plane-a, ne samo jedne aplikacije

Mrežna izolacija — etcd nikad ne treba da bude dostupan van control plane-a

Etcd standardno sluša na portovima 2379 (klijentski API) i 2380 (peer komunikacija). Ovo nije servis dizajniran za direktnu, opštu mrežnu dostupnost — namenjen je isključivo komunikaciji unutar control plane infrastrukture, i njegova izloženost van tog uskog opsega predstavlja nepotreban, ozbiljan rizik nezavisno od toga koliko je dobro autentifikacija inače podešena.

Šta treba uraditi

• Ograničiti mrežni pristup etcd portovima isključivo na control plane čvorove koji ga zaista koriste (API server i, u više-čvornoj konfiguraciji, ostale etcd instance) — kroz firewall pravila na nivou hosta, po istom principu segmentacije opisanom u ranijoj Linux Server hardening seriji
• Nikad ne izlagati etcd portove ka javnom internetu niti ka opštoj korisničkoj mreži klastera — jedini legitimni saobraćaj ka etcd-u dolazi od komponenti control plane-a
• Gde je moguće, fizički ili mrežno odvojiti control plane infrastrukturu (uključujući etcd) od radnih čvorova (worker nodes) na kojima rade obične aplikacije, po istom principu segmentacije upravljačke mreže korišćenom kroz celu ovu seriju

Backup etcd-a — isti podaci, ista pažnja

Redovan backup etcd stanja je neophodan za oporavak klastera u slučaju otkaza, ali backup fajl sadrži potpuno iste podatke kao živi etcd — uključujući, ako enkripcija u mirovanju nije bila uključena u trenutku pravljenja backup-a, čitljive Secret vrednosti. Isti princip opisan za MSSQL i Hyper-V backup u ranijim serijama važi identično ovde.

Šta treba uraditi

• Praviti redovne, automatizovane snapshot-ove etcd stanja (kroz etcdctl snapshot mehanizam) kao deo standardne disaster recovery procedure za klaster
• Čuvati backup fajlove odvojeno od same etcd infrastrukture i enkriptovane na nivou skladišta, po istom "izvan dometa istog kompromitovanog pristupa" principu opisanom za MSSQL backup fajlove
• Ako je enkripcija u mirovanju uključena tek naknadno, imati na umu da stariji backup-ovi napravljeni pre te promene mogu i dalje sadržati čitljive Secret vrednosti — ili ih bezbedno ukloniti nakon što novi, enkriptovani backup-ovi postanu pouzdani, ili ih tretirati sa istim nivoom osetljivosti kao i neenkriptovan podatak
• Periodično testirati stvarnu restauraciju iz backup-a, ne samo proveru da backup fajl postoji — isti princip verifikacije ponovljen kroz svaku seriju o backup-u na ovom blogu

Ovim se zaokružuje pregled bezbednosti Kubernetes control plane-a kroz prizmu etcd-a — poslednja, možda i najkritičnija karika, jer njena kompromitacija poništava vrednost svega ostalog pokrivenog u ovoj seriji. Sledeći delovi mogu ići dalje na admission kontrolere poput Kyverno ili OPA Gatekeeper za pravila van onoga što ugrađeni Kubernetes mehanizmi pokrivaju, ili na runtime detekciju (npr. Falco) za otkrivanje sumnjivog ponašanja unutar već pokrenutih kontejnera, u zavisnosti od toga šta se pokaže najkorisnijim za dalje čitanje.