Реализация rootless kubernetes в рамках ALTLinux-пакетов (Александр Степченко, OSSDEVCONF-2023) — различия между версиями

== 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]]