Проект CoreOS (https://www.opennet.me/opennews/art.shtml?num=40275), развивающий основанное на идеях контейнерной изоляции серверное окружение, представил (https://coreos.com/blog/rkt-hits-1.0.html) выпуск инструментария управления контейнерами rkt 1.0 (https://coreos.com/rkt/) (ранее известен как Rocket), который позиционируется как более безопасная, переносимая и адаптированная для серверного применения альтернатива инструментарию Docker. Код rkt написан на языке Go и распространяется (https://github.com/coreos/rkt) под лицензией Apache 2.0.
Выпуск rkt 1.0 позиционируется как первый стабильный релиз, пригодный для промышленного применения. Формат данных на диске и интерфейс командной строки зафиксированы и в будущем будут развиваться без нарушения обратной совместимости. API пока стабилизирован не полностью, но уже пригоден для использования и начального внедрения.
Основные особенности rkt:- Расширенные механизмы обеспечения безопасности: изоляция с использованием гипервизора KVM (https://coreos.com/rkt/docs/latest/running-lkvm-stage1.html), поддержка SELinux, SVirt и seccomp, интеграция TPM (https://tectonic.com/trusted-computing) (Trusted Platform Module), верификация образов по цифровой подписи, разделение привилегий.
- Помимо традиционных контейнеров на основе пространств имён (namespaces) и групп управления (cgroups) изолированные окружения могут создаваться и при помощи других технологий, включая обычный chroot (контейнеры fly) и виртуальные окружения Clear Linux (https://www.opennet.me/opennews/art.shtml?num=42272) (компактные и быстрые как обычные контейнеры, но предоставляющие более высокий уровень изоляции за счёт применения гипервизора KVM);
- Поддержка образов Docker и контейнеров, построенных в соответствии со спецификацией App Container (https://github.com/coreos/rocket/blob/master/app-container/S...). Таким образом, rkt может применяться в окружениях, изначально развёрнутых при помощи Docker, или для построении новой инфраструктуры на базе формата App Container;- Модель выполнения без использования фонового управляющего процесса с применением методов разделения привилегий для минимизации кода, выполняемого с правами root. Операции загрузки контейнера, проверки целостности и верификации по цифровой подписи выполняются под непривилегированным пользователем (в docker все выполняется под root). Для управления контейнером используются средства запуска изолированных окружений, предоставляемые системами инициализации, такими как systemd, runit и upstart, или системами оркестровки кластеров (Nomad, Kubernetes). Rkt позволяет достигнуть значительно более высокого уровня защищённости по сравнению с Docker, в котором все операции проводятся с участием одного централизованного фонового процесса;
- Многоуровневая модульная архитектура, разделяющая операции работы с контейнером, на отдельные стадии, отдельно обрабатывающие этапы настройки файловой системы, подготовки исполняемого окружения и запуска приложений в контейнере. Кроме безопасности подобный подход также позволяет добиться хорошей расширяемости за счёт возможности реализации дополнительных функций через подключение дополнений. Выделяются три основные стадии запуска контейнера:
- Нулевая стадия, обработка которой производится силами утилиты rkt без привлечения дополнительных средств. На данной стадии производится начальная подготовка контейнера: генерация UUID и манифеста, создания файловой системы для контейнера, настройка директорий для выполнения следующих стадий, копирование исполняемого файла первой стадии в ФС контейнера, извлечение заданных ACI (App Container Image), распаковка образов и копирование приложений в директории третьей стадии;
- Первая стадия, работа которой обеспечивается отдельным исполняемым файлом, имеющим полномочия настройки cgroups, запуска процессов и выполнения операций под пользователем root. На данной стадии осуществляется создание исполняемой группы на основе ФС, подготовленной в нулевой стадии, установка cgroups, пространств имён и точек монтирования. Настройка производится через генерацию unit-файлов systemd и использование systemd-nspawn для организации работы окружения;
- Вторая стадия, на которой производится непосредственный запуск приложения в подготовленном контейнере. В частности, на данной стадии выполняется процесс инициализации содержимого контейнера, описанный в манифесте запуска приложения (Application Manifest).
URL: https://coreos.com/blog/rkt-hits-1.0.html
Новость: http://www.opennet.me/opennews/art.shtml?num=43824
> изоляция с использованием гипервизора KVM, поддержка SELinux,А что, SEL менее безопасен, чем изоляция + SEL?
SEL слишком сложный. Как следствие больше шансов ошибиться в написании правил для него. Да и вообще он совсем не для этого был сделан.
`setenforce Permissive` с последующим обучением через `audit2allow < audit.log` с участием мозга админа уже запретили?
нынешний selinux гораздо больше похож на apparmor, чем на старый selinux. делать setenforce 0 глобально уже не надо, можно выключить отдельный домен. audit2allow тоже не нужен (как человек, вынужденный админить системы с selinux, не могу представить ситуацию его применения)
читай что написанно в прошлом сообщении ещё 100500 раз ...
Ещё есть:http://vagga.readthedocs.org/en/latest/
https://github.com/tailhook/vagga
Вменяемой документации еще бы, а то как всем этим пользоваться не понятно.
А час одно лучше VM, если все равно гипервизор?