Kubernetes безопасность подов: внедрение Pod Security Standards

Pod Security Standards: почему поды получают лишние права

Типовая картина в кластере, которому больше года: в манифестах стоит privileged: true или hostNetwork: true, контейнер запущен от root, а hostPath монтирует каталог узла. Никто не писал это злым умыслом — манифест скопировали из чужого примера, чтобы «просто заработало», и дописали лишнюю возможность ядра по совету с форума. Дальше файл живёт в репозитории и разворачивается при каждом релизе, пока кто-нибудь его не заметит.

Почему такое не ловится: по умолчанию ничего не ограничивает. API-сервер Kubernetes принимает любой securityContext, если в кластере не настроены контроллеры допуска, а право создавать поды в пространстве имён выдано почти каждому сервисному аккаунту. Pod Security Standards существуют как набор профилей, но пока их не включили на конкретное пространство имён, они остаются описанием желаемого, а не проверкой при развёртывании.

Цена избыточных прав контейнеров конкретна. Привилегированный под видит устройства узла и обходит изоляцию ядра — компромисс одного контейнера становится компромиссом всего узла. Запуск от root вместе с монтированием каталога узла или сокета среды исполнения открывает путь к соседним подам, а hostNetwork — к сетевым метаданным облака. Уязвимости среднего уровня превращаются в критические.

Обратная сторона: жёсткие профили ломают легитимные рабочие нагрузки — сборщики метрик, сетевые агенты, драйверы хранилищ. Поэтому вопрос не «запретить всё», а «как выдать ровно необходимые права и не сломать выпуск». Разбираем, как это закрывается.

Что даёт управляемый контур безопасности подов в кластере

До внедрения политик доля привилегированных рабочих нагрузок измеряется единицами процентов — и почти всегда это исключения, о которых забыли. После включения Pod Security Standards в режиме ограничения такие контейнеры не проходят создание, и доля привилегированных подов падает до нуля без ручного разбора каждого манифеста.

• Доля привилегированных подов — ноль по умолчанию; исключение оформляется явно и с областью действия, а не на весь кластер.
• Ограничение привилегий: запуск от непривилегированного пользователя, корневая файловая система только для чтения, запрет повышения прав.
• Снижение поверхности атаки: из манифестов уходят хостовые пути, сеть узла и лишние возможности ядра — самый частый путь выхода за границы пода закрыт.
• Время проверки нового сценария развёртывания — минуты: политика отказывает на применении манифеста, а не через сутки по инциденту в проде.
• Аудит манифестов даёт журнал нарушений и предупреждения: видно, какие команды и сервисы ещё не приведены к профилю.
• Ушедший класс отказов: побег из контейнера, чтение секретов из общей точки монтирования, неявные права на узле.

Эти замеры стоит снимать не разово: политика привязана к пространству имён, манифесты проверяются до выката, а исключения живут с датой пересмотра. Тогда профиль остаётся рабочим инструментом, а не документом, который обходят.

Сравнение режимов Pod Security: baseline и restricted

В Pod Security Standards три уровня политик, и выбор между ними — это выбор класса нагрузки, а не принцип «строже значит лучше». Уровень privileged не накладывает ограничений: под получает доступ к хостовым ресурсам, поэтому его оставляют только системным подам — сетевым драйверам, агентам мониторинга узла. baseline закрывает очевидно опасное: хостовые сетевые пространства и процессы, запуск от root, лишние capability. restricted добавляет требования к профилю seccomp, корневой файловой системе только для чтения, запуску от непривилегированного пользователя и явному сбросу всех capability.

Включать уровни сразу в принудительном режиме рискованно: режим предупреждения возвращает список нарушений в ответе API-сервера и пишет их в журнал аудита, не блокируя запуск. Команда видит реальный профиль нагрузки, правит манифесты и лишь затем переводит пространство имён в принудительный режим — сначала на новых сервисах, потом на остальных.

Как мы внедряем политики: аудит, схема, проверка, передача

Внедрение Pod Security Standards — это не одна метка на пространство имён. Политики вскрывают то, что годами копилось в манифестах: привилегированные контейнеры, hostPath, hostNetwork, запуск от root, лишние capabilities. Поэтому идём от инвентаризации к мягкому режиму и только затем к блокировке, с обратным путём на каждом шаге.

