Podman, KVM та контейнери: практичний посібник з безпечної віртуалізації

Інформатек Діджитал » Ресурси » Podman, KVM та контейнери: практичний посібник з безпечної віртуалізації

Коли ви починаєте налаштовувати серйозне контейнерне середовище в Linux, одразу виникає те саме питання: Наскільки безпечно покладатися виключно на контейнери, і коли доцільно перейти на KVM або мікровіртуальні машини? У корпоративному середовищі, де використовуються віртуальні машини Docker, Podman, LXC, KVM та різні гіпервізори, добре розуміння моделі ізоляції є ключем до уникнення помилок.

Крім того, дещо заплутані сценарії не є рідкістю, такі як спробуйте використовувати Docker Desktop або Podman всередині віртуальної машини у VirtualBox або KVMЦе включає кілька рівнів віртуалізації (вкладених чи ні), і легко зіткнутися з помилками, такими як «KVM не ввімкнено на хості». Давайте організуємо всі ці частини: контейнери, віртуальні машини, Podman, KVM, мережу та безпеку, і подивимося, як їх поєднати для досягнення справді безпечної та практичної віртуалізації.

Класична віртуалізація з KVM та віртуальними машинами

Основою всієї цієї системи залишається віртуалізація операційної системи завершити використанням гіпервізорів, таких як KVM, Xen або ESXiТут фізичне обладнання запускає гіпервізор, який відповідає за «розділення» машини на кілька незалежних віртуальних машин.

У цій моделі кожна віртуальна машина запускається власне ядро ​​та власна гостьова операційна системаповністю окремо від хоста. Гіпервізор (наприклад, KVM, інтегрований у ядро ​​Linux) діє як охоронець між обладнанням та віртуальними машинами та відповідає за надійну ізоляцію між ними.

Зазвичай ми говоримо про два типи гіпервізорів: тип 1 або «голе залізо», які розміщуються безпосередньо на обладнанні, та тип 2, що розміщуються на існуючій операційній системі. VirtualBox або VMware Workstation будуть типу 2Тоді як KVM, керований libvirt на сервері Linux, ближчий до сценарію першого типу, навіть якщо він використовує спільний простір із самим хостом.

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

Для керування цими віртуалізованими платформами в GNU/Linux майже завжди використовується libvirt як API оркестрації, на додаток до яких підтримуються графічні інструменти та інструменти командного рядка, або більші проекти, такі як OpenStack, які створюють цілі хмари, поєднуючи віртуальні машини, базові обчислення та контейнери.

Вимоги до обладнання та поширені проблеми з KVM

Перш ніж запускати KVM або використовувати рішення, що залежать від нього (наприклад, деякі конфігурації Docker Desktop або мікро-VM), потрібно переконатися, що Процесор підтримує апаратну віртуалізацію (VT-x на Intel або SVM/AMD-V на AMD) і що є увімкнено в BIOS/UEFI.

У Linux у нас є швидка перевірка: чи команда grep -E 'svm|vmx' /proc/cpuinfo Якщо нічого не повертається або опція залишається вимкненою в прошивці, KVM не працюватиме. Крім того, у сценаріях, де ми запускатимемо віртуальні машини всередині іншої віртуальної машини (вкладена віртуалізація), гіпервізор верхнього рівня повинен явно надати ці розширення гостьовій системі.

Коли щось йде не так, з'являються типові повідомлення, такі як відоме спливаюче вікно Docker Desktop у RHEL 9 у VirtualBox: «KVM не ввімкнено на хості»Проблема тут не в Docker чи RHEL безпосередньо, а в тому, що віртуальна машина VirtualBox не отримує необхідних розширень віртуалізації для запуску KVM всередині неї.

Команди типу modprobe kvm o modprobe kvm_amd / kvm_intel Модулі ядра повинні завантажуватися без повідомлень про помилки. Якщо в dmesg нічого відповідного не відображається, або lsmod | grep kvm Він показує лише "голі" KVM та IRQ BYPASS, а конкретні модулі процесора відсутні; дуже ймовірно, що Віртуалізація обладнання не розкривається до гостьової системи або вимкнено в прошивці.

У цих сценаріях, навіть якщо всередині хоста активовано все можливе, Якщо VirtualBox не пропонує вкладену віртуалізацію або вона неправильно налаштована, KVM просто не буде використовуватися.Рішення включає перевірку конфігурації гіпервізора хоста (VirtualBox, VMware тощо) та ввімкнення вкладеної віртуалізації, якщо вона доступна.

