Бөлісу құралы:

Защита кластера с помощью политик безопасности pod в службе Azure Kubernetes (AKS) (предварительная версия)

  • Мақала

Внимание

Функция политики безопасности pod устарела 1 августа 2023 г. и удалена из AKS версии 1.25 и выше.

Мы рекомендуем перейти на контроллер допуска безопасности pod или политику Azure, чтобы оставаться в поддержка Azure. Pod Security Admission — это встроенное решение политики для реализаций одного кластера. Если вам нужна политика корпоративного уровня, лучшим выбором будет политика Azure.

Подготовка к работе

  • В этой статье предполагается, что у вас есть существующий кластер AKS. Если вам нужен кластер AKS, создайте его с помощью Azure CLI, Azure PowerShell или портал Azure.
  • Необходимо установить и настроить Azure CLI версии 2.0.61 или более поздней. Чтобы узнать версию, выполните команду az --version. Если вам необходимо выполнить установку или обновление, см. статью Установка Azure CLI.

Установка расширения Azure CLI aks-preview

Внимание

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

  1. Установите расширение aks-preview с помощью az extension add команды.

    az extension add --name aks-preview

  2. Обновите до последней версии расширения с помощью az extension update команды.

    az extension update --name aks-preview

Регистрация флага компонента PodSecurityPolicyPreview

  1. PodSecurityPolicyPreview Зарегистрируйте флаг компонента с помощью az feature register команды.

    az feature register --namespace "Microsoft.ContainerService" --name "PodSecurityPolicyPreview"

    Через несколько минут отобразится состояние Registered (Зарегистрировано).

  2. Проверьте состояние регистрации с помощью az feature show команды.

    az feature show --namespace "Microsoft.ContainerService" --name "PodSecurityPolicyPreview"

  3. Когда состояние отражает зарегистрировано, обновите регистрацию поставщика ресурсов Microsoft.ContainerService с помощью az provider register команды.

    az provider register --namespace Microsoft.ContainerService

Обзор политик безопасности pod

Кластеры Kubernetes используют контроллеры допуска для перехвата запросов к серверу API при создании ресурса. Контроллер допуска может затем проверить запрос ресурса на соответствие набору правил или изменить ресурс, чтобы изменить параметры развернутой службы.

PodSecurityPolicy — это контроллер допуска, который проверяет спецификацию pod в соответствии с определенными требованиями. Эти требования могут ограничивать использование привилегированных контейнеров, доступ к определенным типам хранилища, а также полномочия пользователя или группы, от имени которых запущен контейнер. При попытке развернуть ресурс, в котором спецификации pod не соответствуют требованиям, изложенным в политике безопасности pod, запрос будет отклонен. Возможность контролировать, какие модули pod могут быть запланированы в кластере AKS, помогает предотвратить некоторые возможные уязвимости или эскалацию привилегий.

При включении политики безопасности pod в кластере AKS применяется ряд политик по умолчанию. Эти политики предоставляют встроенный интерфейс, чтобы определить, какие модули pod можно запланировать. Однако вы можете столкнуться с проблемами при развертывании модулей pod, пока не определите собственные политики. Рекомендуем использовать следующий подход.

  1. Создание кластера AKS.
  2. Определите собственные политики безопасности pod.
  3. Включите функцию политики безопасности pod.

Различия в работе политики безопасности pod и Политики Azure

