Безпека Kubernetes

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Вступ

Привіт, DOU! Мене звати Владислав, я працюю пентестером і займаюсь безпекою хмарних і контейнеризованих середовищ, он-прем інфраструктури, а також веб-додатків. Досить часто я проводжу аудити безпеки Kubernetes кластерів, тож вирішив поділитись своїм досвідом у цій сфері. Стаття буде корисною в першу чергу для пентестерів, DevOps інженерів, Middle та Senior розробників, а також для архітекторів.

Що розглядаємо

Екосистема Kubernetes дозволяє створювати декларативні деплойменти додатків, динамічно конфігурувати середовища, створювати бекапи та синхронізувати дані, визначати правила контролю доступу до ресурсів і секретів, їх ізоляцію, конфігурувати стандарти безпеки на рівні всього кластера, додавати різні механізми аутентифікації, інтегрувати додатки з хмарними середовищами, централізовано логувати події... І все це має бути реалізовано згідно з найкращими практиками кібербезпеки.

Дійсно, кількість рухомих частин і налаштувань вражає — на перший погляд, не ясно навіть як почати перевіряти свій кластер на слідування тим самим «найкращим практикам». Тож я пропоную вам методологію аудиту безпеки Kubernetes кластерів, яка не один раз рятувала мене під час пентестів.

Структура Kubernetes кластера

Для початку, згадаймо з чого власне складається сам кластер, а потім побудуємо модель загроз і практичний підхід до тестування. З документації Kubernetes, кожен кластер на високому рівні описується наступною діаграмою:

Кластер умовно поділяється на компоненти «Control Plane» та «Data Plane». Всередині Control Plane крутяться компоненти кластера, які відповідають за життєвий цикл самого кластера. До них належать:

• kube-apiserver — це фронтенд всіх Control Plane API, тобто всі запити до системних компонентів кластера проходять через kube-apiserver.
• etcd — key-value сховище, всередині якого зберігається вся системна інформація про кластер
• kube-scheduler — це компонент, який відповідальний за вибір найкращої ноди (сервера) щоб запускати на ній контейнери
• kube-controller-manager — менеджер контролерів. Контролерами називають допоміжні компоненти кластера, які відповідальні за якийсь один аспект. Наприклад, ServiceAccount контролер відповідальний за те, щоб у кожному неймспейсі обов’язково існував default сервіс-акаунт.
• cloud-controller-manager (Опціональний) — Існує для інкапсуляції логіки взаємодії з хмарним середовищем. Наприклад, Service контролер відповідальний за створення і видалення лоад-балансерів всередині хмарного середовища.

Тепер розглянемо, з чого складається Data Plane. У цій умовній частині кластера запущені самі контейнеризовані додатки. Data Plane кожного кластеру має наступні компоненти:

• kubelet — агент, який запущений на кожній ноді. Він слідкує за тим, щоб усі контейнери, створені через Kubernetes, були запущені і працювали без перерв
• kube-proxy (Опціональний) — це мережевий проксі, який відповідальний за балансування трафіку між подами, і він також відповідальний за дотримання правил мережевої комунікації між ресурсами всередині кластера і зовнішніми ресурсами. Його може не бути, якщо кластер використовує мережеві аддони, що реалізують такий самий функціонал
• Container Runtime — фундаментальний компонент Kubernetes, який власне і запускає контейнери та менеджить їхній життєвий цикл. Kubernetes підтримує різні рантайми, які реалізують інтерфейс Kubernetes CRI (Container Runtime Interface), як-от containerd та CRI-O

Kubernetes також дозволяє встановлювати аддони, які розширяють його функціонал, наприклад:

• DNS — аддон дозволяє мати DNS сервер всередині кластера
• K8s Dashboard — встановлює веб компонент, який візуалізує стан кластера
• Network Plugins — додаткові компоненти, які реалізують Container Network Interface і є відповідальними за адресацію трафіку в кластері

Whitebox аудит Kubernetes

Тепер, коли ми знаємо, з чого складається кластер, можна говорити про методологію аудиту безпеки. Слідування цій методології дозволить знайти максимальну кількість вразливостей за мінімальний час, а саму методологію можна запам’ятати за 30 секунд.

Benchmarking

Перше що ми робимо на початку аудиту — бенчмарк перевірки, які дозволяють швидко оглянути кластер і на високому рівні оцінити, наскільки добре він захищений. Для цього можна використати такі інструменти як kube-bench та Popeye. Вивід цих сканерів покаже контейнери, запущені від юзера root, недоліки мережевих політик, відсутні обмеження на використання CPU і пам’яті контейнерами, поди з сервіс-акаунтами та інше. На цьому етапі також варто завантажити конфігурації всього кластера у yaml, наприклад так: kubectl get all -A -o yaml > cluster.yaml

