Kubernetes 1.22: Ingress в GA и прощание с PodSecurityPolicy

Kubernetes 1.22 вышел с двумя новостями, которые стоят рядом только в changelog - по смыслу они про разное. Ingress наконец получил статус GA после нескольких лет в beta - это хорошая новость без немедленных последствий. А PodSecurityPolicy объявлена deprecated - это тихая новость с конкретными последствиями прямо сейчас для тех, кто PSP реально использует.

Мы в нескольких кластерах использовали PSP. После обновления до 1.22 это дало о себе знать.

Ingress GA: коротко о хорошем

То, что Ingress доделали до stable, - это в первую очередь сигнал о стабильности API. Группа networking.k8s.io/v1 для Ingress теперь основная, старая extensions/v1beta1 и networking.k8s.io/v1beta1 - deprecated ещё с 1.19 - в 1.22 окончательно удалены. Если кто-то тянул с обновлением манифестов, откладывать больше некуда.

Практически для нас это обновление манифестов и значение ingressClassName вместо аннотации kubernetes.io/ingress.class. Большинство проектов мы перевели ещё в прошлом году, оставалось несколько старых. Обновили до апгрейда - иначе Ingress-ресурсы просто перестают существовать с точки зрения API.

# Старый вариант - больше не работает в 1.22
apiVersion: networking.k8s.io/v1beta1
kind: Ingress

# Новый вариант
apiVersion: networking.k8s.io/v1
kind: Ingress
spec:
  ingressClassName: nginx

Helm-чарты популярных контроллеров (nginx-ingress, traefik) уже давно генерируют правильный API - если чарт свежий, изменений в манифестах не требуется.

PodSecurityPolicy: что сломалось и почему

PSP - механизм, который ограничивает что pod может делать на уровне хоста: монтировать hostPath, запускаться от root, использовать privileged-контейнеры. Концепция правильная, реализация - исторически запутанная. Авторизация через RBAC, неочевидное поведение при отсутствии политики, разные эффекты в зависимости от того, кто делает запрос - serviceaccount, пользователь или node. Команды либо разбирались в этом досконально, либо создавали permissive-политику «лишь бы работало» и забывали.

В 1.22 PSP deprecated - это значит, что admission controller ещё работает, но в 1.25 (по текущим планам) его уберут. Deprecation без immediate removal - казалось бы, можно не торопиться. Но у нас получилось иначе.

Проблема первая - admission webhook. В одном из кластеров параллельно с PSP работал сторонний policy webhook. После обновления до 1.22 и рестарта компонентов несколько подов зависли в статусе Pending - webhook конфликтовал с изменившимся поведением PSP-контроллера при обработке ServiceAccount. Потребовалось разобраться что именно сломано: симптом был одинаковый, причины разные.

Проблема вторая - system-компоненты. В другом кластере PSP использовались в том числе для системных компонентов: корневая PSP с широкими правами была привязана к kube-system. После апгрейда обнаружилось, что несколько DaemonSet-ов из add-on-ов не поднимаются - они не попадали под нужную PSP из-за изменившейся логики приоритетов при выборе политики. Диагностика через события была информативной: unable to validate against any pod security policy.

Что такое Pod Security Standards

На замену PSP приходит Pod Security Admission (PSA) - admission controller, встроенный в 1.22 как alpha. Вместо гибкой (читай: запутанной) системы политик - три готовых профиля:

• privileged - без ограничений, для системных компонентов.
• baseline - базовые ограничения, запрещает очевидно опасные конфигурации: privileged-контейнеры, hostPID/hostNetwork, опасные capabilities.
• restricted - строгий профиль: запуск от root запрещён, seccomp обязателен, capabilities минимальны.

Профиль применяется на уровне namespace через лейбл:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

Три режима на выбор: enforce - отклоняет pod, warn - пропускает с предупреждением в ответе, audit - пишет в audit log. Это удобно при миграции: сначала поставить warn и смотреть что нарушает профиль, потом переключить на enforce.

Как мы мигрируем

В 1.22 PSA - alpha, включается флагом. Но это не значит, что надо ждать stable. Миграцию с PSP разумно начинать уже сейчас - оставшееся время до 1.25 выглядит достаточным, но PSP-конфигурации имеют свойство быть сложнее, чем кажется.

Наша схема:

Первое - инвентаризация PSP. Собрать все существующие политики, понять какие namespace-ы и ServiceAccount-ы к ним привязаны. kubectl get psp даёт список, но важна матрица «кто использует какую политику» - её придётся строить через RBAC.

Второе - аудит через warn. Включить PSA в режиме warn для всех namespace-ов и пропускать реальные деплои. Предупреждения агрегируются и дают точный список нарушений под каждый профиль.

Третье - фикс рабочих нагрузок. Большинство нарушений restricted в наших кластерах - это контейнеры без явного securityContext, запускающиеся от root по умолчанию. Добавить runAsNonRoot: true и allowPrivilegeEscalation: false в большинстве случаев достаточно.

Четвёртое - system-компоненты отдельно. Для kube-system и namespace-ов с privileged-рабочими нагрузками (мониторинг, сеть) - профиль privileged. Не потому что там можно всё, а потому что у PSA нет механизма тонкой настройки внутри профиля. Если нужна тонкая настройка - придётся дополнять сторонними инструментами вроде OPA/Gatekeeper или Kyverno.

Что в итоге

Deprecation PSP - это не катастрофа, но и не «починим потом». У нас в двух кластерах обновление до 1.22 спровоцировало реальные инциденты с недоступностью подов - не из-за самого deprecation, а из-за взаимодействия PSP с другими компонентами при апгрейде. Если PSP используется не формально, а реально настроена и задействована - тестировать апгрейд в staging нужно обязательно.

Pod Security Standards концептуально проще PSP. Три профиля вместо произвольных политик - это потеря гибкости, но выигрыш в понимаемости. Что именно настроено, почему и что это означает - с PSA объяснить команде значительно легче.

Кластеры переведём на PSA постепенно, параллельно убирая PSP. Работа не на один день, но лучше начать сейчас, чем разгребать в спешке когда придёт 1.25.