Дадена нода в Kubernetes се превръща в точка на пробив в самоличността, когато атакуващ придобие root достъп. Изследванията показват, че зловреден процес може да се представи за други работни натоварвания (workloads) и да получи техните идентификационни данни, превръщайки една първоначална точка на проникване в по-широк достъп в рамките на споделената нода.
Проблемът засяга внедрявания на SPIFFE и SPIRE, които заменят дълготрайните тайни с кратковременни самоличности на работните натоварвания. Тези идентификационни данни позволяват на услугите да доказват самоличността си една на друга.
Моделът предполага, че нодата е надеждна – предположение, което отпада, когато атакуващ поеме контрол над нейната операционна система. Анализатори от Unit42 установиха как атакуващ с root привилегии може да променя данни в Linux cgroup, използвани по време на проверките на работните натоварвания.
От Palo Alto Networks заявиха в доклад, споделен с Cyber Security News (CSN), че техниката може да накара локален SPIRE агент да издаде самоличността на съвместно разположено работно натоварване на процес, контролиран от атакуващия. Изследователите отбелязват, че не са наблюдавали метода да се използва при реални атаки.
Валидната самоличност на работно натоварване може да разкрие доверени маршрути, които обикновените откраднати идентификационни данни не могат. Атакуващ би могъл да се автентифицира пред вътрешни услуги, да изиска защитени данни или да се придвижва между приложения като легитимна услуга.
Случаите, при които хакери експлоатират грешни конфигурации в Kubernetes, показват защо сигурността на нодите и контролът на самоличността не могат да се разглеждат като отделни проблеми.
Една компрометирана Kubernetes нода
SPIFFE присвоява на всяко работно натоварване име, кратковременен проверим документ за самоличност на SPIFFE (SVID) и доверен пакет (trust bundle), който го валидира.
Приложенията изискват SVID от локалния SPIRE агент. Агентът проверява атрибутите на процеса, преди да върне идентификационни данни за двупосочни TLS връзки (mTLS) или достъп, базиран на токени.
В Kubernetes агентът може да инспектира cgroup пътя на даден процес, за да го свърже с контейнер и под (pod), след което да събере подробности за пространството от имена (namespace) и сервизния акаунт (service account).
Той ги сравнява с правилата за регистрация. Когато стойностите съвпаднат, агентът връща SVID на работното натоварване и необходимите материали за използването му.
Unit42 демонстрира, че root достъпът може да промени този резултат. Атакуващ може да създаде или манипулира cgroup път, наподобяващ този на целта, и да добави своя процес към него. Агентът може да съпостави селекторите на целта и да предостави нейните идентификационни данни на зловредния процес.
Това е техника, използвана след компрометиране (post-exploitation), а не отдалечена уязвимост, която самостоятелно да компрометира целия клъстер. Нейният радиус на щети обаче може да бъде сериозен: всяка самоличност на работно натоварване в засегнатата нода трябва да се счита за компрометирана.
Това прави докладите за уязвимост в Kubernetes NodeRestriction, свързана с компрометирани ноди, изключително важни извън първоначалната точка на проникване.
Защита на границата на нодата
Изследователите създадоха Spooffe – инструмент за тестване, който сканира нода, пресъздава cgroup пътищата за работещите работни натоварвания и изисква от локалния агент получените самоличности.
Той помага на екипите по защита да оценят експозицията след компрометиране на ниво администратор. Също така илюстрира защо кратковременните идентификационни данни сами по себе си не решават пропуските в сигурността на ниво хост.
Организациите трябва да моделират root достъпа до дадена нода като достъп до всяка криптографска самоличност, определена за нея. Това означава да защитават работните ноди (worker nodes) със същата спешност, както и системите за самоличност, да ограничават стриктно администраторските привилегии и да наблюдават за неочаквани промени в процесите, контейнерите и cgroups.
Препоръките потвърждават поуките от злоупотребите на атакуващи с грешни конфигурации в Docker и Kubernetes, при които привилегированите контейнери могат да осигурят директен път към контрола над хоста.
Екипите трябва да блокират привилегированите контейнери, когато е възможно, да ограничат директното монтиране към хоста и хост мрежите, както и да контролират стриктно достъпа до интерфейсите за управление на контейнери (container runtime interfaces).
Политиките за регистрация не трябва да зависят единствено от селектори, които атакуващ с root привилегии може да имитира. Специфичният дизайн на политиките, редовният преглед и многослойният контрол могат да предотвратят превръщането на едно компрометирано работно натоварване в инцидент, засягащ цялата система за самоличност.
Екипите за защита трябва да идентифицират чувствителни работни натоварвания, които споделят едни и същи ноди, особено услуги с широки разрешения за достъп до бази данни, облачни ресурси или внедряване.
Разделянето на високорисковите работни натоварвания и прилагането на принципа на минималните привилегии могат да намалят щетите при пробив в дадена нода. Насърчаването на сигурността в производствените клъстери на Kubernetes по подобен начин набляга на строгия контрол на достъпа, сегментацията и непрекъснатото наблюдение.
Основният извод е прост: самоличността на работното натоварване е толкова силна, колкото е сигурна машината, която я потвърждава. SPIFFE и SPIRE намаляват риска от компрометиране на постоянни тайни, но не могат да запазят изолацията, след като контролът над root привилегиите на хоста бъде загубен.
Плановете за реагиране при инциденти трябва да включват ротация на идентификационните данни, преглед на сесиите и разследване на услугите, които са приели самоличности, издадени от засегнатата нода.