Sysbox: Изолированный container runtime. Краткий обзор и настройка

Если лень читать далее, то вот в 3-х предложениях, что такое Sysbox:

1. Sysbox - это "VM-like" контейнеры с возможностью запускать внутри системный софт: Docker, Kubernetes, Systemd, вложенные контейнеры и т.д. 

2. Любой софт, работающий на виртуальной машине, должен также работать в контейнере без проблем и с надежной изоляцией.

3. Никаких сложных настроек, все настраивается за несколько шагов.

А если, тема вас заинтересовала, то вот план на статью:

• Узнаем зачем нужна безопасная контейнеризация

• Что такое Sysbox?

• Сравним с другими похожими технологиями

• Достоинства и недостатки

• Практическая часть:

  • Установка runtime на хостовую машину

  • Запустим sysbox в Docker (или наоборот?)

  • Запустим docker c systemd

  • Запустим docker c вложенным docker контейнером

Зачем нужны контейнеры с повышенным уровнем безопасности и изоляции?

Ответы лежат на поверхности, достаточно ответить на вопрос, нужна ли вам безопасность в запускаемых приложениях? Вы хотите более оптимально использовать ресурсы в ваших контейнерах?

Безопасная - с оговорками, ниже поясним почему.

Очевидные кейсы:

• Построение системы CI/CD.
  Тут подробнее описана эта проблема. Например, мы не хотим, чтобы разные проекты как-то могли затронуть соседей. Если соседей много, то мы не знаем всех соседей в точности.

• Быстрое поднятие множества Dev окружений.
  Контейнеры быстрее работают, чем виртуалки.

• Запуск привилегированных контейнеров в безопасной среде.
  Обычно это не безопасно.

• Запуск не доверенного кода, в том числе security test.

• Сборка образов внутри контейнераDocker-in-Docker (DinD) или Kubernetes-in-Docker (KinD) без привилегированных юзеров, монтирования сокетов Docker на хосте (открываем двери к хостовой машине).

• Более строгая изоляция с возможностью запускать системные приложения.

• Экономия на ресурсах за счет использования свойств ядра хостовой машины.

Если говорить об экономии ресурсов, то это больше актуально для больших нагрузок.

Контейнеризация используется во многих продуктах, например в kubernetes. В этом решении может быть запущено огромное количество подов, в одном кластере может быть до 15000 подов. Основная разница между контейнеризацией и виртуализации с точки зрения утилизации ресурсов - это оверхед по ресурсам у контейнеризации, в случае Sysbox эта разница может достигать 35%. А когда разговор идет о таких объемах запущенных подах, то цифры по счетам могут быть впечатляющими.

Контейнеризация не является безопасным решением, в некоторых случаях можно игнорировать этот факт.

На одной чаше весов безопасность на другой стоимость.

Что такое sysbox?

Sysbox - это open-source container runtime (исполняемая среда контейнеров) от nestybox. В далеком 2019 году sysbox проект был форкнут от OCI runc. Как следствие Sysbox почти на все 100% совместим с OCI runtime спецификацией, тут можно посмотреть больше деталей по вопросу совместимости.

OCI runc был форкнут, чтобы реализовать 2 основных направления, которые не были реализованы на тот момент:

1. Улучшить уровень контейнерной изоляции

   1. Linux user-namespace для контейнеров (например root пользователь в контейнере не имеет привилегий на хосте). Rootless.

   2. Виртуализация procfs & sysfs внутри контейнера

   3. Предотвратить утечку данных из хоста в контейнер

2. Предоставить возможность запускать в контейнерах все то же, что и на виртуальных машинах

   1. Системные утилиты, такие как:  systemd, Docker, Kubernetes, K3s, buildx.

   2. Софт запущенный в контейнере должен работать без изменений самого ПО и без использования специальных версий программного обеспечения (например, запуск без привилегированного пользователя).

   3. Отсутствие привилегированных контейнеров, сложных образов, хитрых точек входа, специальных примонтированных томов и других трюков, все должно работать из коробки.

О Sysbox стоит думать как более продвинутой контейнерезации, которая позволяет вам запускать софт в контейнерах с повышенной изоляцией. Кроме этого запускать софт, который ранее была возможность  запустить только в виртуалках (например запустить контейнер в качестве хоста и внутри контейнера запустить k3s с несколькими нодами).