Сценарий Политика безопасности pod Политика Azure
Установка Включение функции политики безопасности pod Включение надстройки Политики Azure
Развертывание политик Развертывание функции политики безопасности pod Назначение политик Azure для области подписки или группы ресурсов. Использование надстройки "Политика Azure" для приложений ресурсов Kubernetes обязательно.
Политики по умолчанию Если политика безопасности pod включена в AKS, применяются привилегированные и неограниченные политики по умолчанию. При включении надстройки политики Azure политики по умолчанию не применяются. Необходимо явно включить политики в политике Azure.
Создание и назначение политик Администратор кластера создает ресурс для политики безопасности pod Пользователи должны иметь как минимум роль "владелец" или "участник политики ресурсов" в группе ресурсов кластера AKS. — С помощью API пользователи могут назначать политики в области ресурсов кластера AKS. Пользователь должен иметь как минимум разрешение "владелец" или "участник политики ресурсов" в ресурсе кластера AKS. — На портале Azure политики могут быть назначены на уровне группы управления, подписки или группы ресурсов.
Политики авторизации Пользователям и учетным записям служб требуются явные разрешения на использование политик безопасности pod. Для авторизации политик не требуется дополнительное назначение. После назначения политик в Azure их могут использовать все пользователи кластера.
Возможность применения политики Пользователь с правами администратора может обойти принудительное применение политик безопасности pod. Все пользователи (администратор и неадминистратор) видят одни и те же политики. Нет специального регистра на основе пользователей. Приложение политики можно исключить на уровне пространства имен.
Область политики Политики безопасности Pod не являются пространствами имен Шаблоны ограничений, используемые Политика Azure, не имеют пространства имен.
Действие "запрет/аудит/изменение" Политики безопасности pod поддерживают только действие "запрет". Изменения можно выполнять для значений по умолчанию в запросах на создание. Проверку можно выполнять во время запросов на обновление. Политика Azure Policy поддерживает действия "аудит" и "запрет". Мутация пока не поддерживается.
Соответствие политике безопасности pod Нет никаких сведений о соответствии модулей pod, которые существовали перед включением политики безопасности pod. Не соответствующие политике модули pod, созданные после включения политик безопасности pod, отклоняются. Несоответствующие модули, существовавшие до применения политик Azure, отображаются в сведениях о нарушении политики. Несоответствующие модули pod, созданные после включения политик Azure, отклоняются, если для политик задано действие "Отклонить".
Просмотр политик в кластере kubectl get psp kubectl get constrainttemplate — возвращаются все политики.
Политика безопасности pod "Стандартный — привилегированный" По умолчанию при включении этой функции для ресурса создается привилегированная политика безопасности pod. Привилегированный режим не подразумевает ограничений, так как это эквивалентно тому, что у него нет Политика Azure назначения.
Политика безопасности Pod "Стандартный — базовый/по умолчанию" Пользователь устанавливает базовый ресурс политики безопасности pod. Политика Azure предоставляет встроенную базовую инициативу, которая сопоставляется с базовой политикой безопасности pod.
Политика безопасности Pod "Стандартный — ограниченный" Пользователь устанавливает ресурс с ограничением политики безопасности pod. Политика Azure предоставляет встроенную ограниченную инициативу, которая сопоставляется с ограниченной политикой безопасности pod.

Включение политики безопасности pod в кластере AKS

Примечание.

Для реального использования не включите политику безопасности pod, пока не определите собственные пользовательские политики. В этой статье мы включите политику безопасности pod в качестве первого шага, чтобы узнать, как политики по умолчанию ограничивают развертывания pod.

  • Включите политику безопасности pod с помощью az aks update команды.

    az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --enable-pod-security-policy

Политики AKS по умолчанию

При включении политики безопасности pod AKS создает одну политику по умолчанию с именем privileged. Не изменяйте и не удаляйте политику по умолчанию. Вместо этого создайте собственные политики, выбрав параметры, которые требуется контролировать. Прежде всего давайте посмотрим, как эти политики по умолчанию влияют на развертывания модулей pod.

  1. Просмотрите доступные политики с помощью kubectl get psp команды.

    kubectl get psp

    Выходные данные будут выглядеть примерно так:

    NAME         PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