Network Policies and Services рев’ю

За замовчуванням, усі поди в Kubernetes запускаються у плоскій мережі — тобто кожен под може встановлювати мережеві з’єднання з усіма іншими подами. Це є небезпечною конфігурацією, тож адміністратори створюють Network Policies, які регулюють вхідний і вихідний трафік для кожного пода. Необхідно перевірити, що кожен под дозволяє вхідний трафік виключно для подів, які від нього залежать, і може встановлювати з’єднання тільки з подами чи серверами, які є необхідними для його роботи. Щоб протестувати ефективність політик, можна знайти 2 контейнери, які точно не повинні комунікувати один з одним (наприклад, база даних та контейнер фронтенд додатку) і спробувати передати файл по TCP за допомогою netcat, curl, python чи будь-якого іншого інструмента. Крім того, варто проглянути Service ресурси, адже вони можуть надати не потрібний доступ до подів користувачам Інтернету або локальної мережі.

Перевірка аутентифікації на Kubernetes APIs

Kubernetes дозволяє налаштувати анонімний доступ до kube-apiserver, etcd та kubelet. Це серйозна вразливість, адже анонімний доступ до kubelet дозволить виконувати довільний код всередині кожного контейнера, а доступ до kube-apiserver або etcd — еквівалент доступу до всього кластера з правами адміністратора.

RBAC / ABAC тестування

Kubernetes дозволяє створювати юзерів, групи, та сервіс-акаунти. Всі вони можуть аутентифікуватись в kube-apiserver та виконувати певні дії в кластері, як-от створити под, прочитати секрет, видалити деплоймент тощо. Надмірний доступ до компонентів Kubernetes дозволить підвищити свої привілеї та отримати неавторизований доступ до чутливих даних, вносити зміни в деплойменти та середовища, а також зупинити роботу кластера. Нижче наведено список найбільш небезпечних дозволів:

• GET secrets + CREATE secrets -> дозволяє отримати токени інших сервіс-акаунтів
• CREATE / UPDATE Pod, Deployment, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs and Cronjobs -> Дозволяє отримати root-level доступ до нод, а також до Kubernetes секретів та сервіс-акаунтів
• EXEC into Pods -> доступ до секретів та токенів сервіс-акаунтів, які використовують поди
• IMPERSONATE / CREATE Token -> Дозволяє використовувати Kubernetes API від імені інших сервіс-акаунтів
• CREATE / UPDATE (Cluster)Role and (Cluster)RoleBinding + ESCALATE OVER (Cluster)Roles -> Дозволяє змінювати дозволи, які надані ролям

Під час кожного аудиту необхідно підтвердити, що ці дозволи надані виключно тим сервіс-акаунтам (юзерам, групам) які цього потребують для щоденних активностей за принципом найменших привілеїв. Для цього можна скористатись такими інструментами як kubectl-who-can, rbac-police, PurplePanda, а також за допомогою kubectl auth can-i <action> <resource> —as=<principal>.

K8s Secrets рев’ю

Kubernetes секрети містять дуже чутливу інформацію — API ключі, паролі, сертифікати, токени доступу. Необхідно перевірити, що кожен секрет доступний тільки тим сервіс-акаунтам (юзерам, групам) які потребують їх для своїх повсякденних операцій. Зробити це можна за допомогою kubectl-who-can та kubectl auth can-i get secrets/<secret> —as=<principal>. Крім того, варто упевнитись, що в секретах немає long-lived credentials для акаунтів у хмарних середовищах або для Kubernetes сервіс-акаунтів. Наостанок, варто упевнитись, що для ETCD налаштовано шифрування, адже секрети зберігаються саме там.

Аудит безпеки хостів

Контейнери Control Plane та Data Plane запускаються на звичайних серверах (чи віртуальних машинах), тож необхідно упевнитись, що ці хости є захищеними. Локальний доступ до нод дозволяє виконувати код в усіх контейнерах, які на ній запущені (Якщо у локального юзера є такі привілеї або якщо використовується root юзер). Тож необхідно перевірити, що ноди не містять вразливостей, до них мають доступ тільки ті, хто цього потребує і з найменшими привілеями, а також немає векторів локальної ескалації привілеїв. Для пришвидшення перевірок можна використати PEASS-ng.

Аудит безпеки контейнерів