• Sysbox не использует дополнительную виртуализацию, а только  возможности предоставляемые ОС.

• Sysbox очень просто интегрируется, не нужно изучать новые инструменты. Интеграция в docker занимает буквально 2 действия.

• Sysbox может жить рядом с другими runtimes и вы можете в процессе запуска контейнера определить, какой runtime будете использовать.Это справедливо как для Docker, так и для Kubernetes.

На изображении ниже показано, что  Sysbox работает на уровне хоста без дополнительной виртуализации. В качестве container manager\orchestration может быть использован Docker, k8s(podman имеется в roadmap). В качестве CRI Containerd(отделился от docker и признан Cloud Native Computing Foundation (CNCF) стабильным решением) или CRI-O от всем известной Red-Hat.

Если вы запутались с CRI, runtime …, то тут отличная статья, которая расставит все по полочкам.

Тут можно более подробно почитать про аспекты изоляции в Sysbox.

Сравнение с похожими решениями

Важно отметить, что это сравнение проводилось самими разработчиками и в этом сравнении отсутствуют другие интересные решения, например Firecracker от Amazon. Тут есть более расширенное сравнение с большим количество участников, но не слишком свежий (конец 2020).

Для меня осталось не прозрачной система оценки Isolation Rating.
У разработчиков написано:

Количество звезд - это количество усилий необходимое хакеру, чтобы выйти за область видимости контейнера. 
Привилегированные контейнеры обеспечивают слабую изоляцию. 
Контейнеры, использующие user-namespace Linux, обеспечивают гораздо более сильную изоляцию. 
Контейнеры, работающие в виртуальных машинах, обеспечивают наиболее надежную изоляцию.

У Sysbox есть платная версия Sysbox Enterprise Edition.
На изображении ниже сравнительная таблица возможностей.

Немного о недостатках

• Sysbox не предоставляет жесткой изоляции.
  Если на уровне ядра найдется баг в реализации, то Sysbox использующий это же ядро будет подвержен этому же багу

• Sysbox не может жестко ограничить потребление ресурсов, т.к. Использует все те же механизмы, что предоставляет хостовая ОС.

• Sysbox в бесплатной версии позволяет запускать не более 16 подов в одном кластере.

• Кажется, что основной упор сделан на взаимодействие только с Docker (мнение автора).

• Только ограниченное кол-во Linux дистрибутивов и версиях ядра.

• Повышенное требование к ресурсам хоста.
  А как насчет маломощных систем ? Интересно, как себя поведет Sysbox на raspberry pi.

Чуть больше про преимущества

• На 90% OCI совместим, тут подробнее.
  Почему не 100%? Когда форкались от OCI runc было 100%, куда делись 10% ? Разработчики объясняют это желанием запускать системные(Sysbox так называет контейнеры, в которых можем запустить системный софт типа Systemd, Docker, etc..) контейнер в Docker, чтобы пользователи не изучали новые тулы.

• Запуск внутри почти любой программы внутри Docker.
  Systemd-in-Docker, Docker-in-Docker, Kubernetes-in-Docker, etc. Legacy приложения.

• Максимальная совместимость с Docker, его командами, жизненным циклом.

• Дополнительный упор на безопасность.
  Rootless (нативно в докере уже есть), скрытие информации о хосте, специальная обработка системных вызовов(например сигнал на выключение хоста) и ещё кое-что…

• Никакого оверхеда по сравнению с виртуалками или другими контейнерами.
  Это контейнеры, а значит утилизация ресурсов будет максимальная.

• Может работать у множества SaaS провайдеров: EC2, GCP, GKE, EKS, AKS, Rancher.
  Со множеством оговорок.

Хорошо, как запустить ?

Протестируем на локальном окружении в Docker. 
Работу в k8s или k8saaS (GKE) рассмотрим в другой части, если будет запрос.

Требования к работе с sysbox на локальном окружении:

• Linux ОС.
  Официально поддерживаемые дистрибутивы. Если вашего дистрибутива нет, то можно под него скомпилить из исходников.

• Рекомендуется 4 CPU, 4 RAM.
  Для работы на локальной машине - справедливо, а вопрос работы на маломощных системах - открыт.