Контейнери: легка віртуалізація на рівні операційної системи

Порівняно з традиційними віртуальними машинами, контейнери пропонують альтернативний підхід: Не все обладнання емулюється; натомість повторно використовується ядро ​​хоста. а процеси та ресурси ізольовані за допомогою функцій ядра Linux.

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

Контейнери пропонують майже нативну продуктивність, оскільки Немає ні другого ядра, ні повної емуляції обладнання.Накладні витрати невеликі: достатньо лише для налаштування просторів імен, обмеження ресурсів за допомогою контрольних груп та застосування політик безпеки (seccomp, AppArmor, SELinux тощо).

Однак, така конструкція має важливий наслідок: Усі корисні навантаження мають одне й те саме фізичне ядроСерйозна вразливість у цьому ядрі може раптово стати потенційним вектором втечі для всіх контейнерів, що працюють на цьому вузлі.

Ось чому люди часто говорять про утеплення контейнерів. Це не «абсолютно», як у віртуальної машиниЯкщо комусь вдається використати критичну помилку ядра, простори імен перестають бути ефективним бар'єром, і межі між контейнерами та хостами можуть бути порушені.

Простори імен та контрольні групи: основа ізоляції контейнерів

У Linux ізоляція контейнерів побудована на двох основних принципах: простори імен для розділення системних подань y контрольні групи для обмеження та обліку ресурсів.

Простори імен ізолюють такі речі, як PID, мережа, точки монтування, IPC, ім'я хоста (UTS) та користувачіТаким чином, процес «бачить» лише процеси, мережеві інтерфейси, файлову систему та ім'я хоста власного простору імен, створюючи відчуття перебування в іншій системі.

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

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

Розумний спосіб посилити середовище — це поєднати фільтри системних викликів із seccomp, політики MAC (AppArmor або SELinux) та різке скорочення можливостей процесів, в ідеалі разом із просторами імен користувачів та режимом без доступу до root, щоб мінімізувати шкоду, якщо комусь вдасться залишити контейнер.

Загрози безпеці на контейнерних платформах

У реальній контейнерній платформі поверхня атаки розподілена по кількох шарах: ядро та середовище виконання (runc, container, CRI-O), ланцюжок постачання образів, конфігурація контейнера/оркестратора та базова інфраструктура (хмара, сховище даних, IAM, мережа).

Типові вектори атак включають уразливості програмного забезпечення у середовищі виконання ядра або контейнера, використання незахищених або непідтримуваних образів, помилки конфігурації в Kubernetes або Docker (привілейовані контейнери, небезпечні монтування хостів, надмірно відкриті мережеві режими) та недоліки безпеки в реєстрах або конвеєрах CI/CD.

У багатьох реальних інцидентах трапляється не окремий «магічний баг», а поєднання відомої вразливості та ненадійної конфігурації: контейнери, що працюють від імені root, використання прапорця –privileged, монтування файлової системи хоста всередині контейнера та відсутність seccomp або MAC.

До всього цього додається питання ланцюга поставок: Публічні базові образи часто містять CVE, застарілі пакети та погано контрольовані залежності.Шкідливе програмне забезпечення відносно легко проникає, або скомпрометована бібліотека залишається сплячою, доки не виникнуть умови для виконання.

Тому у виробництві це не є необов'язковим: Зображення потрібно сканувати на наявність вразливостей за допомогою таких інструментів, як Trivy, Clair або Grype.Контролюйте, які реєстри використовуються (Harbor, Quay, GHCR з політиками) та підписуйте/перевіряйте образи перед їх розгортанням у кластері.

Docker проти Podman: вплив на модель загроз

У світі контейнерів додатків Docker та Podman виконують схожі функції, але Його архітектура значно відрізняється, і це змінює модель безпеки. з яким ми працюємо на хості.

Docker, у своєму класичному root-режимі, спирається на центральний демон (dockerd), який працює від імені rootCLI взаємодіє з цим демоном через /var/run/docker.sock або через TCP, і саме цей привілейований процес створює та знищує контейнери, керує образами, мережами та томами, а також взаємодіє з реєстрами.

