SELinux-разметка томов в Kubernetes: как подготовиться к изменениям в v1.37

Если ваш кластер работает на Linux с включённым SELinux в принудительном режиме, вас ждут перемены: в одном из будущих релизов, предположительно в v1.37, функция SELinuxMount станет включённой по умолчанию. Это нововведение ускорит настройку томов для большинства рабочих нагрузок, но может незаметно нарушить работу приложений, которые до сих пор полагаются на старую модель рекурсивной переразметки. Особенно это касается ситуаций, когда один и тот же том используют одновременно привилегированные и непривилегированные поды на одном узле. Версия Kubernetes v1.36 — идеальный момент, чтобы провести аудит вашего кластера и либо адаптироваться к изменениям, либо отказаться от них. Если ваши узлы не используют SELinux, для вас ничего не меняется: kubelet пропускает всю логику SELinux, когда SELinux недоступен или отключён в ядре. В таком случае вы можете смело пропустить эту статью.

Этот материал развивает более раннюю работу, описанную в статье Kubernetes 1.27: Efficient SELinux Relabeling (Beta), где был представлен функциональный бета-флаг SELinuxMountReadWriteOncePod. Проблема, которую предстоит решить, остаётся той же, однако теперь этот подход расширяется на все типы томов.

Что меняется в Kubernetes с SELinuxMount

Linux-системы с включённым SELinux используют метки, прикреплённые к объектам (например, к файлам и сетевым сокетам), для принятия решений о контроле доступа. Исторически контейнерная среда выполнения применяет метки SELinux к поду и всем его томам. Kubernetes лишь передаёт метку SELinux из полей securityContext пода в контейнерную среду выполнения. Затем среда выполнения рекурсивно изменяет метку SELinux на всех файлах, видимых контейнерам пода. Это может занимать много времени, если на томе много файлов, особенно когда том находится в удалённой файловой системе.

Важно понимать: если контейнер использует subPath тома, переразметке подвергается только этот subPath. Это позволяет двум подам с разными метками SELinux использовать один том, если они используют разные subPath. Если поду не назначена метка SELinux в API Kubernetes, среда выполнения назначает уникальную случайную метку, поэтому процесс, работающий в поде, не сможет получить доступ к файлам с другой меткой.

Новая функция SELinuxMount кардинально меняет подход: вместо рекурсивной переразметки всех файлов при каждом монтировании, kubelet будет монтировать том с уже корректной меткой SELinux, применяя её на уровне файловой системы. Это устраняет необходимость в дорогостоящей рекурсивной операции и значительно ускоряет запуск подов, особенно при работе с большими томами или удалёнными хранилищами. Однако это также означает, что если приложение или инфраструктура полагались на то, что все файлы на томе будут переразмечены с меткой пода, такое поведение изменится.

Предыстория и контекст

Проблема эффективной переразметки SELinux не нова. Ещё в Kubernetes 1.27 была представлена бета-версия функции SELinuxMountReadWriteOncePod, которая позволяла оптимизировать работу только с томами ReadWriteOncePod. Теперь команда Kubernetes расширяет этот подход на все типы томов, что логично, учитывая накопленный опыт и обратную связь от сообщества.

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

Однако у такого изменения есть и обратная сторона. Старая модель переразметки была «прощающей»: даже если под и том имели разные метки, среда выполнения приводила их в соответствие. Новая модель требует, чтобы метка была правильной с самого начала. Это может вызвать проблемы в сценариях, где один том используется несколькими подами с разными метками, или где приложения сами управляют метками файлов.

Как это работает и чем отличается от предыдущей версии

В старой модели контейнерная среда выполнения (например, containerd или CRI-O) при запуске пода рекурсивно меняла метки SELinux на всех файлах, к которым под имеет доступ. Это гарантировало, что под сможет читать и записывать файлы, но требовало значительных вычислительных ресурсов.

В новой модели kubelet заранее вычисляет правильную метку SELinux для тома и передаёт её среде выполнения, которая монтирует том с этой меткой. При этом не требуется переразметка файлов — они уже имеют правильную метку. Это работает только в том случае, если все файлы на томе имеют одинаковую метку, что обычно верно для томов, созданных Kubernetes.

Однако есть важное исключение: если том используется несколькими подами с разными метками SELinux (например, один под привилегированный, другой нет), то новая модель не сможет обеспечить корректный доступ для обоих. В этом случае необходимо либо использовать subPath, чтобы каждый под имел свою область, либо отказаться от SELinuxMount для этого тома.

Технические подробности и последствия для кластеров

Для администраторов кластеров важно понимать, как включить или отключить эту функцию. Флаг SELinuxMount управляется через функциональный шлюз (feature gate) в kubelet. В v1.36 он всё ещё находится в статусе beta, но по умолчанию может быть включён для некоторых конфигураций. Начиная с v1.37, ожидается, что он будет включён по умолчанию для всех.

Чтобы проверить, включена ли функция, можно выполнить команду kubectl describe node и посмотреть на наличие метки selinux-mount в аннотациях. Если функция включена, kubelet будет использовать новый механизм. Если вы хотите отключить её, можно добавить флаг --feature-gates=SELinuxMount=false в конфигурацию kubelet.

Однако просто отключить функцию недостаточно — нужно убедиться, что ваши приложения не зависят от старого поведения. Рекомендуется провести аудит всех подов, которые используют тома, и проверить, не используют ли они один том с разными метками SELinux. Если такие случаи есть, их нужно либо переработать на subPath, либо настроить отдельные тома.

Кого затронет изменение

Изменение затронет прежде всего администраторов Kubernetes-кластеров, работающих на узлах с SELinux в принудительном режиме. Разработчики приложений также должны быть готовы к тому, что их приложения могут столкнуться с проблемами доступа к файлам, если они полагались на автоматическую переразметку.

Для пользователей в России и СНГ, где SELinux часто используется в корпоративных средах, это особенно актуально. Многие организации используют SELinux для усиления безопасности, и переход на новую модель потребует внимания со стороны DevOps-инженеров. Важно заранее протестировать свои приложения на тестовом кластере с включённой функцией, чтобы выявить потенциальные проблемы.

Что будет дальше

Ожидается, что в v1.37 функция SELinuxMount станет стабильной и будет включена по умолчанию. Команда Kubernetes рекомендует всем пользователям SELinux начать тестирование уже сейчас, в v1.36, чтобы успеть адаптироваться. В последующих релизах, вероятно, будет удалена поддержка старой модели переразметки, поэтому чем раньше вы перейдёте на новую модель, тем плавнее пройдёт переход.

Также стоит следить за обновлениями документации и списками рассылки, где могут появляться дополнительные рекомендации по миграции. Если вы столкнётесь с проблемами, не стесняйтесь сообщать о них в Kubernetes SIG-Storage, так как обратная связь помогает улучшить реализацию.

Итог

SELinuxMount — это важное улучшение, которое делает Kubernetes быстрее и эффективнее, но требует осознанного подхода к миграции. Администраторам стоит уже сейчас провести аудит своих кластеров, проверить совместимость приложений и при необходимости скорректировать конфигурацию. Включение функции по умолчанию в v1.37 — не повод для паники, а повод действовать заранее, чтобы избежать сюрпризов при обновлении. Следите за обновлениями Kubernetes и тестируйте новые функции в своих средах — это залог стабильной работы ваших приложений.