Загрози виконання в Kubernetes: Вразливості та захист

Модель загроз під час виконання в Kubernetes

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

MITRE ATT&CK для контейнерів документує техніки, які зловмисники використовують проти контейнерних середовищ, включаючи Kubernetes. Ці техніки включають виконання (наприклад, T1610 Розгортання контейнера), стійкість (T1525 Впровадження внутрішнього образу), підвищення привілеїв (T1611 Вихід на хост) та доступ до облікових даних (T1552 Незахищені облікові дані, наприклад, токени, виявлені через служби метаданих контейнера або хмарного екземпляра). Це створює структуровану таксономію загроз, специфічну для рівня виконання контейнерів та оркестрації.

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

Загрози під час виконання в Kubernetes структурно відрізняються від загроз для віртуальних машин через те, як платформа реалізує ізоляцію та повноваження. Ізоляція контейнерів залежить від просторів імен Linux, cgroups, можливостей та seccomp, а не від меж гіпервізора. Кілька робочих навантажень спільно використовують простір ядра на кожному вузлі.

Вихід з контейнера

Вихід з контейнера порушує примітивні межі Linux, на які Kubernetes покладається для ізоляції робочих навантажень. Привілейовані контейнери з можливістю CAP_SYS_ADMIN можуть маніпулювати функціями ядра, що впливають на хост. Монтування hostPath до чутливих каталогів хоста — кореневої файлової системи хоста, /proc, /sys або /var/lib/kubelet — надає контейнерам прямий доступ до ресурсів хоста.

Уразливість CVE-2022-0492 у функції release_agent cgroup v1 ядра Linux могла дозволити процесу виконувати команди на хості. Однак на практиці це вимагало, щоб контейнер вже мав CAP_SYS_ADMIN або іншим чином міг монтувати файлову систему cgroup v1. Ці умови не виконуються для посиленого пода (без root, з відкинутими можливостями, seccomp RuntimeDefault). Ця вразливість продемонструвала конкретний вектор виходу з контейнера, що ґрунтується на примітиві Linux, на якому будується ізоляція подів Kubernetes. Подальше посилення безпеки (профілі seccomp, відмова від CAP_SYS_ADMIN) та обмежений профіль Kubernetes Pod Security Standards вирішують цю та подібні вектори виходу на рівні оркестрації.

Компрометація середовища виконання контейнера створює інший шлях виходу. Якщо зловмисник може зловживати сокетом CRI (containerd або CRI-O), він може маніпулювати життєвим циклом контейнера поза контролем Kubernetes. Неправильно налаштовані контексти безпеки подів, що дозволяють успадкування можливостей або відключають функції безпеки, такі як AppArmor або SELinux, розширюють поверхню для виходу.

Обмежений профіль Pod Security Standards блокує найнебезпечніші конфігурації, відкидаючи всі можливості за замовчуванням, забороняючи привілейовані контейнери, забороняючи монтування hostPath та вимагаючи seccomp RuntimeDefault або користувацьких профілів.

Зловживання API-сервером та etcd

kube-apiserver служить центральним органом для всіх операцій кластера. Усі команди kubectl, дії контролерів та виклики вебхуків надходять через цю точку. Рішення щодо автентифікації та авторизації приймаються на API-сервері, що робить його як основним кордоном безпеки, так і найціннішою мішенню.

Зловживання токенами ServiceAccount є найпоширенішим шаблоном атаки на API-сервер. ServiceAccount — це ідентичності кластера, які застосунки використовують для виклику Kubernetes API. Кожен под може монтувати токен ServiceAccount, а прив'язки RBAC визначають, що ця ідентичність може робити. Надмірно широкі RBAC створюють радіус ураження при компрометації пода.

Поширені шаблони зловживання включають використання підстановочних знаків у ClusterRoleBindings (verbs: ["*"]), надання доступу cluster-admin ServiceAccount, яким він не потрібен, та монтування токенів ServiceAccount у подах, які не викликають API. Томи токенів монтуються лише для читання за замовчуванням за адресою /var/run/secrets/kubernetes.io/serviceaccount/token, якщо автоматичне монтування не вимкнено.