Це означає, що Будь-хто, хто має доступ до сокета Docker, по суті має root-доступ до хоста.Оскільки демон може запускати привілейовані контейнери, монтувати довільні файлові системи та змінювати критичну конфігурацію, він фактично стає єдиною точкою відмови.

Подман, з іншого боку, народився з ідеєю бути контейнерним рушієм без демона та максимально "нативним" для LinuxНемає постійного централізованого процесу; контейнери залежать від користувача або systemd, а інтеграція з останнім дозволяє керувати контейнерами через сервісні блоки.

Такий підхід краще відповідає моделі Unix, яка передбачає, що «кожен процес належить користувачеві, який його запускає». уникайте залежності від демона з високими привілеямиКрім того, Podman пропонує сумісність з командами Docker, що спрощує міграцію (ви навіть можете використовувати псевдонім docker=podman у середовищах, де ви не хочете встановлювати Docker CE).

Режим без доступу до root та простори імен користувачів

Одним з головних практичних досягнень у зменшенні впливу потенційного витоку з контейнера є режим без доступу до root у поєднанні з просторами імен користувачівПитання, яке тут розглядається: «Що станеться, якщо контейнер врешті-решт витіке?»

Простори імен користувачів дозволяють перепризначити UID контейнера 0 на непривілейований UID на хостіІншими словами, всередині контейнера застосунок вважає себе root-користувачем, але з точки зору хоста, цей процес насправді є звичайним користувачем із призначеним діапазоном subuid/subgid.

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

Podman був розроблений з самого початку з урахуванням цієї моделі: безкоренева контейнеризація за замовчуванням, коли це можливо, використання SELinux/AppArmor та cgroups навіть без root-прав, а також сильний акцент на мінімізації структурних привілеїв.

Докер також має "Справжній" режим без доступу до коренівУ цьому середовищі Dockerd та його контейнери знаходяться в просторі імен користувачів, на відміну від старішої системи `userns-remap`, де демон залишався root-доступом. З точки зору безпеки, це запобігає експлойту проти Dockerd, який може автоматично надати root-доступ до хоста.

Контейнерні мережі з Podman: інтерфейси bridge, host, macvlan та rootless

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

Представлено Podman 4 Netavark, мережевий драйвер, що відповідає моделі CNI щоб надати контейнерам IP-адреси в мережах-мостах, macvlan тощо. У NetAvark root-контейнери зазвичай за замовчуванням підключаються до мережі під назвою "podman", пов'язаної з мостом Linux (podman0) на хості, з адресою 10.88.0.0/16.

Ця мережа мостів за замовчуванням забезпечує Базове підключення до Інтернету через правила SNAT Це дозволяє вам надати порти контейнерів хосту за допомогою `-po --publish`, що генерує правила DNAT в iptables/nftables. Для сумісності з Docker ця мережа не активує внутрішній DNS-сервер.

Ми також можемо творити визначені користувачем мостові мережіЦі рішення ізолюють групи контейнерів один від одного та пропонують внутрішній DNS. Це дозволяє контейнерам розпізнавати дані за іменем у межах їхньої приватної мережі, спрощує розділення служб, які не повинні бачити один одного, та забезпечує більше контролю над MTU, брандмауерами та іншими налаштуваннями.

У більш просунутих середовищах можна використовувати мережі macvlan або ipvlan для підключення контейнерів безпосередньо до фізичної мережі Macvlan дозволяє контейнерам взаємодіяти один з одним, тоді як ipvlan має тенденцію більше ізолювати їх; це корисні опції в розгортаннях, де кожен контейнер повинен розглядатися рештою мережі як справжній хост.

Безкорневі мережі: slirp4netns та паста

Коли користувач не є root-правом, все ускладнюється: Користувач без привілеїв не може вільно змінювати простір імен глобальної мережі. ані створювати довільні інтерфейси, тому Podman змушений вдаватися до рішень у просторі користувача для забезпечення зв'язку.

Ось тут і починається справа slirp4netns, класичний механізм, який використовує Podman rootlessЦей проєкт створює ізольоване мережеве середовище всередині контейнера та використовує модуль slirp ядра для перетворення адрес (NAT) та дозволяє контейнеру отримувати доступ до Інтернету через мережу хоста.

