Как SPO v1 упрощает управление seccomp, SELinux и AppArmor в Kubernetes

Профили безопасности в Linux давно стали обязательной частью защиты контейнеров. Seccomp ограничивает системные вызовы процесса, SELinux и AppArmor задают политики доступа к файлам, сети и возможностям ядра. В Kubernetes эти механизмы особенно полезны, потому что одна ошибка в workload может дать атакующему слишком широкую поверхность внутри узла.

Security Profiles Operator решает практическую задачу: профили можно описывать, записывать, распространять и привязывать к pod’ам через Kubernetes API. С выпуском v1.0.0 проект закрепил стабильную API-поверхность для восьми CRD, прошёл сторонний аудит безопасности и подготовил миграцию, при которой старые манифесты продолжают работать через конвертирующие вебхуки.

Что изменилось в API

SPO начал развитие как оператор для seccomp, затем получил поддержку SELinux, AppArmor, запись профилей через audit logs и eBPF, распространение профилей через OCI-артефакты и дополнительные механизмы для работы с Kubernetes workload’ами. Из-за такого роста разные CRD долго жили в alpha и beta-версиях, хотя отдельные ресурсы фактически использовались в production годами.

В v1.0.0 команда провела чистку API перед фиксацией стабильных контрактов. Все CRD теперь используют единый подход к статусу через conditions, привычный для Kubernetes. Спецификация SPOD стала более структурированной: крупный плоский набор полей разложен по логическим секциям для SELinux, enricher, webhook, scheduling и security. Общие базовые типы вынесены отдельно, чтобы сократить дублирование между ресурсами.

Часть изменений касается совместимости с Kubernetes API conventions. Беззнаковые целые типы заменены на знаковые, внешние типы с лишними import-зависимостями перенесены внутрь проекта, enum-значения приведены к PascalCase. Например, logs превращается в Logs, а RUNNING — в Running. Для полей добавлены маркеры +optional и +required, а также валидация на уровне CRD. Исключение оставлено для seccomp-констант SCMP_ACT_* и SCMP_CMP_*: они сохраняют верхний регистр ради соответствия OCI runtime specification и заголовкам ядра Linux.

Для администраторов это важное изменение: API получает предсказуемый контракт, на который можно опираться в GitOps, Helm-чартах, внутренних платформах и policy-шаблонах. Когда ресурс выходит в v1, его сложнее менять произвольно, значит инфраструктурный код меньше зависит от поведения конкретной версии оператора.

Аудит показал самые рискованные границы

Перед стабильным релизом код прошёл внешний security audit. Критических уязвимостей найдено не было. Проверка подтвердила несколько важных свойств: пути к файлам на хосте формируются из метаданных объекта, команды собираются массивами аргументов без shell-инъекций, а стандартные RBAC-настройки не выдают лишние права пользователям без административных полномочий.

При этом аудит подсветил зоны, где пользовательский Kubernetes-ресурс превращается в состояние модулей безопасности ядра. Именно такая граница требует максимальной осторожности: ошибка в admission, validation или reconciliation может привести к загрузке опасной политики на узел.

Самый чувствительный путь связан с RawSelinuxProfile. Этот ресурс позволяет задавать SELinux-политику на CIL, которую оператор устанавливает на node. В v1.0.0 появилась настройка enableRawSelinuxProfiles, через которую администратор может полностью отключить поддержку сырых SELinux-профилей. Admission webhook получил проверку корректности таких политик до reconciliation, поэтому невалидный профиль отклоняется раньше и понятнее.

Для обычного SelinuxProfile поле permissive заменено на enum mode со значениями Enforcing и Permissive. Такой формат явнее показывает намерение оператора кластера и снижает риск включить permissive-режим из-за неопределённого булева значения.

AppArmor тоже получил более строгую обработку входных данных. Имена профилей, пути к исполняемым файлам и capabilities теперь проходят regex-валидацию, а уже загруженные в ядро профили защищены от перезаписи через некорректный ввод. Для RawSelinuxProfile.spec.policy добавлен лимит размера 500 КБ, чтобы слишком большой документ не доходил до SELinux CIL compiler на узле.

Усиление защиты выходит за рамки формальной проверки

Релиз добавляет несколько защитных изменений, которые полезны для эксплуатации в шумных и многоарендных кластерах. В парсерах журналов seccomp, SELinux и AppArmor жадные регулярные выражения заменены на более ограниченные шаблоны. Это снижает риск чрезмерного backtracking на специально подготовленных строках audit log.

