Bloodhound-Kube: Візуалізація шляхів атаки в Kubernetes

Обмеження існуючих інструментів

Існуючі інструменти безпеки Kubernetes чудово справляються з виявленням надмірно дозволених ролей RBAC, вразливих робочих об'єктів та неправильних конфігурацій безпеки. Однак вони зазвичай представляють виявлені проблеми як незалежні, а не як пов'язані шляхи атаки. Розуміння того, як зловмисник може перейти від початкової точки до компрометації кластера, може вимагати ручної кореляції багатьох ресурсів Kubernetes, розподілених між кількома просторами імен. Сучасні інструменти безпеки Kubernetes забезпечують чудову видимість окремих ресурсів, відповідаючи на питання типу: «Які користувачі можуть виконувати певну дію?» або «Які ServiceAccounts мають підвищені привілеї?». Проте вони часто не відповідають на найважливіші питання під час оцінки або реагування на інциденти, такі як: «Якщо цей Pod скомпрометовано, куди зловмисник може рухатися далі?» або «Які ServiceAccounts забезпечують найкоротший шлях до адміністратора кластера?».

Bloodhound-Kube: Графовий підхід до безпеки

Для вирішення цієї проблеми був розроблений Bloodhound-Kube. Це інструмент для переліку ресурсів Kubernetes, який використовує формат BloodHound OpenGraph для створення даних, що можуть бути візуалізовані в BloodHound – інструменті для відображення шляхів атаки, що фокусується на Microsoft Active Directory. Замість простого звітування про проблеми з дозволами, інструмент моделює об'єкти Kubernetes як граф ідентичностей, ресурсів та зв'язків. Це дозволяє досліджувати шляхи атаки в Kubernetes, використовуючи існуючі можливості візуалізації та запитів BloodHound, надаючи як червоним, так і синім командам знайомий інтерфейс для розуміння ескалації привілеїв у середовищах Kubernetes.

Як працює Bloodhound-Kube

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

Колектор взаємодіє безпосередньо з API-сервером Kubernetes. Після виявлення підтримуваних ресурсів API, доступних у кластері, він перелічує об'єкти для створення графа. Колектор парсить ресурси у вузли та зв'язки, використовуючи прості функції Go як «правила», зосереджуючись на атрибутах, необхідних для поширених шляхів атаки, неправильних конфігурацій та загальних зв'язків між об'єктами. Наприклад, один RoleBinding створює кілька графових зв'язків: він ідентифікує суб'єкт, пов'язана роль з'єднується з прив'язкою, дозволи ролі парсяться як атрибути вузла, а потім пов'язана роль з'єднується з суб'єктом. Цей підхід розділяє збір даних Kubernetes від генерації графа, що полегшує розширення проєкту.

Виявлення шляхів атаки

Після збору та обробки отриманий граф експортується у форматі BloodHound OpenGraph сумісного JSON. Після імпорту в BloodHound аналітики можуть негайно почати відповідати на питання, такі як: «Які ServiceAccounts можуть стати cluster-admin?», «Які робочі об'єкти розкривають привілейовані Secrets?» або «Як зловмисник може перейти від одного скомпрометованого Pod до іншого?». Замість ручного перегляду сотень або тисяч рядків YAML-маніфестів, ці питання стають Cypher-запитами.

Графовий аналіз стає особливо цінним при дослідженні реальних сценаріїв ескалації привілеїв. Один поширений приклад починається з компрометації Pod. Pod успадковує ServiceAccount, який має дозвіл на читання Secrets у своєму просторі імен. Один з цих Secrets містить облікові дані, що дозволяють розгортати додаткові робочі об'єкти. Ці робочі об'єкти можуть бути налаштовані на виконання з використанням більш привілейованого ServiceAccount з адміністративним доступом до всього кластера. Інший приклад починається зі скомпрометованого Pod, що працює під ServiceAccount, який має дозвіл на створення RoleBindings у своєму просторі імен. Хоча цей дозвіл спочатку може здатися обмеженим, він може дозволити ServiceAccount прив'язати себе до існуючих ролей або ClusterRoles, що надасть додаткові можливості, такі як читання Secrets або створення нових робочих об'єктів. Жоден з цих сценаріїв не є очевидним при розгляді окремих об'єктів RBAC, але обидва стають негайно видимими при представленні як графових зв'язків.