На практиці, slirp4netns створює інтерфейс TAP у просторі імен мережі контейнера (наприклад, tap0 з IP 10.0.2.100 та шлюзом 10.0.2.2) та маршрутизує трафік через стек TCP/IP, реалізований у просторі користувача. Це функціонально, але додає деякі накладні витрати та певні обмеження.

Одним із таких обмежень є те, що Непривілейовані користувачі не можуть використовувати порти нижче 1024Параметр sysctl net.ipv4.ip_unprivileged_port_start позначає, який порт вважається "непривілейованим" (за замовчуванням, 1024), хоча його можна ретельно налаштувати, якщо це дозволяє модель безпеки.

У Podman 5 slirp4netns замінено на вставити як безкореневий механізм за замовчуваннямPasta також працює повністю в просторі користувача, але завдяки інтерфейсу tap та методам нульового копіювання вона досягає майже нативної продуктивності мережі, зменшуючи вплив на затримку та пропускну здатність порівняно зі slirp4netns.

Мережі-містки та хости в контейнерах без коренів

Навіть працюючи в режимі без root-доступу, ми можемо Підключіть безкореневі контейнери до мережі мосту "podman" за замовчуванням використовуючи –network=podman. Це використовує можливості netavark та призначає порти хосту за допомогою -p, як і в rootful режимі.

Також можливо створити визначені користувачем мостові мережі в середовищах без коренівУ цьому випадку мости та пов'язані з ними пристрої створюються не в глобальному просторі імен хоста, а в просторі імен користувача, тому з хоста ми не побачимо ці інтерфейси за допомогою простої команди sudo ip a.

Щоб оглянути ці безкореневі мости, Подман пропонує команду podman розблокувати –rootless-netnsЦе відкриває оболонку в просторі імен мережі користувача. Звідти можна спостерігати внутрішні мости та перевіряти пряме підключення до контейнерів.

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

На іншому кінці знаходиться мережа хоста (–network=host)У цьому режимі контейнер використовує мережевий стек разом з хостом без власної IP-адреси. Якщо контейнер без доступу до root запускає сервер на порту 8080/tcp, сервіс буде безпосередньо доступний на порту 8080 хоста, що зберігає зіставлення портів, але зменшує ізоляцію.

Podman Desktop, інструменти обробки зображень та локальна оркестрація

Для тих, хто віддає перевагу чомусь більш візуальному, Podman Desktop забезпечує графічне середовище для керування контейнерами, подами, образами та мережевими конфігураціями на машинах розробки, діючи як пряма альтернатива Docker Desktop, але спираючись на бездемонський рушій.

Отримання зображення здійснюється за допомогою Команда `podman pull` завантажує дані з регістрів, визначених у `/etc/containers/registries.conf`.Якщо ми вкажемо зображення без назви запису, Podman спробує знайти його в налаштованому порядку записів, використовуючи за замовчуванням найновіший тег.

Окрім CLI Podman, ми також можемо використовувати skopeo як спеціальний інструмент для керування, перевірки та копіювання зображень між локальними реєстрами та репозиторіями. Такі команди, як копіювання, видалення або синхронізація, дозволяють автоматизувати синхронізацію між репозиторіями, позначати образи для збору сміття або переміщувати артефакти між середовищами.

Після завантаження зображення, podman run дозволяє запускати контейнери, вказуючи транспорт та маршрут (За замовчуванням Docker транспортує та шукає в налаштованих регістрах). Звичайні опції (-d, -p, --name, --pod тощо) охоплюють як лабораторні сценарії, так і більш серйозні розгортання.

Щоденне управління здійснюється за допомогою `podman ps` для перегляду списку контейнерів, `podman stop / start` для зупинки або запуску існуючих екземплярів та `podman rm` для видалення зупинених контейнерів.Якщо контейнер було змінено, і ми хочемо конвертувати його в нове зображення, podman commit зберігає ці зміни під новим ім'ям.

Поди та розширені моделі виконання з Podman

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

Команда `podman pod create` створює новий пакет і повертає його ідентифікатор, але за замовчуванням pod залишається зупиненим, доки не буде запущено пов'язаний контейнер або його не буде явно запущено за допомогою podman pod start.

Щоб побачити, які поди є в системі, ви використовуєте podman pod lsТакож буде перераховано контейнер INFRA, пов'язаний з кожним із них. Цей спеціальний контейнер підтримує роботу мережі та інших спільних ресурсів pod-системи, тому кількість контейнерів ніколи не дорівнює нулю.

