Меню
Статья k8s

Безопасность Kubernetes: от PSP к Pod Security Admission

Meiirbek

• Время прочтения: 2 мин.
Безопасность Kubernetes: от PSP к Pod Security Admission

Безопасность в Kubernetes постоянно эволюционирует. Одним из самых значимых изменений за последние годы стал полный отказ от Pod Security Policies (PSP) в пользу более простой и надежной системы — Pod Security Admission (PSA).

Важное изменение: Лейблы узлов (Node Labels)

При настройке размещения подов (например, через nodeSelector) важно помнить, что в новых версиях Kubernetes (1.24+) лейбл управляющего узла изменился:

  • Старый вариант: node-role.kubernetes.io/master: ""
  • Новый вариант: node-role.kubernetes.io/control-plane: ""

Всегда проверяйте версию вашего кластера перед использованием этих меток в манифестах.

Эволюция безопасности: PSP → PSS → PSA

Раньше для контроля безопасности использовались сложные объекты PodSecurityPolicy. Начиная с версии 1.25, они полностью удалены. На их место пришла связка PSA и PSS.

Основные понятия:

  1. PSA (Pod Security Admission): Контроллер в Kubernetes, который проверяет поды при создании.
  2. PSS (Pod Security Standards): Три готовых набора правил (профиля) безопасности.
  3. Namespace Labels: Метод активации проверки через метки на пространстве имен.

Три уровня политик (PSS):

ПолитикаОписание
PrivilegedПолностью неограниченная. Разрешает всё (root, доступ к хосту).
Baseline«Золотая середина». Запрещает самые явные дыры в безопасности, но не требует сложной настройки.
RestrictedМаксимально жесткая. Соответствует лучшим практикам безопасности (Best Practices).

Как включить и настроить PSA

В отличие от PSP, вам не нужно создавать сложные роли. Достаточно добавить метку на Namespace.

Режимы работы PSA:

  • enforce: Блокирует запуск пода, если он нарушает правила.
  • audit: Разрешает запуск, но пишет о нарушениях в аудит-лог.
  • warn: Разрешает запуск, но выводит предупреждение пользователю в консоль.

Пример активации самого строгого режима:

kubectl label namespace my-apps pod-security.kubernetes.io/enforce=restricted

Capabilities и SecurityContext

Capabilities позволяют давать контейнеру только часть привилегий root, не давая полного доступа к системе. Например, NET_ADMIN позволяет настраивать сеть, но не дает доступа к файлам на хосте.

Согласно стандарту Restricted, хороший тон — это сбросить все привилегии (drop: ["ALL"]).

Пример безопасного пода (соответствует Restricted)

Этот под не запустится под пользователем root, не сможет повысить свои привилегии и использует стандартный профиль безопасности среды выполнения.

apiVersion: v1
kind: Pod
metadata:
  name: secure-busybox
  namespace: my-apps
spec:
  containers:
  - image: busybox:1.35.0
    name: busybox
    command: ["sh", "-c", "sleep 1h"]
    securityContext:
      allowPrivilegeEscalation: false # Запрет повышения прав
      runAsNonRoot: true              # Запрет запуска от root
      runAsUser: 2000                 # ID пользователя
      runAsGroup: 3000                # ID группы
      capabilities:
        drop: ["ALL"]                 # Сброс всех системных привилегий
      seccompProfile:
        type: RuntimeDefault          # Использование стандартного профиля защиты
Поделиться