Виявлення та видимість

Колектор, як і будь-який клієнт Kubernetes, взаємодіє виключно через API-сервер Kubernetes, використовуючи автентифіковані API-запити. Перелік в основному складається з операцій лише для читання ресурсів Kubernetes, що призводить до API-запитів, які можуть бути захоплені через Kubernetes Audit Logging. Організації, які вмикають аудит-логінг, можуть відстежувати незвичайну активність переліку, переглядаючи API-запити. Ці запити включають великомасштабні операції списку та отримання даних по ресурсах RBAC, робочих об'єктах, Secrets та інших об'єктах кластера. Автентифікована ідентичність та вихідна IP-адреса надають додатковий контекст для ідентифікації несподіваної активності збору даних.

Дозволи, надані колектору, також безпосередньо впливають на видимість, яку він отримує. Хоча ідентичність cluster-admin забезпечує найповніший граф, колектор також може працювати з більш обмежувальними дозволами, створюючи граф, який точно відображає лише ресурси, видимі автентифікованому користувачеві. Ця поведінка відображає перспективу, доступну зловмиснику, що працює з цими обліковими даними. Оскільки колектор виконує стандартні операції Kubernetes API, виявлення значною мірою узгоджується з існуючими практиками аудиту Kubernetes.

Поточні обмеження та майбутній розвиток

Хоча цей інструмент охоплює багато зв'язків, залучених до тестування безпеки Kubernetes, все ще є можливості для покращення. Поточна реалізація зосереджена переважно на основній авторизації Kubernetes та зв'язках ресурсів. Вона наразі не моделює глибоку мережеву доступність, поширені CRD для компонентів безпеки (такі як політики мережі Istio/CNI) або всі компоненти OpenShift, накладені на Kubernetes. Іншим обмеженням є кількість ребер, що створюються, та складність Cypher-запитів. У великих середовищах з тисячами ресурсів вимоги до ресурсів для виконання запитів стають дуже великими. Майбутній розвиток продовжуватиме покращувати графову модель для представлення додаткових концепцій безпеки Kubernetes.

Висновок

Безпека Kubernetes фундаментально пов'язана зі зв'язками. Ідентичності отримують дозволи через RBAC, робочі об'єкти успадковують ідентичності, контролери створюють ресурси, і ці ресурси відкривають додаткові можливості для ескалації привілеїв. Зосередження на цих компонентах окремо може затьмарити загальну картину. Моделюючи Kubernetes як граф та експортуючи дані, сумісні з BloodHound, Bloodhound-Kube робить ці зв'язки явними. Замість ручного відстеження прив'язок RBAC та взаємодій робочих об'єктів у десятках YAML-маніфестів, фахівці з безпеки можуть візуалізувати повні шляхи атаки та аналізувати ці вектори за допомогою інструментів, які вони вже знають.

Що це означає для розробників

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

Ключові факти

Bloodhound-Kube – це інструмент для переліку ресурсів Kubernetes, який використовує формат BloodHound OpenGraph.
Він моделює об'єкти Kubernetes як граф ідентичностей, ресурсів та зв'язків для виявлення шляхів ескалації привілеїв.
Інструмент інтегрується з BloodHound, дозволяючи візуалізувати та запитувати дані про шляхи атаки за допомогою знайомого інтерфейсу.
Bloodhound-Kube допомагає відповісти на питання про подальші дії атакуючого після компрометації Pod або найкоротші шляхи до адміністратора кластера.
Колектор Bloodhound-Kube взаємодіє з Kubernetes API-сервером, виконуючи операції лише для читання, які можуть бути виявлені через Kubernetes Audit Logging.