etcd зберігає весь стан кластера і може бути доступний безпосередньо, якщо зловмисник досягає вузла площини управління (де працює etcd) і etcd не налаштований з взаємною TLS-автентифікацією клієнта. Прямий доступ до etcd дозволяє читати та записувати весь стан кластера, повністю обходячи автентифікацію та авторизацію API-сервера.

Ризик зловживання API-сервером змінюється завдяки RBAC з найменшими привілеями з явним визначенням дієслів та ресурсів, відключенню автоматичного монтування ServiceAccount за замовчуванням (automountServiceAccountToken: false) та налаштуванню аудиту для фіксації спроб підвищення привілеїв.

Зловживання ідентичністю робочого навантаження та горизонтальне переміщення

Ідентичність робочого навантаження Kubernetes федеративно інтегрується в Cloud IAM, створюючи шлях для ескалації компрометації контейнера до доступу до хмарних ресурсів. Механізми, такі як AWS IRSA, GCP Workload Identity Federation та Azure Workload Identity, дозволяють подам приймати ролі Cloud IAM без зберігання довгострокових облікових даних у кластері.

Коли под з ідентичністю робочого навантаження скомпрометований, зловмисник успадковує дозволи Cloud IAM, пов'язані з ServiceAccount цього пода. Ця федерація відбувається через обмін токенами OIDC — kubelet надає токен OIDC, який служба Cloud IAM приймає в обмін на тимчасові облікові дані.

Ролі IAM вузлів створюють додатковий ризик горизонтального переміщення. Якщо досягнуто виходу з контейнера, зловмисник може прийняти роль IAM, призначену базовому екземпляру EC2, групі вузлів EKS або пулу вузлів GKE. Ідентичність сервісної сітки (сертифікати mTLS) може бути використана для горизонтального переміщення між службами, якщо компрометована система управління сертифікатами.

Горизонтальне переміщення між просторами імен відбувається через спільні ServiceAccount, прогалини в мережевій політиці, що дозволяють зв'язок між подами через межі просторів імен, або спільні постійні томи. Мережеві політики за замовчуванням у багатьох кластерах дозволяють весь зв'язок між подами всередині кластера.

Обмеження горизонтального переміщення включає найменші привілеї ідентичності робочого навантаження (ролі Cloud IAM, обмежені лише необхідними ресурсами), мережеві політики, що за замовчуванням забороняють зв'язок між просторами імен, та ізоляцію ServiceAccount (унікальний ServiceAccount для кожного застосунку, без спільного використання між просторами імен).

Загрози ланцюга постачання та образів під час виконання

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

Підписання образів та контроль допуску є межею примусового виконання, але техніки обходу можуть подолати слабкі політики. Контролери допуску, налаштовані на дозвіл образів з неавтентифікованих реєстрів, застарілі конфігурації вебхуків політик або відсутність перевірки підпису образу створюють прогалини.

Init-контейнери виконуються перед контейнерами застосунків і можуть бути використані для встановлення стійкості або модифікації середовища виконання. Sidecar-контейнери, що працюють поруч з контейнерами застосунків, можуть бути впроваджені через компрометацію або неправильне налаштування контролера допуску.

Поверхня атаки під час виконання залежить від складу образу. Distroless-образи містять лише середовище виконання застосунку та залежності, зменшуючи доступні інструменти атаки. Мінімальні образи на базі Alpine Linux надають оболонку, але обмежені системні утиліти. Повні образи на базі Ubuntu або CentOS надають повні набори інструментів операційної системи, які зловмисники можуть використовувати.

Ризик ланцюга постачання під час виконання змінюється завдяки контролерам допуску, налаштованим на вимогу підписів образів з довірених реєстрів, використанню distroless або мінімальних базових образів, що зменшують можливості після компрометації, та веденню журналів походження образів, що відстежують, які образи виконуються у вашому кластері.

Спостережуваність безпеки під час виконання: Що моніторити

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

Журналювання kube-audit фіксує всі запити до API-сервера. Критичні класи подій включають підвищення привілеїв (модифікації RBAC, створення ClusterRoleBinding), виконання команд у подах та доступ до секретів. Політику аудиту слід налаштувати для фіксації цих подій без перевантаження обсягу журналів.