privileged   true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *     configMap,emptyDir,projected,secret,downwardAPI,persistentVolumeClaim

    Привилегированная политика безопасности pod применяется к любому пользователю, прошедшему проверку подлинности в кластере AKS. Это назначение контролируется ClusterRoles и ClusterRoleBindings.

  2. Выполните поиск по умолчанию:privileged: привязка в пространстве имен kube-system с помощью kubectl get rolebindings команды.

    kubectl get rolebindings default:privileged -n kube-system -o yaml

    В следующем сжатом примере выходных данных показано, что psp:privileged ClusterRole назначается любому системному:прошедшим проверку подлинности пользователям. Эта возможность обеспечивает базовый уровень привилегий при отсутствии собственных политик.

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  [...]
  name: default:privileged
  [...]
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: psp:privileged
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters

Важно понять, как эти политики по умолчанию взаимодействуют с запросами пользователей на добавление модулей pod в расписание, прежде чем приступать к созданию собственных политик безопасности. В следующих нескольких разделах мы запланируем некоторые модули pod, чтобы увидеть политики по умолчанию в действии.

Создание тестового пользователя в кластере AKS

При использовании az aks get-credentials команды учетные данные администратора кластера AKS добавляются в kubectl конфигурацию по умолчанию. Пользователь с правами администратора может обойти принудительное применение политик безопасности pod. Если вы используете интеграцию Microsoft Entra для кластеров AKS, вы можете войти с помощью учетных данных пользователя без администратора, чтобы увидеть применение политик в действии.

  1. Создайте пример пространства имен psp-aks для тестовых ресурсов с помощью kubectl create namespace команды.

    kubectl create namespace psp-aks

  2. Создайте учетную запись службы с именем nonadmin-user с помощью kubectl create serviceaccount команды.

    kubectl create serviceaccount --namespace psp-aks nonadmin-user

  3. Создайте RoleBinding для неадмин-пользователя, чтобы выполнить основные действия в пространстве имен с помощью kubectl create rolebinding команды.

    kubectl create rolebinding \
    --namespace psp-aks \
    psp-aks-editor \
    --clusterrole=edit \
    --serviceaccount=psp-aks:nonadmin-user

Создание псевдонимов для администраторов и обычных пользователей

При использовании kubectlвы можете выделить различия между обычным пользователем администратора и пользователем без администратора, создав два псевдонима командной строки:

  1. Псевдоним kubectl-admin для обычного пользователя администратора, который ограничен пространством имен psp-aks.
  2. Псевдоним kubectl-nonadminuser для пользователя nonadmin-user , созданного на предыдущем шаге, который ограничен пространством имен psp-aks .

  • Создайте два псевдонима с помощью следующих команд.

    alias kubectl-admin='kubectl --namespace psp-aks'
alias kubectl-nonadminuser='kubectl --as=system:serviceaccount:psp-aks:nonadmin-user --namespace psp-aks'

Тестирование создания привилегированного модуля pod

Давайте протестируем, что происходит при планировании модуля pod с контекстом privileged: trueбезопасности. Этот контекст безопасности повышает привилегии модуля. Политика безопасности AKS по умолчанию должна запретить этот запрос.

  1. Создайте файл с именем nginx-privileged.yaml и вставьте содержимое следующего манифеста YAML.

    apiVersion: v1
kind: Pod
metadata:
  name: nginx-privileged
spec:
  containers:
    - name: nginx-privileged
      image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine
      securityContext:
        privileged: true

  2. Создайте pod с помощью kubectl apply команды и укажите имя манифеста YAML.

    kubectl-nonadminuser apply -f nginx-privileged.yaml

    В следующем примере выходных данных показано, что модуль pod не удалось запланировать:

    Error from server (Forbidden): error when creating "nginx-privileged.yaml": pods "nginx-privileged" is forbidden: unable to validate against any pod security policy: []

    Так как модуль pod не достигает этапа планирования, перед переходом к ней нет ресурсов для удаления.

Тестирование создания непривилегированного модуля pod

