Kubernetes стана най-популярната система за облачни контейнери. Така че всъщност беше само въпрос на време да бъде открит първият му основен недостатък в сигурността.
И така беше, защото наскоро Първият основен недостатък в сигурността в Kubernetes беше пуснат под CVE-2018-1002105, известен също като неуспех при ескалация на привилегиите.
Този основен недостатък в Kubernetes е проблем, тъй като е критичен пропуск в сигурността на CVSS 9.8. В случай на първия голям недостатък в сигурността на Kubernetes.
Подробности за грешката
Със специално проектирана мрежа за заявки всеки потребител може да установи връзка чрез от сървъра за интерфейс за програмиране на приложения (API) Kubernetes към бекенд сървър.
Веднъж установени, атакуващият може да изпраща произволни заявки по мрежовата връзка директно до този бекенд в който по всяко време целта е този сървър.
Тези заявки се удостоверяват с идентификационните данни на TLS (Transport Layer Security) от Kubernetes API сървъра.
Още по-лошо, в конфигурацията по подразбиране всички потребители (удостоверени или не) могат да изпълняват извиквания за откриване на API, които позволяват тази ескалация на привилегиите от нападателя.
И така, всеки, който знае тази дупка, може да се възползва от възможността да поеме командването на техния клъстер Kubernetes.
В момента няма лесен начин да се установи дали тази уязвимост е била използвана по-рано.
Тъй като се правят неоторизирани заявки по установена връзка, те не се появяват в дневниците за одит на сървъра на Kubernetes API или в дневника на сървъра.
Заявките се появяват в регистрите на kubelet или в обобщения API сървър, но те се различават от правилно оторизирани и прокси заявки чрез Kubernetes API сървъра.
Злоупотреба тази нова уязвимост в Kubernetes няма да остави очевидни следи в регистрационните файлове, така че сега, когато бъгът Kubernetes е изложен, е просто въпрос на време да бъде използван.
С други думи, Red Hat каза:
Недостатъкът на ескалацията на привилегиите позволява на всеки неоторизиран потребител да получи пълни привилегии на администратор на всеки изчислителен възел, работещ в подсистема на Kubernetes.
Това не е просто кражба или отваряне за инжектиране на злонамерен код, но също така може да намали приложенията и производствените услуги в защитната стена на организацията.
Всяка програма, включително Kubernetes, е уязвима. Дистрибуторите на Kubernetes вече пускат поправки.
Red Hat съобщава, че всички негови продукти и услуги, базирани на Kubernetes, включително Red Hat OpenShift Container Platform, Red Hat OpenShift Online и Red Hat OpenShift Dedicated са засегнати.
Red Hat започна да предоставя корекции и актуализации на услуги за засегнатите потребители.
Доколкото е известно, никой все още не е използвал нарушението на сигурността, за да атакува. Дарън Шепърд, главен архитект и съосновател на лабораторията Rancher, откри грешката и я докладва, използвайки процеса на докладване на уязвимостта на Kubernetes.
Как да коригирам тази грешка?
За щастие, корекцията за тази грешка вече е пусната. В която само те са помолени да извършат актуализация на Kubernetes за да могат да изберат някои от версиите Kubernetes v1.10.11, v1.11.5, v1.12.3 и v1.13.0-RC.1.
Така че, ако все още използвате някоя от версиите Kubernetes v1.0.x-1.9.x, препоръчително е да надстроите до фиксирана версия.
Ако по някаква причина не могат да актуализират Kubernetes и те искат да спрат този неуспех, е необходимо те да извършат следния процес.
Трябва да спрете да използвате API на агрегатите на сървъра или да премахнете разрешенията за exec / attach / portforward за потребители, които не трябва да имат пълен достъп до API на kubelet.
Джордан Лигит, софтуерният инженер на Google, който е отстранил грешката, каза, че тези мерки вероятно ще бъдат в ущърб.
Така че единственото реално решение срещу този недостатък в сигурността е да се извърши съответната актуализация на Kubernetes.