Все, що запускається в Kubernetes, запускається в контейнерах. Вразливості контейнерів можуть поставити під загрозу весь кластер. Для початку, треба перевірити, що доступ до реєстру контейнерів є тільки у тих, кому він потрібен для щоденних задач. Далі необхідно перевірити самі контейнери на наявність вразливостей — просканувати імейджі на наявність вразливостей за допомогою Trivy або Snyk, а також перевірити чи немає hardcoded секретів за допомогою docker history та Dive. Крім того, необхідно перевірити, чи можна втекти з контейнерів на ноди — через privileged налаштування, чутливі маунти і тд. Наостанок, необхідно переконатись, що контейнери не запущені від імені root.

Бонус — Cloud-Managed clusters checks

Використання хмарних сервісів, таких як EKS, AKS та GKS дещо змінює поверхню атаки. Якщо менеджментом Control Plane частини кластера займається клауд провайдер, то не потрібно проводити перевірку шифрування ETCD та наявність аутентифікації на ендпоінтах самого Kubernetes API — за це все відповідає Kubernetes сервіс у хмарі. Але не все так класно, адже натомість додаються загрози, специфічні для хмарних середовищ.

1. Доступні IMDS ендпоінти

IMDS ендпоінти — це спеціальний API для віртуальних машин у хмарних середовищах, звідки віртуальні машини дістають тимчасові ключі які дозволяють користуватись ресурсами клауда (Бакети, лямбда функції, менеджери секретів і тд.). Якщо дати мережевий доступ контейнеру до IMDS, він зможе отримати небажаний доступ до хмарної інфраструктури. Особливо серйозною ця проблема є у середовищах, де необхідно підтримувати ізоляцію між різними тенантами в одному клауд акаунті.

2. Місконфігурації Role Trust Policies / Workload Identities

Крім IMDS ендпоінтів, клауд провайдери надають механізми Role Trust Policies (AWS) та Workload Identities (GCP), які дозволяють надати доступ до ресурсів хмарного середовища конкретному Kubernetes сервіс-акаунту. Проте якщо ці політики написані неправильно, вони можуть надати доступ до компонентів хмари не одному сервіс-акаунту, а групі (або навіть усім сервіс-акаунтам кластера). Це можна побачити по використанню зірочок «*» в політиці або по відсутності директиви «sub».

3. Використання long-lived cloud credentials

Найстарішим і найгіршим способом надати сервіс-акаунту доступ до компонентів клауда є створення постійних ключів для якого клауд IAM юзера, і передача цих ключів контейнеру через Kubernetes секрети, змінні середовища або захардкодити їх у вихідному коді додатка. Такий підхід значно посилює вплив вразливостей, які дозволяють читати файли, і також заважає ротації секретів у самому клауді.

Необхідні доступи

Для проведення White-Box пентесу Kubernetes кластера, необхідно мати 2 юзери (або сервіс-акаунти, не важливо). Перший юзер — read-only — має лише права на читання всього кластера, а другий — адміністратор, має права на читання і запис. Read-only користувач нам потрібен, щоб запускати автоматичні інструменти для бенчмаркінгу кластера та RBAC / ABAC політик, а також для перевірки секретів. Адміністратор потрібен для того, щоб заходити в поди, перевіряти налаштування мережевих політик, а також для ручної верифікації проблем, які були ідентифіковані з read-only правами.

Ремарка

Прохання дати адміністраторський доступ може викликати подив, і дехто каже, що краще дати гранульовані доступи на кожну дію, яку захоче робити аудитор безпеки — окремо доступ на деплой подів, окремо доступ на виконання «exec» операцій, окремо доступ для створення токенів сервіс-акаунтів для етапу перевірки RBAC / ABAC і тд. Проте такий підхід не є більш безпечним і тільки сповільнює аудит. Просто тому, що всі ці дозволи дозволяють провести Kubernetes Privilege Escalation атаки, які дозволять «силою» отримати набагато більше доступу. Так, дозвіл на виконання «exec» дозволить захопити всі сервіс-акаунт токени, що існують в кластері, треба просто зайти в усі контейнери і прочитати токени з файлів. Дозвіл на створення подів або дасть можливість втекти на будь-яку ноду кластера і прочитати токени з /var/* папки, або дасть можливість задеплоїти под, всередину якого будуть маунтитись токени будь-якого сервіс-акаунта. Тож банально простіше одразу дати адміністратора і не витрачати час на створення додаткових акаунтів посеред аудиту.

Прощання

Сподіваюсь, ця стаття була достатньо цікавою і допоможе вам проводити якісніші аудити. Якщо цікаво розглянути більш детально кожен з кроків — звертайтесь!