Модуль 4.3: Втеча з контейнера
Складність:
[СЕРЕДНЯ]- Обізнаність щодо загрозЧас на виконання: 25-30 хвилин
Передумови: Модуль 4.2: Поширені вразливості
Що ви зможете робити
Розділ «Що ви зможете робити»Після завершення цього модуля ви зможете:
- Визначити конфігурації, що дозволяють втечу з контейнера: привілейований режим, hostPID, hostNetwork, записуваний hostPath
- Оцінити радіус ураження втечі з контейнера на основі доступу на рівні вузла та RBAC
- Оцінити стратегії запобігання: контексти безпеки, застосування PSA та пісочниця виконання
- Пояснити реальні сценарії втечі з контейнера та рівні захисту, що їх блокують
Чому цей модуль важливий
Розділ «Чому цей модуль важливий»Втеча з контейнера — вихід за межі контейнера для отримання доступу до хоста — є найсерйознішою проблемою безпеки контейнерів. Розуміння того, які конфігурації уможливлюють втечу, допомагає будувати безпечні значення за замовчуванням та розпізнавати небезпечні налаштування до того, як вони потраплять у продакшн.
KCSA перевіряє вашу здатність ідентифікувати конфігурації, які дозволяють втечу з контейнера, та розуміти стратегії запобігання. Вам не потрібно знати конкретні команди експлуатації — це територія CKS — але ви маєте розпізнавати ризиковані налаштування та знати, як їм запобігти.
Що таке втеча з контейнера?
Розділ «Що таке втеча з контейнера?»┌─────────────────────────────────────────────────────────────┐│ ВИЗНАЧЕННЯ ВТЕЧІ З КОНТЕЙНЕРА │├─────────────────────────────────────────────────────────────┤│ ││ НОРМАЛЬНА ІЗОЛЯЦІЯ КОНТЕЙНЕРА: ││ ┌─────────────────────────────────────────────────────┐ ││ │ ХОСТ │ ││ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ ││ │ │ Контейнер A │ │ Контейнер B │ │ Контейнер C │ │ ││ │ │ (ізольов.) │ │ (ізольов.) │ │ (ізольов.) │ │ ││ │ └─────────────┘ └─────────────┘ └─────────────┘ │ ││ └─────────────────────────────────────────────────────┘ ││ Контейнери не бачать і не впливають на хост або один ││ на одного ││ ││ ВТЕЧА З КОНТЕЙНЕРА: ││ ┌─────────────────────────────────────────────────────┐ ││ │ ХОСТ ← КОМПРОМЕТОВАНИЙ │ ││ │ ┌─────────────┐ │ ││ │ │ Контейнер A │──→ ВТЕЧА ──→ Повний доступ до │ ││ │ │ (зловмисн.) │ хоста │ ││ │ └─────────────┘ │ ││ └─────────────────────────────────────────────────────┘ ││ Зловмисник порушує ізоляцію, отримує доступ до хоста ││ ││ ВПЛИВ: Компрометація вузла, горизонтальне переміщення, ││ можлива компрометація кластера ││ │└─────────────────────────────────────────────────────────────┘Фактори ризику: що робить втечу можливою?
Розділ «Фактори ризику: що робить втечу можливою?»1. Привілейовані контейнери
Розділ «1. Привілейовані контейнери»┌─────────────────────────────────────────────────────────────┐│ РИЗИК ПРИВІЛЕЙОВАНОГО КОНТЕЙНЕРА │├─────────────────────────────────────────────────────────────┤│ ││ КОНФІГУРАЦІЯ: ││ securityContext: ││ privileged: true ││ ││ ЩО ЦЕ НАДАЄ: ││ • Всі можливості (capabilities) Linux ││ • Доступ до всіх пристроїв хоста (/dev/*) ││ • Без фільтрації seccomp ││ • Обхід SELinux/AppArmor ││ ││ ЧОМУ ЦЕ НЕБЕЗПЕЧНО: ││ Зловмисник усередині привілейованого контейнера може ││ змонтувати файлову систему хоста, отримати доступ до ││ чутливих файлів хоста та змінювати конфігурації хоста — ││ фактично отримуючи повний контроль над хостом із ││ мінімальними зусиллями. ││ ││ ТРИВІАЛЬНА ВТЕЧА — Ніколи не використовуйте ││ privileged: true ││ │└─────────────────────────────────────────────────────────────┘2. Спільний доступ до просторів імен хоста
Розділ «2. Спільний доступ до просторів імен хоста»┌─────────────────────────────────────────────────────────────┐│ РИЗИКИ ПРОСТОРІВ ІМЕН ХОСТА │├─────────────────────────────────────────────────────────────┤│ ││ hostPID: true ││ ├── Контейнер бачить усі процеси хоста ││ ├── Може надсилати сигнали процесам хоста ││ └── Зловмисник може інспектувати або взаємодіяти з ││ процесами хоста, потенційно отримуючи доступ ││ на рівні хоста ││ ││ hostNetwork: true ││ ├── Контейнер використовує мережевий стек хоста ││ ├── Може прив'язуватися до будь-якого порту хоста ││ └── Може перехоплювати весь мережевий трафік хоста ││ ││ hostIPC: true ││ ├── Доступ до спільної пам'яті хоста ││ └── Може комунікувати з процесами хоста через IPC ││ │└─────────────────────────────────────────────────────────────┘3. Небезпечні монтування томів
Розділ «3. Небезпечні монтування томів»┌─────────────────────────────────────────────────────────────┐│ РИЗИКИ HOSTPATH │├─────────────────────────────────────────────────────────────┤│ ││ НЕБЕЗПЕЧНІ МОНТУВАННЯ: ││ ││ hostPath: { path: / } ││ └── Повний доступ до файлової системи хоста ││ ││ hostPath: { path: /etc } ││ └── Можна читати/змінювати облікові дані та конфігурацію ││ хоста ││ ││ hostPath: { path: /var/run/docker.sock } ││ └── Контроль демона Docker → створення привілейованих ││ контейнерів ││ ││ hostPath: { path: /var/log } ││ └── Читання журналів, потенційно чутливі дані ││ ││ hostPath: { path: /root/.ssh } ││ └── Крадіжка SSH-ключів ││ ││ ЧОМУ DOCKER-СОКЕТ ОСОБЛИВО НЕБЕЗПЕЧНИЙ: ││ Доступ до Docker-сокету надає повний контроль над ││ середовищем виконання контейнерів. Зловмисник може ││ використати його для запуску нових привілейованих ││ контейнерів з доступом до файлової системи хоста, ││ фактично здійснюючи втечу на хост. ││ │└─────────────────────────────────────────────────────────────┘4. Небезпечні можливості (capabilities)
Розділ «4. Небезпечні можливості (capabilities)»┌─────────────────────────────────────────────────────────────┐│ НЕБЕЗПЕЧНІ МОЖЛИВОСТІ │├─────────────────────────────────────────────────────────────┤│ ││ CAP_SYS_ADMIN ││ ├── Майже еквівалентно root ││ ├── Дозволяє монтування файлових систем ││ └── Може використовуватися для порушення ізоляції ││ контейнера ││ ││ CAP_SYS_PTRACE ││ ├── Дозволяє відлагодження процесів ││ └── У поєднанні з hostPID може взаємодіяти з процесами ││ хоста небезпечним чином ││ ││ CAP_NET_ADMIN ││ ├── Налаштування мережевих інтерфейсів ││ └── Перехоплення трафіку, зміна маршрутизації ││ ││ CAP_DAC_READ_SEARCH ││ ├── Обхід перевірок дозволів на читання файлів ││ └── Читання будь-якого файлу незалежно від власності ││ ││ CAP_DAC_OVERRIDE ││ ├── Обхід усіх перевірок дозволів на файли ││ └── Запис у будь-який файл незалежно від власності ││ ││ НАЙКРАЩА ПРАКТИКА: Скинути ВСІ можливості, потім додати ││ лише ті, які потрібні вашому застосунку. ││ │└─────────────────────────────────────────────────────────────┘5. Вразливості ядра
Розділ «5. Вразливості ядра»┌─────────────────────────────────────────────────────────────┐│ ВТЕЧА ЧЕРЕЗ ЕКСПЛОЙТ ЯДРА │├─────────────────────────────────────────────────────────────┤│ ││ КОНЦЕПЦІЯ: ││ • Контейнери спільно використовують ядро хоста ││ • Вразливість ядра = можливість втечі ││ • Працює навіть із "безпечними" налаштуваннями ││ контейнера ││ ││ ПРИКЛАДИ: ││ ├── Dirty COW (CVE-2016-5195) ││ ├── Dirty Pipe (CVE-2022-0847) ││ └── Різні CVE підвищення привілеїв ││ ││ ЗАХОДИ ЗАХИСТУ: ││ • Тримати ядро оновленим ││ • Використовувати seccomp для обмеження системних викликів││ • Розглянути ізольовані середовища виконання (gVisor, ││ Kata) ││ • Ізольовані середовища використовують інше ядро або ││ перехоплюють системні виклики, зменшуючи поверхню ││ атаки ядра ││ │└─────────────────────────────────────────────────────────────┘Стратегії запобігання
Розділ «Стратегії запобігання»Pod Security Standards
Розділ «Pod Security Standards»┌─────────────────────────────────────────────────────────────┐│ PSS ЗАПОБІГАЄ ВТЕЧІ │├─────────────────────────────────────────────────────────────┤│ ││ СТАНДАРТ BASELINE БЛОКУЄ: ││ ├── privileged: true ││ ├── hostNetwork: true ││ ├── hostPID: true ││ ├── hostIPC: true ││ └── Чутливі монтування hostPath ││ ││ СТАНДАРТ RESTRICTED ДОДАТКОВО: ││ ├── Вимагає non-root ││ ├── Вимагає профіль seccomp ││ ├── Скидає всі можливості ││ └── Вимагає файлову систему тільки для читання ││ ││ УВІМКНЕННЯ У ПРОСТОРІ ІМЕН: ││ kubectl label ns production \ ││ pod-security.kubernetes.io/enforce=restricted ││ │└─────────────────────────────────────────────────────────────┘Захист у глибину
Розділ «Захист у глибину»┌─────────────────────────────────────────────────────────────┐│ ЗАПОБІГАННЯ ВТЕЧІ З КОНТЕЙНЕРА │├─────────────────────────────────────────────────────────────┤│ ││ РІВЕНЬ 1: БЕЗПЕКА ПОДІВ ││ ├── Pod Security Standards (Restricted) ││ ├── Без привілейованих контейнерів ││ ├── Без спільного доступу до просторів імен хоста ││ ├── Без небезпечних монтувань hostPath ││ └── Скинути всі можливості ││ ││ РІВЕНЬ 2: БЕЗПЕКА ЧАСУ ВИКОНАННЯ ││ ├── Профілі seccomp (мінімум RuntimeDefault) ││ ├── Профілі AppArmor/SELinux ││ ├── Файлова система тільки для читання ││ └── Запуск як non-root користувач ││ ││ РІВЕНЬ 3: ІЗОЛЯЦІЯ ЧАСУ ВИКОНАННЯ ││ ├── Розглянути gVisor для недовірених навантажень ││ ├── Розглянути Kata Containers для сильної ізоляції ││ └── Класи середовища виконання для різних рівнів безпеки ││ ││ РІВЕНЬ 4: МОНІТОРИНГ ││ ├── Безпека часу виконання (Falco) ││ ├── Моніторинг цілісності файлів ││ └── Виявлення аномалій ││ │└─────────────────────────────────────────────────────────────┘Ізольовані середовища виконання
Розділ «Ізольовані середовища виконання»┌─────────────────────────────────────────────────────────────┐│ ВАРІАНТИ ІЗОЛЬОВАНИХ СЕРЕДОВИЩ ВИКОНАННЯ │├─────────────────────────────────────────────────────────────┤│ ││ gVisor (runsc) ││ ├── Ядро в просторі користувача ││ ├── Перехоплює та емулює системні виклики ││ ├── Контейнер не взаємодіє безпосередньо з ядром хоста ││ ├── Накладні витрати продуктивності ││ └── Підходить для: Недовірених навантажень, мультитенант ││ ││ Kata Containers ││ ├── Легка ВМ на контейнер ││ ├── Окреме ядро від хоста ││ ├── Ізоляція через апаратну віртуалізацію ││ ├── Більші накладні витрати, ніж у gVisor ││ └── Підходить для: Максимальної ізоляції, відповідності ││ ││ ВИКОРИСТАННЯ RUNTIME CLASSES: ││ apiVersion: node.k8s.io/v1 ││ kind: RuntimeClass ││ metadata: ││ name: gvisor ││ handler: runsc ││ --- ││ spec: ││ runtimeClassName: gvisor # Використання у pod spec ││ │└─────────────────────────────────────────────────────────────┘Чи знали ви?
Розділ «Чи знали ви?»-
Більшість втеч з контейнерів — це неправильні конфігурації, а не zero-day. Правильна конфігурація запобігає більшості сценаріїв втечі.
-
Монтування Docker-сокету є одним із найпоширеніших векторів втечі. Воно надає зловмиснику повний контроль над середовищем виконання контейнерів, роблячи компрометацію хоста тривіальною.
-
gVisor перехоплює понад 200 системних викликів та реалізує їх у просторі користувача, значно зменшуючи поверхню атаки ядра.
-
Kata Containers використовують ту саму технологію гіпервізора (QEMU/KVM), що й віртуальні машини, забезпечуючи ізоляцію на рівні ВМ для контейнерів.
Поширені помилки
Розділ «Поширені помилки»| Помилка | Чому це шкодить | Рішення |
|---|---|---|
| privileged: true для зручності | Тривіальна втеча | Використовувати конкретні capabilities |
| Монтування Docker-сокету | Контейнер контролює всі контейнери | Використовувати альтернативи |
| hostPath до чутливих каталогів | Прямий доступ до хоста | Використовувати PV/PVC |
| Відсутність примусового PSS | Дозволяє небезпечні конфігурації | Увімкнути PSS у просторах імен |
| Запуск від root | Вищі привілеї після експлойту | runAsNonRoot: true |
Перевірка знань
Розділ «Перевірка знань»-
Що робить привілейований контейнер легким для втечі?
Відповідь
Привілейовані контейнери мають усі можливості Linux, доступ до всіх пристроїв хоста, без фільтрації seccomp та обхід SELinux/AppArmor. Це дозволяє тривіальну втечу через монтування файлової системи хоста або безпосередній доступ до пристроїв хоста. -
Чому hostPID: true є ризиком втечі з контейнера?
Відповідь
З hostPID контейнер може бачити всі процеси хоста. У поєднанні з можливостями, такими як CAP_SYS_PTRACE або CAP_SYS_ADMIN, зловмисник може інспектувати або взаємодіяти з процесами хоста, потенційно отримуючи доступ на рівні хоста. Pod Security Standards (Baseline і вище) блокують це налаштування. -
Чому монтування Docker-сокету небезпечне, і як цьому запобігти?
Відповідь
Docker-сокет надає повний контроль над середовищем виконання контейнерів. Зловмисник може використати його для запуску нових привілейованих контейнерів з доступом до файлової системи хоста, фактично здійснюючи втечу на хост. Запобігайте цьому через примусове застосування Pod Security Standards, які блокують чутливі монтування hostPath, та уникайте монтування Docker-сокету в специфікаціях подів. -
Як ізольовані середовища виконання на кшталт gVisor запобігають втечі?
Відповідь
gVisor запускає ядро в просторі користувача, яке перехоплює та емулює системні виклики. Контейнер ніколи безпосередньо не взаємодіє з ядром хоста, тому вразливості ядра не можуть бути використані для втечі. -
Який рівень Pod Security Standard запобігає більшості технік втечі з контейнера?
Відповідь
Baseline запобігає найнебезпечнішим налаштуванням (privileged, простори імен хоста). Restricted додає додатковий захист (non-root, seccomp, скинуті capabilities) для сильнішого запобігання.
Практична вправа: Аналіз шляхів втечі
Розділ «Практична вправа: Аналіз шляхів втечі»Сценарій: Проаналізуйте цю специфікацію поду та визначте шляхи втечі:
apiVersion: v1kind: Podmetadata: name: risky-podspec: hostPID: true containers: - name: app image: ubuntu:20.04 securityContext: capabilities: add: - SYS_ADMIN - SYS_PTRACE volumeMounts: - name: docker-sock mountPath: /var/run/docker.sock - name: host-root mountPath: /host volumes: - name: docker-sock hostPath: path: /var/run/docker.sock - name: host-root hostPath: path: /Завдання:
- Визначте всі фактори ризику втечі в цій специфікації поду
- Поясніть, чому кожен із них небезпечний
- Напишіть виправлену версію відповідно до Restricted Pod Security Standard
Фактори ризику
Цей под має кілька факторів ризику втечі:
1. Монтування Docker-сокету (/var/run/docker.sock)
- Надає повний контроль над середовищем виконання контейнерів
- Зловмисник може запустити нові привілейовані контейнери з доступом до хоста
2. Монтування кореневої файлової системи хоста (/ змонтовано в /host)
- Прямий доступ на читання/запис до всієї файлової системи хоста
- Облікові дані, конфігурація та SSH-ключі — все відкрито
3. hostPID + CAP_SYS_PTRACE
- Контейнер може бачити всі процеси хоста та взаємодіяти з ними
- Може використовуватися для інспекції пам’яті процесів хоста або отримання доступу до хоста
4. hostPID + CAP_SYS_ADMIN
- У поєднанні з видимістю PID хоста дозволяє маніпуляцію просторами імен
- Майже еквівалентно запуску безпосередньо на хості
Запобігання: Видаліть ВСІ ці налаштування. Застосуйте Restricted Pod Security Standard.
Виправлена специфікація поду
apiVersion: v1kind: Podmetadata: name: secure-podspec: # Без hostPID, hostNetwork або hostIPC containers: - name: app image: ubuntu:20.04 securityContext: runAsNonRoot: true runAsUser: 1000 readOnlyRootFilesystem: true allowPrivilegeEscalation: false capabilities: drop: - ALL seccompProfile: type: RuntimeDefault # Без томів hostPath — використовуйте PVC, якщо потрібне сховищеХочете вивчити практичні техніки експлуатації та тестування безпеки? Див. трек CKS для лабораторних робіт з наступальної безпеки.
Підсумок
Розділ «Підсумок»Втеча з контейнера порушує фундаментальну обіцянку ізоляції:
| Вектор втечі | Конфігурація | Запобігання |
|---|---|---|
| Привілейований | privileged: true | Ніколи не використовувати у продакшні |
| Простори імен хоста | hostPID/Network/IPC | Блокувати через PSS |
| Шляхи хоста | hostPath: / | Використовувати PV/PVC |
| Можливості | CAP_SYS_ADMIN | Скинути всі, додати мінімум |
| Експлойти ядра | Спільне ядро | Ізольовані середовища виконання |
Стратегія захисту:
- Примусово застосовувати Pod Security Standards (мінімум Baseline, бажано Restricted)
- Використовувати seccomp та AppArmor/SELinux
- Розглянути ізольовані середовища виконання для недовірених навантажень
- Моніторити спроби втечі за допомогою Falco
Наступний модуль
Розділ «Наступний модуль»Модуль 4.4: Загрози ланцюга постачання — Розуміння та зменшення ризиків ланцюга постачання програмного забезпечення.