Alauda Container Platform
  • Русский

    • Политики безопасности Pod

    ACP поддерживает Kubernetes Pod Security Admission (PSA) и Kyverno Policy для помощи в обеспечении стандартов безопасности для Pod, работающих в ваших кластерах.

    Содержание

    Pod Security AdmissionРежимы безопасностиСтандарты безопасностиКонфигурацияМетки namespaceИсключенияKyverno PolicyПредварительные требованияПрименение Kyverno политикВеб-консольCLI

    Pod Security Admission

    Обратитесь к официальной документации Kubernetes: Pod Security Admission

    Pod Security Admission (PSA) — это контроллер допуска Kubernetes, который обеспечивает выполнение политик безопасности на уровне namespace, проверяя спецификации Pod на соответствие предопределённым стандартам.

    Режимы безопасности

    PSA определяет три режима для управления обработкой нарушений политики:

    РежимПоведениеСценарий использования
    EnforceЗапрещает создание/изменение несоответствующих Pod.Производственные среды, требующие строгого соблюдения безопасности.
    AuditПозволяет создавать Pod, но регистрирует нарушения в логах аудита.Мониторинг и анализ инцидентов безопасности без блокировки рабочих нагрузок.
    WarnПозволяет создавать Pod, но возвращает клиенту предупреждения о нарушениях.Тестовые среды или переходные этапы для корректировки политик.

    Ключевые замечания:

    • Enforce действует только на Pod (например, отклоняет Pod, но позволяет ресурсы, не являющиеся Pod, такие как Deployments).
    • Audit и Warn применяются как к Pod, так и к их контроллерам (например, Deployments).

    Стандарты безопасности

    PSA определяет три стандарта безопасности для ограничения привилегий Pod:

    СтандартОписаниеОсновные ограничения
    PrivilegedНеограниченный доступ. Подходит для доверенных рабочих нагрузок (например, системных компонентов).Нет проверки полей securityContext.
    BaselineМинимальные ограничения для предотвращения известных эскалаций привилегий.Блокирует hostNetwork, hostPID, привилегированные контейнеры и неограниченные тома hostPath.
    RestrictedСамая строгая политика, обеспечивающая лучшие практики безопасности.Требует:
    - runAsNonRoot: true
    - seccompProfile.type: RuntimeDefault
    - Удаление Linux capabilities.

    Конфигурация

    Метки namespace

    Применяйте метки к namespace для определения политик PSA.

    Пример YAML файла

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

    Команда CLI

    # Шаг 1: Обновить метки Pod Admission
kubectl label namespace <namespace-name> \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/audit=restricted \
  --overwrite

# Шаг 2: Проверить метки
kubectl get namespace <namespace-name> --show-labels

    Исключения

    Исключайте конкретных пользователей, namespace или runtime классы из проверок PSA.

    Пример конфигурации:

    apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
