Реализация rootless kubernetes в рамках ALTLinux-пакетов (Александр Степченко, OSSDEVCONF-2023) — различия между версиями
Материал из 0x1.tv
StasFomin (обсуждение | вклад) |
StasFomin (обсуждение | вклад) |
||
(не показана одна промежуточная версия этого же участника) | |||
;{{SpeakerInfo}}: {{Speaker|Александр Степченко}} <blockquote> Рассматриваются вопросы одной из первых реализаций rootless kubernetes в рамках ALTLinux-пакетов защиты контейнерных решений podsec (Podman Security). * Сравнение rootless и rootfull-решения. * Особенности реализации rootless-решения. * Механизмы защиты от несанкционированного доступа и использования уязвимостей </blockquote> {{VideoSection}} {{vimeoembed|892800464|800|450}} {{youtubelink|}} |l2ksiI75xbg}} {{SlidesSection}} [[File:Реализация rootless kubernetes в рамках ALTLinux-пакетов (Александр Степченко, OSSDEVCONF-2023).pdf|left|page=-|300px]] {{----}} == Thesis == * https://github.com/alt-cloud/podsec === Базовое решение Usernetes === Реализация <tt>rootless kubernetes</tt> была сделана на основе проекта [https://github.com/rootless-containers/usernetes Usernetes]. [[File:2023-kaf-img001.png|center]] Отличие данного решения от стандартного <tt>rootfull</tt>-решения: * Основные программы (<tt>kube-apiserver</tt>, <tt>kube-controller</tt>, <tt>kube-scheduler</tt>, <tt>kube-proxy</tt>, <tt>coredns</tt>, <tt>etcd</tt>, …) запускаются в виде сервисов, а не в виде контейнеров. * Сертификаты генерируются сторонней программой (<tt>cfssl</tt>) и помещаются в тома, доступные узлам кластера. Достоинства данного решения: * Позволяет разворачивать rootless kubernetes в одноузловом или кластерном варианте. * Обеспечивает быстрое тестирование решения путём разворачивания <tt>rootless kubernetes</tt> в виде стека сервисов (<tt>docker-</tt> <tt>compose</tt>) в рамках одного сервера. В то же время это решение носит экспериментальный характер, что предопределило следующие недостатки: * Генерация сертификатов производится программой <tt>cfssl</tt>, отсутствующей в репозитории пакетов <tt>ALTLinux</tt>. * Для создания и доступа к сертификатам необходимо использовать либо <tt>docker-тома,</tt> либо <tt>разделяемую файловую систему</tt>. * Решение создаётся без использования стандартной команды разворачивания кластера <tt>kubeadm</tt>, что ограничивает варианты разворачивания решения в виде кластера. * Решение поднимается либо в виде стека сервисов (<tt>docker-</tt> <tt>compose</tt>) в рамках одного сервера, либо требует создание <tt>разделяемого тома</tt> в рамках кластера для доступа к сертификатам. * Процедуры добавления, удаления узлов в кластер, обновления сертификатов нестандартные и требуют дополнительной квалификации от системного администратора. * Реализация основных компонент кластера в виде сервисов, а не в виде контейнеров (<tt>POD</tt>’ов) несёт потенциальные риски при обновлении версий <tt>kubernetes</tt>, так как требует анализа возможных изменений в образах новых версий <tt>kubernetes</tt>. === Стандартная схема разворачивания rootfull kubernetes кластера через команду kubeadm === Для снятия основных недостатков необходимо было реализовать на основе <tt>Usernetes</tt> вариант разворачивания <tt>rootless kubernetes</tt>-кластера через стандартную программу <tt>kubernetes</tt> — <tt>kubeadm</tt>. Процесс разворачивания <tt>rootfull-кластера</tt> через <tt>kubeadm</tt> выглядит следующим образом: [[File:2023-kaf-img002.png|center|Схема инициализации rootfull master сервера]] При запуске на начальном (<tt>Init</tt>) <tt>Master</tt>(<tt>ControlPlane</tt>) узле <tt>kubeadm init</tt> производит следующие основные действия: * загружает с регистратора все необходимые (<tt>kube-apiserver</tt>, <tt>kube-controller</tt>, <tt>kube-scheduler</tt>, <tt>kube-proxy</tt>, <tt>coredns</tt>, <tt>etcd</tt>, …) <tt>kubernetes</tt>-образы; * запускает через <tt>systemctl start kubelet</tt> сервис <tt>kubelet</tt>; * генерирует сертификаты и kubernet-манифесты в каталоге <tt>/etc/kubernetes/manifests/;</tt> * поднимает через <tt>kubelet</tt> основные контейнеры (<tt>POD</tt>’ы); * конфигурирует одноузловой кластер и записывает его конфигурацию в <tt>etcd</tt>; * генерирует строки подключения (<tt>kubeadm join ...</tt>) к кластеру <tt>ControlPlane</tt> и <tt>Worker</tt> узлов. Для подключения дополнительных узлов на них запускается команда <tt>kubeadm join </tt> с указанными параметрами. === Разворачивание rootless-кластера через команду kubeadm === Реализованный в рамках ALTLinux пакет <tt>podsec-k8s</tt>\footnote{[https://github.com/alt-cloud/podsec]} — это набор скриптов, который позволяет разворачивать rootless-кластер стандартной немодифицированной бинарной командой <tt>kubeadm</tt>. Все разворачиваемые процессы в <tt>rootless kubernetes</tt> кластере запускаются в <tt>user namespace</tt> системного пользователя <tt>u7s-admin</tt>, обладающего обычными (непривилегированными) правами. Таким образом, все <tt>POD</tt>’ы имеют права обычного непривилегированного пользователя и не могут при взломе повлиять на функционирование узла. === Разворачивание Master(ControlPlane) rootless -узла === Скрипты пакета <tt>podsec-k8s</tt> находятся в каталоге <tt>/usr/libexec/podsec/u7s/bin</tt>. Часть из них (<tt>kubeadm</tt>, <tt>systemctl</tt>) являются оболочками над стандартными командами системы с аналогичным именем. За счёт установки переменной <tt>PATH</tt> export PATH=/usr/libexec/podsec/u7s/bin/:$PATH они вызываются до вызова основных системных команд <tt>kubeadm</tt> и <tt>systemctl</tt>, и после выполнения настройки среды вызывают основные системные команды. [[File:2023-kaf-img003.png|center|Схема инициализации rootless master сервера]] При запуске на начальном (<tt>Init</tt>) <tt>Master</tt>(<tt>ControlPlane</tt>) узле скрипт <tt>kubeadm init</tt> производит следующие основные действия: * В окружении пользователя <tt>u7s-admin</tt> запускает сервис <tt>rootlesskit</tt>, который позволяет запускать процессы с правами «псевдоroot». Процессы в рамках <tt>user namespace</tt> пользователя <tt>u7s-admin</tt> имеют права <tt>root</tt> (<tt>UID=0</tt>), могут создавать сетевые интерфейсы, настраивать правила маршрутизации <tt>iptables</tt> и выполнять другие системные действия. Но в рамках <tt>HOST-системы</tt> все производимые действия изолируются в <tt>user namespace</tt> пользователя <tt>u7s-admin</tt> и никак не взаимосвязаны с системными ресурсами HOST-системы. В процессе <tt>rootlesskit</tt> в рамках <tt>user namespace</tt> пользователя <tt>u7s-admin</tt> запускаются: ** подпроцесс <tt>crio</tt>, обеспечивающий работу с контейнерами; ** подпроцесс <tt>slirp4net</tt>, обеспечивающий создание сетевых интерфейсов и работу с ними. * В рамках <tt>user namespace</tt> пользователя <tt>u7s-admin</tt> запускается стандартная бинарная команда <tt>kubeadm.</tt> * В рамках этого <tt>namespace</tt> команда <tt>kubeadm</tt> имеет права <tt>псевдо-</tt> <tt>root</tt>: ** Загружает с регистратора все необходимые (<tt>kube-apiserver</tt>, <tt>kube-controller</tt>, <tt>kube-scheduler</tt>, <tt>kube-proxy</tt>, <tt>coredns</tt>, <tt>etcd</tt>, …) <tt>kubernetes</tt>-образы. ** Запускает через <tt>systemctl start kubelet</tt> сервис <tt>kubelet</tt>. ** Генерирует сертификаты и kubernet-манифесты в каталоге <tt>/etc/kubernetes/manifests/</tt>. ** Поднимает через <tt>kubelet</tt> основные контейнеры (<tt>POD</tt>’ы). ** Конфигурирует одноузловой кластер и записывает его конфигурацию в <tt>etcd</tt>. ** Генерирует строки подключения (<tt>kubeadm join ...</tt>) к кластеру <tt>ControlPlane</tt> и <tt>Worker</tt>-узлов. * Производит настройку интерфейсов и правил <tt>iptables</tt> в HOST-системе и <tt>user namespace</tt> пользователя <tt>u7s-admin</tt> * Производит настройку файлов конфигурации (<tt>.kube/config</tt>) пользователе <tt>root</tt> и <tt>u7s-admin</tt>. Таким образом, при запуске скрипта <tt>kubeadm</tt> пакета <tt>podsec-k8s</tt> производится полноценная настройка <tt>Master</tt> (<tt>ControlPlane</tt>) узла <tt>rootless кластера</tt>. === Подключение дополнительных ControlPlane и Worker-узлов === Подключение дополнительных ControlPlane и Worker узлов производится аналогичным образом: * Устанавливается пакет <tt>podsec-k8s</tt>. * Устанавливается переменная среды <tt>PATH</tt>: * Запускается скрипт ‘kubeadm’ пакета <tt>podsec-k8s</tt> в режиме <tt>kubeadm join ...</tt> с параметрами, сгенерированными при установке начального <tt>Master</tt> (<tt>ControlPlane</tt>) узла. === Группа пакетов podsec (Podman Security) === Пакет <tt>podsec-k8s</tt> входит в состав группы пакетов: * <tt>podsec</tt> ** Разворачивание локального регистратора (<tt>regitry.local</tt>) и сервера подписей (<tt>sigstore.local</tt>). ** Создание пользователей группы <tt>podsec-dev</tt>, имеющих права на создание docker-образов, их подписывание и размещение в локальном регистраторе. ** Создание пользователей группы <tt>podsec</tt>, имеющих возможность запуска подписанных образов с локального регистратора. Работа с образами из других источников не допускается. ** Настройка политик доступа и работы с образами для различных групп пользователей. ** Загрузка и обновление новых версий <tt>kubernetes</tt> с регистратора <tt>registry.altlinux.org</tt>, их архивирование, подпись и размещение их на локальном регистраторе. <tt>podsec-k8s-rbac</tt>: *** Создание удалённых рабочих мест с генерацией сертификатов для доступа к <tt>rootfull</tt> или <tt>rootless</tt> <tt>kubernetes</tt> кластеру. *** Создание привязки (<tt>bind</tt>) пользователя к обычной или кластерной роли. ** Просмотр списка связанных с пользователем ролей. ** Удаление привязки (<tt>bind</tt>) пользователя к обычной или кластерной роли <tt>podsec-inotify</tt>: ** Автоматический мониторинг политик безопасности на узлах кластера и рабочих местах пользователей. ** Контроль несанкционированного доступа к <tt>API</tt> <tt>kubernetes</tt> кластера. ** Мониторинг docker-образов узла сканером безопасности <tt>trivy</tt>. === Ссылки === * [https://github.com/alt-cloud/podsec PODSEC (Podman Security)]. * [https://www.altlinux.org/Rootless_kubernetes Rootless kubernetes] * Kubernetes — https://www.altlinux.org/Kubernetes. * [https://github.com/rootless-containers/usernetes Usernetes: Kubernetes without the root privileges]. * [https://github.com/rootless-containers/slirp4netns User-mode networking for unprivileged network namespaces]. {{----}} [[File:{{#setmainimage:Реализация rootless kubernetes в рамках ALTLinux-пакетов (Александр Степченко, OSSDEVCONF-2023)!.jpg}}|center|640px]] {{LinksSection}} <!-- <blockquote>[©]</blockquote> --> <references/> [[Категория:OSSDEVCONF-2023]] [[Категория:Open-source projects]] [[Категория:Draft]] |
Текущая версия на 05:32, 2 апреля 2024
- Докладчик
- Александр Степченко
Рассматриваются вопросы одной из первых реализаций rootless kubernetes в рамках ALTLinux-пакетов защиты контейнерных решений podsec (Podman Security).
- Сравнение rootless и rootfull-решения.
- Особенности реализации rootless-решения.
- Механизмы защиты от несанкционированного доступа и использования уязвимостей
Содержание
- 1 Видео
- 2 Презентация
- 3 Thesis
- 3.1 Базовое решение Usernetes
- 3.2 Стандартная схема разворачивания rootfull kubernetes кластера через команду kubeadm
- 3.3 Разворачивание rootless-кластера через команду kubeadm
- 3.4 Разворачивание Master(ControlPlane) rootless -узла
- 3.5 Подключение дополнительных ControlPlane и Worker-узлов
- 3.6 Группа пакетов podsec (Podman Security)
- 3.7 Ссылки
- 4 Примечания и ссылки
Видео
Презентация
Thesis
Базовое решение Usernetes
Реализация rootless kubernetes была сделана на основе проекта Usernetes.
Отличие данного решения от стандартного rootfull-решения:
- Основные программы (kube-apiserver, kube-controller, kube-scheduler, kube-proxy, coredns, etcd, …) запускаются в виде сервисов, а не в виде контейнеров.
- Сертификаты генерируются сторонней программой (cfssl) и помещаются в тома, доступные узлам кластера.
Достоинства данного решения:
- Позволяет разворачивать rootless kubernetes в одноузловом или кластерном варианте.
- Обеспечивает быстрое тестирование решения путём разворачивания rootless kubernetes в виде стека сервисов (docker- compose) в рамках одного сервера.
В то же время это решение носит экспериментальный характер, что предопределило следующие недостатки:
- Генерация сертификатов производится программой cfssl, отсутствующей в репозитории пакетов ALTLinux.
- Для создания и доступа к сертификатам необходимо использовать либо docker-тома, либо разделяемую файловую систему.
- Решение создаётся без использования стандартной команды разворачивания кластера kubeadm, что ограничивает варианты разворачивания решения в виде кластера.
- Решение поднимается либо в виде стека сервисов (docker- compose) в рамках одного сервера, либо требует создание разделяемого тома в рамках кластера для доступа к сертификатам.
- Процедуры добавления, удаления узлов в кластер, обновления сертификатов нестандартные и требуют дополнительной квалификации от системного администратора.
- Реализация основных компонент кластера в виде сервисов, а не в виде контейнеров (POD’ов) несёт потенциальные риски при обновлении версий kubernetes, так как требует анализа возможных изменений в образах новых версий kubernetes.
Стандартная схема разворачивания rootfull kubernetes кластера через команду kubeadm
Для снятия основных недостатков необходимо было реализовать на основе Usernetes вариант разворачивания rootless kubernetes-кластера через стандартную программу kubernetes — kubeadm.
Процесс разворачивания rootfull-кластера через kubeadm выглядит следующим образом:
При запуске на начальном (Init) Master(ControlPlane) узле kubeadm init производит следующие основные действия:
- загружает с регистратора все необходимые (kube-apiserver, kube-controller, kube-scheduler, kube-proxy, coredns, etcd, …) kubernetes-образы;
- запускает через systemctl start kubelet сервис kubelet;
- генерирует сертификаты и kubernet-манифесты в каталоге /etc/kubernetes/manifests/;
- поднимает через kubelet основные контейнеры (POD’ы);
- конфигурирует одноузловой кластер и записывает его конфигурацию в etcd;
- генерирует строки подключения (kubeadm join ...) к кластеру ControlPlane и Worker узлов.
Для подключения дополнительных узлов на них запускается команда kubeadm join с указанными параметрами.
Разворачивание rootless-кластера через команду kubeadm
Реализованный в рамках ALTLinux пакет podsec-k8s\footnote{[1]} — это набор скриптов, который позволяет разворачивать rootless-кластер стандартной немодифицированной бинарной командой kubeadm.
Все разворачиваемые процессы в rootless kubernetes кластере запускаются в user namespace системного пользователя u7s-admin, обладающего обычными (непривилегированными) правами. Таким образом, все POD’ы имеют права обычного непривилегированного пользователя и не могут при взломе повлиять на функционирование узла.
Разворачивание Master(ControlPlane) rootless -узла
Скрипты пакета podsec-k8s находятся в каталоге /usr/libexec/podsec/u7s/bin.
Часть из них (kubeadm, systemctl) являются оболочками над стандартными командами системы с аналогичным именем. За счёт установки переменной PATH
export PATH=/usr/libexec/podsec/u7s/bin/:$PATH
они вызываются до вызова основных системных команд kubeadm и systemctl, и после выполнения настройки среды вызывают основные системные команды.
При запуске на начальном (Init) Master(ControlPlane) узле скрипт kubeadm init производит следующие основные действия:
- В окружении пользователя u7s-admin запускает сервис rootlesskit, который позволяет запускать процессы с правами «псевдоroot». Процессы в рамках user namespace пользователя u7s-admin имеют права root (UID=0), могут создавать сетевые интерфейсы, настраивать правила маршрутизации iptables и выполнять другие системные действия. Но в рамках HOST-системы все производимые действия изолируются в user namespace пользователя u7s-admin и никак не взаимосвязаны с системными ресурсами HOST-системы. В процессе rootlesskit в рамках user namespace пользователя u7s-admin запускаются:
- подпроцесс crio, обеспечивающий работу с контейнерами;
- подпроцесс slirp4net, обеспечивающий создание сетевых интерфейсов и работу с ними.
- В рамках user namespace пользователя u7s-admin запускается стандартная бинарная команда kubeadm.
- В рамках этого namespace команда kubeadm имеет права псевдо- root:
- Загружает с регистратора все необходимые (kube-apiserver, kube-controller, kube-scheduler, kube-proxy, coredns, etcd, …) kubernetes-образы.
- Запускает через systemctl start kubelet сервис kubelet.
- Генерирует сертификаты и kubernet-манифесты в каталоге /etc/kubernetes/manifests/.
- Поднимает через kubelet основные контейнеры (POD’ы).
- Конфигурирует одноузловой кластер и записывает его конфигурацию в etcd.
- Генерирует строки подключения (kubeadm join ...) к кластеру ControlPlane и Worker-узлов.
- Производит настройку интерфейсов и правил iptables в HOST-системе и user namespace пользователя u7s-admin
- Производит настройку файлов конфигурации (.kube/config) пользователе root и u7s-admin.
Таким образом, при запуске скрипта kubeadm пакета podsec-k8s производится полноценная настройка Master (ControlPlane) узла rootless кластера.
Подключение дополнительных ControlPlane и Worker-узлов
Подключение дополнительных ControlPlane и Worker узлов производится аналогичным образом:
- Устанавливается пакет podsec-k8s.
- Устанавливается переменная среды PATH:
- Запускается скрипт ‘kubeadm’ пакета podsec-k8s в режиме kubeadm join ... с параметрами, сгенерированными при установке начального Master (ControlPlane) узла.
Группа пакетов podsec (Podman Security)
Пакет podsec-k8s входит в состав группы пакетов:
- podsec
- Разворачивание локального регистратора (regitry.local) и сервера подписей (sigstore.local).
- Создание пользователей группы podsec-dev, имеющих права на создание docker-образов, их подписывание и размещение в локальном регистраторе.
- Создание пользователей группы podsec, имеющих возможность запуска подписанных образов с локального регистратора. Работа с образами из других источников не допускается.
- Настройка политик доступа и работы с образами для различных групп пользователей.
- Загрузка и обновление новых версий kubernetes с регистратора registry.altlinux.org, их архивирование, подпись и размещение их на локальном регистраторе. podsec-k8s-rbac:
- Создание удалённых рабочих мест с генерацией сертификатов для доступа к rootfull или rootless kubernetes кластеру.
- Создание привязки (bind) пользователя к обычной или кластерной роли.
- Просмотр списка связанных с пользователем ролей.
- Удаление привязки (bind) пользователя к обычной или кластерной роли podsec-inotify:
- Автоматический мониторинг политик безопасности на узлах кластера и рабочих местах пользователей.
- Контроль несанкционированного доступа к API kubernetes кластера.
- Мониторинг docker-образов узла сканером безопасности trivy.
Ссылки
- PODSEC (Podman Security).
- Rootless kubernetes
- Kubernetes — https://www.altlinux.org/Kubernetes.
- Usernetes: Kubernetes without the root privileges.
- User-mode networking for unprivileged network namespaces.