Пути к системным директориям стали жестче ограничены: HostProcVolumePath проверяется на соответствие /proc, а seccomp-ListenerPath привязан к директории сокета оператора. Такие проверки важны для компонентов, которые работают с привилегированными возможностями и файловой системой хоста.

Для eBPF-рекордера добавлены лимиты на число записываемых файлов и максимальную длину пути. Без подобных ограничений workload с активным доступом к файловой системе может создавать чрезмерную нагрузку и приводить к OOM. Кэш процессов теперь учитывает PID вместе со временем старта процесса, что защищает от устаревших попаданий после повторного использования PID ядром.

Отдельная практичная правка касается метрик. Из счётчиков Prometheus убраны неограниченные labels, чтобы избежать высокой кардинальности. Для production-кластера это заметная деталь: один удобный, но неконтролируемый label способен быстро раздуть TSDB и превратить мониторинг в источник проблем.

Миграция рассчитана на живые кластеры

Обновление до v1.0.0 задумано без ручной миграции ресурсов. Конвертирующие вебхуки принимают старые версии API, переводят их в v1 перед сохранением и умеют отдавать объекты обратно в прежнем формате, если клиент запрашивает старую версию. Это сохраняет работоспособность старых манифестов, CI-пайплайнов и GitOps-репозиториев на время перехода.

Главный пример — ProfileRecording. В старом ресурсе recorder мог задаваться как logs, а merge strategy — как none. В v1 эти значения становятся Logs и None. Конверсионный слой сопоставляет enum-значения в обе стороны, поэтому кластер может хранить ресурс в новой версии и обслуживать клиентов, которые ещё не обновили manifests или SDK.

Для команд платформенной разработки это снижает риск релиза. Можно сначала обновить оператор, убедиться в стабильной работе CRD и webhook’ов, затем постепенно привести chart’ы, kustomize overlays, Terraform-модули и внутренние Go-клиенты к новой версии API. Старые версии останутся доступными для обратной совместимости в течение переходного периода, после чего их удалят в будущих релизах.

Связь с upstream Kubernetes

SPO развивается рядом с upstream-направлением Kubernetes по профилям безопасности. Оператор уже использует GA-поверхность seccomp, появившуюся в Kubernetes 1.19, и закрывает задачи, которые kubelet сам по себе не решает: запись профилей с работающих workload’ов, структурированное описание SELinux-политик, привязку профилей к образам контейнеров и обогащение audit logs.

Важное направление — распространение профилей безопасности через OCI-артефакты. Такая модель позволяет публиковать seccomp, SELinux и AppArmor-профили в OCI registry и ссылаться на них из спецификаций workload’ов. KEP 6061 предлагает перенести похожую идею ближе к kubelet: container runtime сможет получать профиль по запросу через CRI API PullSecurityProfileArtifact.

Модель доверия похожа на localhost-профили: на уровне kubelet действует allow-list с запретом по умолчанию, а Pod Security Admission относится к OCI-профилям по тем же принципам. Даже если нативная поддержка появится в Kubernetes, SPO сохранит роль более высокого уровня управления: запись, валидация, привязки, распространение и эксплуатационные удобства останутся задачами оператора.

Что стоит проверить перед внедрением

Для homelab и небольших production-кластеров выпуск v1.0.0 выглядит как хороший момент пересмотреть подход к профилям безопасности. Минимальный план внедрения может быть таким:

обновить оператор в тестовом кластере и проверить conversion webhook’и на существующих CRD;
включить запрет RawSelinuxProfile, если сырые CIL-политики не нужны пользователям кластера;
привести манифесты к security-profiles-operator.x-k8s.io/v1 и новым enum-значениям;
проверить RBAC вокруг создания профилей и доступа к namespace’ам с workload’ами;
добавить мониторинг webhook’ов, reconciliation errors и метрик оператора;
описать правила публикации OCI-профилей, если профили распространяются через registry;
зафиксировать процесс ревью для SELinux/AppArmor/seccomp изменений в GitOps.

Главная ценность SPO v1 — в превращении профилей безопасности из набора ручных файлов на узлах в управляемый Kubernetes-контур. Стабильные CRD, строгая валидация, понятная миграция и внимание к границам ядра делают этот контур более пригодным для долгого сопровождения. Для кластеров с несколькими командами это шаг к тому, чтобы политики seccomp, SELinux и AppArmor стали частью обычного platform engineering workflow, а не редкой ручной настройкой после инцидента.