В предыдущем примере мы запросили повышение привилегий в спецификации модуля pod. Этот запрос был отклонен политикой безопасности по предоставлению привилегий, используемой по умолчанию, поэтому модуль pod не удалось добавить в расписание. Давайте попробуем запустить тот же pod NGINX без запроса на эскалацию привилегий.

  1. Создайте файл с именем nginx-unprivileged.yaml и вставьте содержимое следующего манифеста YAML.

    apiVersion: v1
kind: Pod
metadata:
  name: nginx-unprivileged
spec:
  containers:
    - name: nginx-unprivileged
      image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine

  2. Создайте pod с помощью kubectl apply команды и укажите имя манифеста YAML.

    kubectl-nonadminuser apply -f nginx-unprivileged.yaml

    В следующем примере выходных данных показано, что модуль pod не удалось запланировать:

    Error from server (Forbidden): error when creating "nginx-unprivileged.yaml": pods "nginx-unprivileged" is forbidden: unable to validate against any pod security policy: []

    Так как модуль pod не достигает этапа планирования, перед переходом к ней нет ресурсов для удаления.

Тестирование создания модуля pod с определенным контекстом пользователя

В предыдущем примере образ контейнера автоматически пытался использовать корневой каталог для привязки NGINX к порту 80. Этот запрос был отклонен политикой безопасности по предоставлению привилегий, используемой по умолчанию, поэтому модуль pod не удалось запустить. Давайте попробуем запустить тот же pod NGINX с определенным контекстом пользователя, например runAsUser: 2000.

  1. Создайте файл с именем nginx-unprivileged-nonroot.yaml и вставьте его в следующий манифест YAML.

    apiVersion: v1
kind: Pod
metadata:
  name: nginx-unprivileged-nonroot
spec:
  containers:
    - name: nginx-unprivileged
      image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine
      securityContext:
        runAsUser: 2000

  2. Создайте pod с помощью kubectl apply команды и укажите имя манифеста YAML.

    kubectl-nonadminuser apply -f nginx-unprivileged-nonroot.yaml

    В следующем примере выходных данных показано, что модуль pod не удалось запланировать:

    Error from server (Forbidden): error when creating "nginx-unprivileged-nonroot.yaml": pods "nginx-unprivileged-nonroot" is forbidden: unable to validate against any pod security policy: []

    Так как модуль pod не достигает этапа планирования, перед переходом к ней нет ресурсов для удаления.

Создание пользовательской политики безопасности pod

Теперь, когда вы изучили поведение политик безопасности pod по умолчанию, расскажем, как пользователь без прав администратора может добавлять модули в расписание.

Мы создадим политику для отклонения модулей pod, запрашивающих привилегированный доступ. Другие параметры, такие как runAsUser или разрешенные тома, не будут ограничены. Этот тип политики запрещает запрос на привилегированный доступ, но позволяет кластеру запускать запрошенные модули pod.

  1. Создайте файл с именем psp-deny-privileged.yaml и вставьте его в следующий манифест YAML.

    apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: psp-deny-privileged
spec:
  privileged: false
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
 - '*'

  2. Создайте политику с помощью kubectl apply команды и укажите имя манифеста YAML.

    kubectl apply -f psp-deny-privileged.yaml

  3. Просмотрите доступные политики с помощью kubectl get psp команды.

    kubectl get psp

    В следующем примере выходных данных сравните политику psp-deny-privileged с политикой привилегий по умолчанию, которая была применена в предыдущих примерах для создания модуля pod. Политика запрещает только использование эскалации PRIV. Для политики psp-deny-privileged не существует ограничений пользователей или групп.

    NAME                  PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
privileged            true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *
psp-deny-privileged   false          RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *

Использование пользовательской политики безопасности pod для учетных записей пользователя

В предыдущем шаге вы создали политику безопасности pod для отклонения модулей, запрашивающих привилегированный доступ. Чтобы разрешить использование политики, создайте объект Role или ClusterRole. Затем свяжите одну из этих ролей с помощью RoleBinding или ClusterRoleBinding. В этом примере мы создадим ClusterRole, который позволяет использовать политику psp-deny-privileged , созданную на предыдущем шаге.

  1. Создайте файл с именем psp-deny-privileged-clusterrole.yaml и вставьте его в следующий манифест YAML.

    kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: psp-deny-privileged-clusterrole