• Раз мы тестируем на docker, то у нас должен быть Docker.
  Спасибо капитан очевидность.

На моем локальном окружении все требования выполнены. 

Установка всего несколько шагов

1. sysbox-ce_0.4.1-ubuntu-focal_amd64.deb
   Скачиваем пакет для своего дистрибутива пакет

2. Если на хосте запущены Docker контейнеры, то их надо остановить

   docker rm $(docker ps -a -q) -f

3. Устанавливаем

   sudo apt-get install ./sysbox-ce_0.4.1-ubuntu-focal_amd64.deb

4. Проверим и убедимся, что все установилось как надо
   sudo systemctl status sysbox -n20

   sudo systemctl status sysbox -n20

   Должны увидеть что-то подобное

   

5. Готово

Запуск  docker контейнера с sysbox runtime.

Запустим дистрибутив Ubuntu с интегрированным systemd.
Бонусом запустим еще 1 docker контейнер внутри нашего sysbox контейнера (сон внутри сна ?).

Для того чтобы запустить docker c sysbox runtime, достаточно указать флаг --runtime=sysbox-runc.

docker run --runtime=sysbox-runc --rm -it nestybox/ubuntu-bionic-systemd-docker

После запуска авторизуемся:
L: admin
P: admin

Проверим, что systemd запущен:

ps -fu root

systemctl

Как видим, процесс запущен и работает внутри контейнера.

Давайте запустим docker внутри docker.

docker run -it alpine ash

На хостовой машине вложенного контейнера не видно

Если перейти в хостовую систему, ты мы не найдем следов нашего alpine контейнера.

Остановим контейнеры и на этом наш тест на локальном окружении может быть завершен.

Заключение

Sysbox делает упор на безопасность контейнеров и изоляцию. Если вам нужна дешевая контейнеризация с более продвинутой изоляцией и секьюрностью, то попробовать это решение однозначно стоит. 
Например, тут недавно вышел свежий обзор от разработчиков о безопасности в kubernetes && sysbox.

На субъективный взгляд автора, если нужна изоляция, то берем нормальную виртуализацию. 
Если нужна экономия ресурсов и бюджета, то берем нативное решение предлагаемое провайдером, т.к. ни один другой инструмент не будет лучше протестирован и не будет лучше поддерживать внутренние фичи провайдера.

При выборе стоит обратить на:

• Максимальную совместимость решения с OCI, CNI и другими общими стандартами

• Совместимость с фичами провайдера, если они конечно вам нужны

• Остальное как у всех, поддерживаемость, как часто отвечают на issue, etc…

Хочется верить, что в ближайшем будущем при выборе исполняемой среды все решения будут поддерживать общепринятые стандарты, интеграция будет легкая, а выбор будет основан только на  количестве фич, которым способно порадовать решение.

P.S.

Если интересно узнать по подробнее о взаимодействии с sysbox, то пишите в комментариях.

Примерный план на следующие части:

1. Интегрируем Sysbox secure runtime в k8s

2. Проверим как облачные провайдеры работают с Sysbox

3. Запустим часть workload в безопасных контейнерах, а часть в стандартном runtime предлагаемый облачным провайдером

   1. Это будут GitLab runners

4. Проведем аудит Sysbox на безопасность доступными утилитами

5. Проведем нагрузочные тесты Sysbox, чтобы сравнить производительность различных runtimes.

P.P.S.

Известно ли мне, что Docker мертв, или Docker уже умер, Kubernetes is deprecating Docker ?

Ну так и тут про container runtime, а не про Docker. На локальных машинах docker удобно использовать и так же удобно менять runtime, как например в случае с sysbox. Docker - это уже не один монолит(был до версии 1.11) и мы можем его конфигурить более гибко, хотя до идеала далеко. Ну, а для действительно стоящих задач sysbox использует  CRI-O, тут подробнее.

Хотя надеюсь таких вопросов не возникнет, потому, что в первых строчках указано, что это форк от OCI runc.

Также хочу пригласить всех желающих на бесплатный вебинар по теме: "Принципы организации инфраструктурного кода и работа над инфраструктурой в команде на примере Terraform". Регистрация доступна по ссылке.

DevOps курсы от практикующих экспертов. DevOps learning: практики и инструменты | OTUS

otus.ru