Kubernetes u bë larg sistemi më i popullarizuar i kontejnerëve në re. Pra, në të vërtetë ishte vetëm çështje kohe derisa u zbulua e meta e tij e parë e madhe e sigurisë.
Dhe kështu ishte, sepse kohët e fundit E meta e parë e madhe e sigurisë në Kubernetes u lëshua nën CVE-2018-1002105, i njohur gjithashtu si dështimi i përshkallëzimit të privilegjit.
Kjo e metë kryesore në Kubernetes është një problem pasi është një vrimë kritike e sigurisë CVSS 9.8. Në rast të metës së parë të madhe të sigurisë në Kubernetes.
Detajet e gabimit
Me një rrjet kërkesash të krijuar posaçërisht, çdo përdorues mund të krijojë një lidhje përmes nga serveri i ndërfaqes së programimit të aplikacionit (API) Kubernetes në një server backend.
Pasi të themelohet, një sulmues mund të dërgojë kërkesa arbitrare mbi lidhjen e rrjetit drejtpërdrejt në atë backend në të cilën në çdo kohë objektivi është ai server.
Këto kërkesa vërtetohen me letrat kredenciale (Transport Layer Security) nga serveri Kubernetes API.
Më keq akoma, në konfigurimin e paracaktuar, të gjithë përdoruesit (të vërtetuar ose jo) mund të ekzekutojnë thirrje zbulimi të API që lejojnë këtë përshkallëzim të privilegjit nga sulmuesi.
Me të cilën atëherë, kushdo që e njeh atë vrimë mund të shfrytëzojë rastin për të marrë komandën e tufës së tyre Kubernetes.
Për momentin nuk ka asnjë mënyrë të thjeshtë për të zbuluar nëse kjo dobësi është përdorur më parë.
Ndërsa kërkesat e paautorizuara bëhen përmes një lidhjeje të vendosur, ato nuk shfaqen në regjistrat e auditimit të serverit Kubernetes API ose regjistrin e serverit.
Kërkesat paraqiten në regjistrat e serverit API ose kubelet, por ato dallohen nga kërkesat e autorizuara si duhet dhe nga përfaqësuesit përmes serverit Kubernetes API.
Abuzimi kjo dobësi e re në Kubernetes nuk do të linte gjurmë të dukshme në regjistrat, kështu që tani që është zbuluar bug i Kubernetes, është thjesht çështje kohe derisa të përdoret.
Me fjalë të tjera, Red Hat tha:
E meta e përshkallëzimit të privilegjeve lejon çdo përdorues të paautorizuar të fitojë privilegje të plota administratori në çdo nyje llogaritëse që ekzekutohet në një pod të Kubernetes.
Kjo nuk është vetëm një vjedhje ose një hapje për të injektuar kodin e dëmshëm, ajo gjithashtu mund të zvogëlojë shërbimet e aplikimit dhe të prodhimit brenda firewall-it të një organizate.
Çdo program, përfshirë Kubernetes, është i prekshëm. Shpërndarësit e Kubernetes tashmë po lëshojnë rregullime.
Red Hat raporton se të gjitha produktet dhe shërbimet e saj me bazë Kubernetes përfshirë Platformën e Enëve RedS OpenShift, Red Hat OpenShift Online dhe Red Hat OpenShift Dedikuar preken.
Red Hat filloi të siguronte rregullime dhe azhurnime të shërbimeve për përdoruesit e prekur.
Me sa dihet, askush nuk e ka përdorur shkeljen e sigurisë për të sulmuar akoma. Darren Shepard, arkitekti kryesor dhe bashkëthemeluesi i laboratorit Rancher, zbuloi defektin dhe e raportoi atë duke përdorur procesin e raportimit të cenueshmërisë së Kubernetes.
Si ta korrigjoni këtë defekt?
Për fat të mirë, një rregullim për këtë defekt tashmë është lëshuar.. Në të cilën vetëm atyre u kërkohet të kryejnë një azhurnim të Kubernetes kështu që ata mund të zgjedhin disa nga versionet e arnuara të Kubernetes v1.10.11, v1.11.5, v1.12.3 dhe v1.13.0-RC.1.
Pra, nëse jeni duke përdorur ndonjë nga versionet Kubernetes v1.0.x-1.9.x, rekomandohet që të azhurnoni në një version fiks.
Nëse për ndonjë arsye ata nuk mund të azhurnojnë Kubernetes dhe ata duan të ndalojnë këtë dështim, është e nevojshme të kryhet procesi i mëposhtëm.
Ju duhet të ndaloni përdorimin e API-së së agregatëve të serverit ose të hiqni lejet e ekzekutimit / bashkangjitjes / portit përpara për përdoruesit që nuk duhet të kenë qasje të plotë në kubelet API.
Jordan Liggitt, inxhinier i softuerit Google i cili rregulloi defekt, tha se këto masa ka të ngjarë të jenë të dëmshme.
Kështu që zgjidhja e vetme e vërtetë kundër këtij të mete sigurie është kryerja e azhurnimit përkatës të Kubernetes.