Компанія Google представила проект gVisor, в рамках якого підготовлено новий відкритий runtime для забезпечення ізольованого запуску контейнерів, які відповідають вимогам специфікації Open Container Initiative (OCI). gVisor може застосовуватися як шар у Docker та Kubernetes, замінюючи пропонований у них штатний runtime. Код gVisor написаний мовою Go та постачається під ліцензією Apache 2.0.

При розробці gVisor було поставлено завдання створення рішення для виконання контейнерів більш легковагого ніж системи віртуалізації, але забезпечує подібний рівень ізоляції. Ключовим компонентом gVisor є власне ядро, написане мовою Go і реалізує більшість системних викликів ядра Linux. Мова Go обрана для забезпечення додаткового захисту завдяки вбудованим засобам контролю типів і меж блоків пам'яті, виключенню проблем use-after-free, захисту від переповнень стека та наявності детектора станів гонки.

Ядро gVisor виконується як звичайний непривілейований процес та забезпечує роботу ізольованого оточення контейнера. За аналогією із системами віртуалізації у кожному подібному оточенні використовується своє ядро ​​та набір віртуалізованих пристроїв, відокремлених від хост-системи та інших контейнерів. Ядро gVisor обробляє всі системні виклики від програм, ізолюючи їхню відмінність від решти системи. При цьому, gVisor не просто транслює системні виклики додатків у запити до ядра Linux, а самостійно реалізує основні примітиви ядра (сигнали, ФС, блокування, мапінг пам'яті, неіменовані канали і т.п.) і вибудовує обробники системних викликів, що надаються додаткам, на основі даних примітивів. Так як ядро ​​gVisor реалізовано у формі звичайного процесу, то для реалізації функціональності примітивів виконується звернення до обмеженого набору штатних системних викликів основного ядра Linux (за аналогією з UML – User Mode Linux).

Подібний підхід надає високу гнучкість в управлінні ресурсами та нижчі накладні витрати в порівнянні з VM, але ціною цього стає підвищення накладних витрат при обробці системних викликів та обмежена сумісність із додатками. В даний час реалізовано близько 200 системних викликів, які найчастіше застосовуються. Деякі системні виклики та параметри поки що не реалізовані, також відсутня підтримка частини ієрархії /proc і /sys, що потребує особливого відношення під час підбору програм для запуску в контейнерах gVisor. З програм, що працюють з gVisor, відзначені Node.js, Java 8, MySQL, Jenkins, Apache httpd, Redis, PHP, Tomcat, WordPress і MongoDB. З додатків, що поки не працюють, можна відзначити nginx, Elasticsearch і PostgreSQL.

Для Для організації доступу до частин основної файлової системи хост-оточення застосовується спеціальний процес-проксі Gofer, що взаємодіє з ядром gVisor за допомогою протоколу 9P. Для доступу до мережі в ядрі gVisor реалізовано власний мережевий стек (netstack), що підтримує відстеження станів з'єднання та перескладання пакетів. Netstack повністю ізольований від мережевого стека ядра Linux та взаємодіє із зовнішнім світом через віртуальний пристрій, що працює в окремому просторі імен. Для особливих ситуацій передбачено режим прямого прокидання мережевих з'єднань, ціною зниження рівня ізоляції. Для перемикання контексту та реалізації карти пам'яті пропонується використовувати Ptrace або KVM.

Нагадаємо, що у звичайних контейнерах застосовується загальне для всіх ізольованих оточень ядро ​​Linux з розмежуванням доступу до ресурсів на рівні cgroups та namespaces, що є слабкою ланкою безпеки, тому що не всі ресурси обмежуються, а вразливість у ядрі Linux компрометує всю систему ізоляції. В умовах, що вимагають надійної ізоляції додатків, застосовується метод запуску кожного контейнера в окремій віртуальній машині зі своїм ядром і системним оточенням, але в порівнянні з контейнерами на базі cgroups і namespaces вказаний спосіб вимагає значно більше ресурсів і витрачає багато часу на запуск. У рамках проекту Kata розвивається runtime на базі гіпервізора та спеціальних урізаних оточень з оптимізованим ядром Linux, яке частково вирішує зазначені проблеми.

Інші новини