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

Короткая ссылка: 20230929F

Докладчик: Александр Степченко

Рассматриваются вопросы одной из первых реализаций rootless kubernetes в рамках ALTLinux-пакетов защиты контейнерных решений podsec (Podman Security).

Сравнение rootless и rootfull-решения.

Особенности реализации rootless-решения.

Механизмы защиты от несанкционированного доступа и использования уязвимостей

Видео

on youtube

Презентация

Thesis

https://github.com/alt-cloud/podsec

Базовое решение 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 выглядит следующим образом:

Схема инициализации rootfull master сервера

При запуске на начальном (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, и после выполнения настройки среды вызывают основные системные команды.

Схема инициализации rootless master сервера

При запуске на начальном (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.

Ссылки

Примечания и ссылки