Podman пропонує певні команди для запуск, зупинка або перезапуск цілих подів (запуск/зупинка/перезапуск подмана)Але ми також можемо діяти лише з певним контейнером усередині pod-системи, не змінюючи решту, зберігаючи ізоляцію процесу на рівні програми.

Щоб додати більше контейнерів до існуючого pod, ви використовуєте podman запустити –pod НАЗВА_ПІДКАДотримуючись того ж синтаксису, що й для окремих контейнерів. Контейнер не можна «видалити» з поду, не знищивши його, оскільки членство в поді пов’язане з його життєвим циклом.

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

Контейнери, LXC та віртуалізація застосунків

Хоча Докер та Подман домінують у розмові, Це не єдині варіанти контейнеризації в GNU/LinuxІснують такі рішення, як LXC/LXD, systemd-nspawn або Kata Containers, які підходять до проблеми з дещо інших точок зору.

LXC надає Дуже легкі системні контейнери з власним ім'ям хоста, IP-адресою, файловою системою та повним ініціалізацією.У поєднанні з LXD, який виступає гіпервізором для контейнерів та віртуальних машин, ви отримуєте досвід, дуже близький до використання кількох легких машин з майже повністю базовою продуктивністю.

Хоча Docker/Podman зосереджуються на OCI-сумісні контейнери застосунківLXC є незамінним, коли потрібні постійні середовища з кількома сервісами та процесами, які поводяться як віртуальна машина, але з меншими накладними витратами та дуже природною інтеграцією з ядром Linux.

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

Поряд з цим вони також набрали сили технології, орієнтовані на мікро-віртуальні машини та посилену ізоляцію, такі як контейнери KataЦі опції запускають кожен pod у невеликій віртуальній машині з власним ядром, тоді як gVisor вставляє написану на Go "пісочницю ядра" між програмою та Linux. Обидва варіанти зменшують залежність від спільного ядра та наближаються до моделі безпеки віртуальних машин, зберігаючи при цьому ергономіку контейнерів.

Найкращі практики для посилення захисту Docker та Podman

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

На практиці доцільно прийняти як стандарт, що Контейнери повинні працювати в режимі без прав root, коли це можливо.особливо в багатокористувацьких середовищах або в спільних хмарах. Podman спрощує це одразу після встановлення, а Docker rootless дотримується тієї ж філософії, коли потрібна сумісність.

Ядро хоста повинно будьте в курсі оновлення безпекиТакі вразливості, як Dirty COW, Dirty Pipe та інші, вирішуються за допомогою оновлень, які необхідно застосовувати відносно швидко, якщо ми не хочемо залишати двері відкритими для витоків з контейнерів.

Ще один дуже ефективний захід – це використання Незмінні контейнерно-орієнтовані дистрибутиви, такі як openSUSE MicroOS або Flatcar LinuxЙого root-доступ лише для читання та система атомарних оновлень значно зменшують поверхню для атаки та полегшують відкат, якщо щось піде не так після виправлення.

Щодо конфігурації: Немає привілейованих контейнерів у продакшені, окрім випадків гіперконтролю.Не запускайте програми від імені root всередині контейнера, використовуйте файлові системи лише для читання, коли це можливо, та обмежте можливості до абсолютного мінімуму. Профілі SELinux/AppArmor та seccomp, адаптовані до фактичних викликів програми, майже обов'язкові.

Зрештою, ми не повинні забувати про частину про моніторинг часу виконанняТакі інструменти, як Falco, Sysdig Secure або Aqua, допомагають виявляти аномалії, спроби втечі (наприклад, незвичайний доступ до /proc або /sys), нетиповий мережевий трафік або підозрілі команди, надаючи час для реагування до того, як атака почнеться.

Поєднуючи класичну віртуалізацію з KVM, контейнерами, що керуються Podman (бажано в rootless режимі), добре сегментованими мережами та належними практиками посилення захисту, можна створити дуже гнучку та досить безпечну платформу віртуалізації. Розуміння того, що спільне ядро ​​є найважливішою точкою, покладання на віртуальні машини або мікровіртуальні машини, коли цього вимагає ризик або відповідність нормативним вимогам, та ретельне управління ланцюжком постачання образів – це різниця між лабораторним середовищем та інфраструктурою, готовою до виробництва.