1. Аудит кластера и инвентаризация манифестов. Собираем рабочие нагрузки по пространствам имён, включая CronJob, DaemonSet и операторы, и фиксируем по каждой пользователя, привилегии и монтирования. Результат — таблица «нагрузка → нарушаемые правила», а не общий поток предупреждений.
2. Схема перевода. Раскладываем нагрузки по трём профилям — ограниченный, базовый, привилегированный — и решаем, какие пространства имён получат блокирующий режим сразу, а какие пойдут через мягкий.
3. Включение в мягком режиме. Проставляем метки аудита и предупреждений: контроллер ничего не блокирует, но каждое нарушение попадает в события и лог. Несколько дней режима показывают реальный объём правок без риска для боевого контура.
4. Проверка конфигураций. Переписываем манифесты под нужный профиль: снимаем лишние capabilities, убираем hostPath в пользу томов, задаём runAsNonRoot и seccomp. Правки проходят ревью и прогон в тестовом контуре.
5. Перевод нагрузки. Блокировку включаем по пространствам имён — от менее критичных к боевым, с наблюдением за отказами и быстрым откатом метки.
6. Передача регламентов. Отдаём политики как код в репозитории, правила для новых сервисов, чек-лист ревью манифестов и порядок исключений.

Артефакты внедрения: политики доступа, роли и регламенты

Команда заказчика получает не набор разовых команд, а рабочий комплект, по которому можно дежурить и менять политики без нас. Ниже — что именно остаётся в репозитории и во внутренней базе знаний после внедрения Pod Security Standards.

• Конфигурации кластера: манифесты пространств имён с метками pod-security.kubernetes.io/enforce, audit и warn, выбранные уровни baseline или restricted, отдельный перечень исключений для системных пространств имён.
• Матрица ролей: таблица «пространство имён — уровень политики — кто вправе выводить нагрузку из-под неё», с привязкой к ролям доступа и разделением права менять политику и права на релиз.
• Схемы размещения нагрузки: какие рабочие нагрузки живут в строгом профиле, а где нужны привилегии — с указанием причины и владельца, а не пометкой «разберёмся позже».
• Регламенты безопасности: порядок выпуска политики — сначала режимы аудита и предупреждения на живом трафике, затем включение принудительного режима по заранее согласованному критерию по числу нарушений в журнале.
• Инструкции для дежурной смены: что делать, когда под не создаётся из-за политики — как читать сообщение контроллера допуска, где искать исключение, как откатить изменение, не снимая весь режим целиком.
• Документация для разработчиков: эталонный манифест с обязательными полями — запуск не от суперпользователя, профиль seccomp, корневая файловая система только для чтения, сброшенные возможности.

Каждый пункт проверен на стенде заказчика и привязан к конкретному пространству имён, поэтому новый инженер входит в работу по документу, а не по памяти коллеги.

Кейс: как убрали привилегированные поды без простоя сервисов

Исходная точка

Кластер на несколько десятков команд: 46 namespace, из них 11 с привилегированными подами — сетевой агент, сбор логов, драйверы узлов. Аудит Kubernetes показывал, что 88% контейнеров запускались без профиля seccomp, а шесть из десяти рабочих нагрузок имели allowPrivilegeEscalation: true. Общей политики не было: каждый namespace жил по своим правилам, и любой сервис мог получить монтирование каталога узла.

Порядок перевода

Начали с режимов warn и audit на всех namespace — за неделю собрали отчёт по нарушениям и разложили их на три группы: правка манифестов, замена образов, системные исключения. Дальше включали enforce волнами: сначала stateless-сервисы, затем stateful-наборы с постоянными томами, последними — агенты на каждом узле, которые нельзя прервать без потери самого узла. Системные нагрузки вынесли в отдельные namespace с уровнем baseline и узким списком разрешений по именам. Простоя не было: обновление шло через постепенную замену реплик с проверкой готовности, а не через перезапуск всего набора.

Результат