Сигнали середовища виконання контейнерів показують, які процеси виконуються всередині подів, які мережеві з'єднання вони встановлюють та які файли вони змінюють. Інструменти, такі як Falco, сенсори на основі eBPF або агенти безпеки під час виконання, забезпечують цю видимість. Критичні сигнали включають несподіване виконання процесів, мережеві з'єднання з зовнішніми IP-адресами, яких немає в дозволених списках, та модифікації файлів у монтованих шляхах лише для читання.

Журнали аудиту хмари (AWS CloudTrail, GCP Cloud Audit Logs, Azure Activity Logs) фіксують зловживання ідентичністю IAM після компрометації пода. Коли використовується ідентичність робочого навантаження, компрометація пода, що призводить до доступу до хмарних ресурсів, відображається в журналах аудиту хмари, а не лише в журналах аудиту кластера.

Походження образів та рішення про допуск повинні бути зафіксовані для можливості проведення судової експертизи. Знання того, які образи були дозволені або заблоковані контролерами допуску та з яких реєстрів вони походили, допомагає відстежувати компрометацію ланцюга постачання.

Пріоритети посилення безпеки, що змінюють результати

Застосування обмеженого профілю Pod Security Standards суттєво зменшує ризик виходу з контейнера. Обмежений профіль за замовчуванням відкидає всі можливості, забороняє привілейовані контейнери, забороняє монтування hostPath, вимагає виконання від користувача без root та встановлює профілі seccomp RuntimeDefault. Це слід впроваджувати через контролери допуску, які відхиляють поди, що порушують профіль.

Принцип найменших привілеїв RBAC усуває дозволи з підстановочними знаками, які можуть призвести до компрометації всього кластера. Слід уникати ClusterRoleBindings з verbs: ["*"] або resources: [""]. RoleBindings повинні бути обмежені конкретними просторами імен та лише необхідними дієсловами. ServiceAccount повинні мати чітко задокументовані вимоги до ресурсів та дієслів.

Відключення автоматичного монтування ServiceAccount за замовчуванням запобігає непотрібному розкриттю токенів API. Встановіть automountServiceAccountToken: false у специфікаціях подів та визначеннях ServiceAccount, якщо робоче навантаження не вимагає доступу до API. Це усуває файли токенів з подів, які не викликають Kubernetes API.

Найменші привілеї федерації ідентичності робочого навантаження обмежують радіус ураження при компрометації подів. Ролі Cloud IAM, пов'язані з ServiceAccount, повинні мати мінімальні необхідні дозволи, сесії з обмеженим часом (де підтримується) та обмеження за ресурсами (на рівні бакета, а не на рівні облікового запису).

Коренева файлова система лише для читання, де це можливо, запобігає модифікації файлової системи під час виконання. Встановіть readOnlyRootFilesystem: true у контекстах безпеки контейнерів. Застосунки, що вимагають шляхів для запису, можуть використовувати томи emptyDir для тимчасового зберігання.

Вихід з контейнера та зловживання API-сервером є загрозами з найвищим радіусом ураження в більшості конфігурацій кластера. Обмежений профіль Pod Security Standards та RBAC з найменшими привілеями вирішують ці основні вектори атаки. Інші елементи контролю зменшують можливості горизонтального переміщення та стійкості після компрометації.

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

Розробникам необхідно розуміти, як архітектура їхніх кластерів Kubernetes впливає на профіль ризиків. Важливо впроваджувати елементи контролю, що обмежують радіус ураження при компрометації, такі як застосування обмеженого профілю Pod Security Standards, налаштування RBAC за принципом найменших привілеїв та відключення автоматичного монтування ServiceAccount токенів за замовчуванням.

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

Загрози під час виконання в Kubernetes експлуатують рівень оркестрації між робочими навантаженнями та базовою ОС Linux.
Поширені вектори атак включають неправильно налаштовані поди, контейнери з надмірними привілеями та надмірно дозволені призначення ролей Kubernetes.
Загрози поділяються на структурні категорії: вихід з контейнера, зловживання API-сервером, зловживання ідентичністю робочого навантаження та загрози ланцюга постачання.
Ізоляція контейнерів залежить від просторів імен Linux, cgroups, можливостей та seccomp, а не від меж гіпервізора.
kube-apiserver є центральною точкою авторизації, і його компрометація може надати зловмисникам повноваження імітованої ідентичності.