rules:
- apiGroups:
  - extensions
   resources:
  - podsecuritypolicies
   resourceNames:
  - psp-deny-privileged
   verbs:
  - use

  2. Создайте ClusterRole с помощью kubectl apply команды и укажите имя манифеста YAML.

    kubectl apply -f psp-deny-privileged-clusterrole.yaml

  3. Создайте файл с именем psp-deny-privileged-clusterrolebinding.yaml и вставьте его в следующий манифест YAML.

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: psp-deny-privileged-clusterrolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: psp-deny-privileged-clusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts

  4. Создайте ClusterRoleBinding с помощью kubectl apply команды и укажите имя манифеста YAML.

    kubectl apply -f psp-deny-privileged-clusterrolebinding.yaml

Примечание.

В первом шаге этих инструкций мы включили функцию политики безопасности pod в кластере AKS. Рекомендуется включать функцию политики безопасности pod только после определения собственных политик. На этом этапе можно включить функцию политики безопасности pod. Мы определили одну или несколько пользовательских политик и связали учетные записи пользователей с этими политиками. Теперь вы можете безопасно включить функцию политики безопасности pod и свести к минимуму проблемы, вызванные политиками по умолчанию.

Повторное тестирование создания непривилегированного модуля pod

Давайте попробуем снова создать непривилегированный модуль, применяя пользовательскую политику безопасности pod и привязку учетной записи пользователя для использования политики.

В этом примере показано, как создать пользовательские политики безопасности pod, чтобы контролировать доступ к кластеру AKS для разных пользователей или групп. Политики AKS по умолчанию обеспечивают ограниченный контроль над запуском модулей pod, поэтому следует создать собственные пользовательские политики, чтобы правильно определить необходимые ограничения.

  1. nginx-privileged.yaml Используйте манифест для создания модуля pod с помощью kubectl apply команды.

    kubectl-nonadminuser apply -f nginx-unprivileged.yaml

  2. Проверьте состояние pod с помощью kubectl get pods команды.

    kubectl-nonadminuser get pods

    В следующем примере выходных данных показано, что модуль pod успешно запланирован и выполняется:

    NAME                 READY   STATUS    RESTARTS   AGE
nginx-unprivileged   1/1     Running   0          7m14s

  3. Удалите unprivileged pod NGINX с помощью kubectl delete команды и укажите имя манифеста YAML.

    kubectl-nonadminuser delete -f nginx-unprivileged.yaml

Очистка ресурсов

  1. Отключите политику безопасности pod с помощью az aks update команды.

    az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --disable-pod-security-policy

  2. Удалите ClusterRole и ClusterRoleBinding с помощью kubectl delete команды.

    kubectl delete -f psp-deny-privileged-clusterrole.yaml

  3. Удалите ClusterRoleBinding с помощью kubectl delete команды.

    kubectl delete -f psp-deny-privileged-clusterrolebinding.yaml

  4. Удалите политику безопасности с помощью kubectl delete команды и укажите имя манифеста YAML.

    kubectl delete -f psp-deny-privileged.yaml

  5. Удалите пространство имен psp-aks с помощью kubectl delete команды.

    kubectl delete namespace psp-aks

Следующие шаги

В этой статье показано, как создать политику безопасности pod, чтобы предотвратить использование привилегированного доступа. Политики могут применять множество функций, таких как тип тома или пользователя RunAs. Дополнительные сведения о доступных параметрах см. в Справочнике по политикам безопасности Kubernetes Pod.

Дополнительные сведения об ограничении сетевого трафика для модулей pod см. в статье Защита трафика между группами pod с использованием политик сети в Службе Azure Kubernetes (AKS).