Практический итог через два релизных цикла: привилегированных подов в рабочих namespace — ноль, доля контейнеров без seccomp упала с 88% до 4%. Отказов на этапе допуска при выкатке — ноль после первых двух недель, когда команды привыкли к новым требованиям. Запуск от root и монтирование каталогов узла закрыты, а новый сервис по умолчанию получает профиль restricted и не требует отдельных согласований с безопасностью.

Что делать, если в кластере уже развёрнуты привилегированные поды?

Политика безопасности подов проектировалась под чистый кластер, где манифесты изначально пишут под строгий профиль. На кластере с наследственной нагрузкой — старые операторы, вендорные агенты, сборщики метрик — прямое включение строгого профиля выбивает работающие сервисы. Поэтому первый шаг не запрет, а режимы проверки без блокировки: контроллер пропускает всё, но фиксирует, какие поды и по каким правилам расходятся с политикой.

За несколько дней такой прогон даёт точный список нарушителей и их владельцев — без единой аварии. Дальше политика включается не везде сразу, а по пространствам имён: метка с нужным профилем ставится на те, чьи манифесты уже готовы. Отступления оформляются как исключения внутри самой политики, а не как отключение профиля целиком.

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

Нагрузку, которую починить нельзя — вендорный образ, требующий привилегий или доступа к устройствам, — выносим в отдельное пространство имён с ослабленным профилем и держим там до замены компонента. Это видимая, управляемая зона отступления, а не дыра в политике на всём кластере.

Срок жизни отступления — главное. Исключение без даты пересмотра становится постоянным, и через полгода строгая политика существует только на бумаге. Мы ведём реестр исключений и на каждом цикле показываем, сколько их, какие истекли и что мешает закрыть остальные. Тогда строгий профиль остаётся правилом по умолчанию, а отступления — точечными и заметными.

Технические сомнения инженерных команд: риски и совместимость

Перед включением почти каждая команда задаёт один и тот же набор вопросов: не погаснет ли прод, что делать с системными компонентами и есть ли путь назад. Ниже — ответы, которые мы даём на старте, и порядок действий, снимающий основные риски внедрения.

Как быть с системными компонентами кластера?

Плагины сети и хранилища, сбор логов, мониторинг и контроллеры входа требуют привилегий или доступа к узлу. Для их пространств имён задаём явные исключения и отдельный уровень вместо отключения политики целиком — остальной кластер остаётся под строгим профилем.

Что чаще всего не проходит проверку в приложениях?

Привилегированные контейнеры, монтирование каталогов узла, запуск от root, запись в корневую файловую систему, лишние возможности ядра. Часть закрывается правкой контекста безопасности в манифесте, часть — пересборкой образа под непривилегированного пользователя.

Возможен ли откат изменений?

Да: уровень задаётся меткой на пространстве имён, и снятие метки возвращает прежнее поведение за секунды, без пересборки кластера. Оговорка — откат не восстанавливает поды, отклонённые принуждением, поэтому переводим пространства имён по одному, с наблюдением на каждом шаге.

Обсудим задачу: подберём режим и план перехода

Чтобы подобрать режим Pod Security Standards и собрать схему внедрения, достаточно вводного среза по кластеру: число пространств имён, уже проставленные метки, наличие привилегированных рабочих нагрузок. Этого хватает, чтобы дать оценку работ по этапам, а не считать вслепую.

Что нужно от вас:

• перечень пространств имён с владельцами и порядком выкатки;
• срез текущих манифестов либо доступ к конфигурации только на чтение;
• список нагрузок, которым нужны привилегии, хостовые порты или тома — с обоснованием;
• окно, когда можно включить аудит и смотреть предупреждения без влияния на прод;
• контакт дежурного инженера на время перевода и сведения о тестовом контуре.

Что отдаём взамен:

• схему внедрения: какой уровень политик ставим на какое пространство имён и где допускаем исключения;
• план перехода — сначала аудит, затем предупреждения, потом принудительное применение, с точкой отката на каждом шаге;
• оценку работ по этапам с пометкой, что идёт параллельно, а что требует окна;
• исключения отдельными ролями с ограничением по области действия и сроку жизни;
• регламент разбора срабатываний и памятку для команд разработки.

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