exemptions:
  usernames: ['admin']
  runtimeClasses: ['nvidia']
  namespaces: ['kube-system']

    Kyverno Policy

    ACP предоставляет несколько примеров для создания Kyverno политик безопасности Pod. Примеры включают:

    • Restricted: Restricted запрещает доступ ко всем функциям хоста и требует, чтобы Pod запускались с UID и SELinux контекстом, выделенными для namespace.
    • Restricted-v2: Restricted-v2 запрещает доступ ко всем функциям хоста и требует, чтобы Pod запускались с UID и SELinux контекстом, выделенными для namespace. Это самая строгая политика, используемая по умолчанию для аутентифицированных пользователей. В дополнение к устаревшей политике 'restricted', она требует удаления ВСЕХ capabilities и запрещает бинарники для повышения привилегий. Также по умолчанию устанавливает seccomp профиль в runtime/default, если он не задан, иначе требуется этот профиль seccomp.
    • Anyuid: Anyuid предоставляет все возможности политики restricted, но позволяет запускать Pod с любым UID и GID.
    • Hostaccess: Hostaccess разрешает доступ ко всем namespace хоста, но требует, чтобы Pod запускались с UID и SELinux контекстом, выделенными для namespace. ВНИМАНИЕ: эта политика разрешает доступ к namespace, файловым системам и PID хоста. Используйте только для доверенных Pod. Предоставляйте с осторожностью.
    • Hostmount-anyuid: Hostmount-anyuid предоставляет все возможности политики restricted, но разрешает хостовые монтирования и любой UID для Pod. В основном используется для recycler persistent volume. ВНИМАНИЕ: эта политика разрешает доступ к файловой системе хоста с любым UID, включая UID 0. Предоставляйте с осторожностью.
    • Hostnetwork: Hostnetwork разрешает использование сетей и портов хоста, но требует, чтобы Pod запускались с UID и SELinux контекстом, выделенными для namespace.
    • Hostnetwork-v2: Hostnetwork-v2 разрешает использование сетей и портов хоста, но требует, чтобы Pod запускались с UID и SELinux контекстом, выделенными для namespace. В дополнение к устаревшей политике 'hostnetwork', требует удаления ВСЕХ capabilities и запрещает бинарники для повышения привилегий. По умолчанию устанавливает seccomp профиль в runtime/default, если он не задан, иначе требуется этот профиль seccomp.
    • Node-exporter: Политика Node-exporter используется для Prometheus node exporter.
    • Nonroot: Nonroot предоставляет все возможности политики restricted, но позволяет запускать Pod с любым не-root UID. Пользователь должен указать UID или он должен быть указан в манифесте контейнерного рантайма.
    • Nonroot-v2: Nonroot-v2 предоставляет все возможности политики restricted, но позволяет запускать Pod с любым не-root UID. Пользователь должен указать UID или он должен быть указан в манифесте контейнерного рантайма. В дополнение к устаревшей политике 'nonroot', требует удаления ВСЕХ capabilities и запрещает бинарники для повышения привилегий. По умолчанию устанавливает seccomp профиль в runtime/default, если он не задан, иначе требуется этот профиль seccomp.
    • Privileged: Privileged разрешает доступ ко всем привилегированным функциям и функциям хоста, а также возможность запускать с любым пользователем, любой группой, любым fsGroup и с любым SELinux контекстом. ВНИМАНИЕ: это самая либеральная политика и должна использоваться только для администрирования кластера. Предоставляйте с осторожностью.
    NOTICE

    Политика Restricted не равна стандарту Kubernetes Pod Security Admission 'restricted'. Возможно, вам потребуется изменить конфигурацию безопасности Pod, если вы хотите использовать Kyverno политику Restricted вместо стандарта Kubernetes Pod Security Admission 'restricted'.

    Предварительные требования

    • Установите Alauda Container Platform Compliance для Kyverno, обратитесь к документу.
    • Включите feature gate namespace-resource-manage в настройках featuregate ACP.

    Применение Kyverno политик

    Веб-консоль

    1. В консоли ACP перейдите в Container Platform, выберите namespace, в котором хотите применить политику безопасности.
    2. Перейдите в Advanced > Resources.
    3. Найдите ресурс типа Policy из группы kyverno.io.
    4. Выберите версию "v2beta1", нажмите Create для создания новой Kyverno политики.
    5. В диалоге Create Resource выберите вкладку Samples.
    6. Выберите нужный пример политики безопасности Pod (например, Restricted), затем нажмите Try.
    7. Просмотрите и при необходимости измените YAML политики, затем нажмите Update для применения политики.

    CLI

    1. Войдите в Kubernetes кластер, где хотите применить политику безопасности.

    2. Выполните следующую команду для создания Kyverno политики из примерного ресурса:

      $ kubectl get consoleyamlsamples.console.alauda.io restricted-policy -otemplate --template={{.spec.yaml}}|kubectl apply -f -
$ kubectl get policies.kyverno.io
NAME         ADMISSION   BACKGROUND   READY   AGE   MESSAGE
restricted   true        true         True    1m   Ready

    Доступные примерные ресурсы:

    • restricted-policy
    • restrictedv2-policy
    • anyuid-policy
    • hostaccess-policy
    • hostmount-anyuid-policy
    • hostnetwork-policy
    • hostnetwork-v2-policy
    • node-exporter-policy
    • nonroot-policy
    • nonroot-v2-policy
    • privileged-policy