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

Предупреждение

Поддержка функции политики безопасности pod (предварительная версия), описанной в этом документе, будет прекращена начиная с версии Kubernetes 1.21. В версии 1.25 функция будет удалена. Так как соответствующая версия Kubernetes будет скоро выпущена, сообщество Kubernetes планирует начать разработку приемлемых альтернатив. Предыдущее объявление о прекращении поддержки было сделано, когда приемлемых вариантов замены для клиентов еще не существовало. В настоящее время сообщество Kubernetes работает над альтернативным вариантом функции, и мы можем не торопиться с прекращением поддержки.

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

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

Важно!

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

Перед началом

В этой статье предполагается, что у вас есть кластер AKS. Если вам нужен кластер AKS, обратитесь к краткому руководству по работе с AKS с помощью Azure CLI или портала Azure.

Необходимо установить и настроить Azure CLI версии 2.0.61 или более поздней. Чтобы узнать версию, выполните команду az --version. Если вам необходимо выполнить установку или обновление, см. статью Установка Azure CLI 2.0.

Установка расширения интерфейса командной строки предварительной версии AKS

Чтобы использовать политики безопасности pod, требуется расширение CLI aks-preview версии 0.4.1 или более поздней. Установите расширение Azure CLI aks-preview с помощью команды az extension add, а затем проверьте наличие доступных обновлений с помощью команды az extension update.

# Install the aks-preview extension
az extension add --name aks-preview

# Update the extension to make sure you have the latest version installed
az extension update --name aks-preview

Регистрация поставщика функций политики безопасности pod

Этот документ и функция считаются устаревшими начиная с 15 октября 2020 г.

Чтобы создать или обновить кластер AKS для использования политик безопасности Pod, установите флаг компонента в подписке. Чтобы зарегистрировать флаг компонента PodSecurityPolicyPreview, используйте команду az feature register, как показано в следующем примере.

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

Через несколько минут отобразится состояние Registered (Зарегистрировано). Состояние регистрации можно проверить с помощью команды az feature list.

az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/PodSecurityPolicyPreview')].{Name:name,State:properties.state}"

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

az provider register --namespace Microsoft.ContainerService

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

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

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

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

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

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

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

Ниже приводятся краткие сведения о различиях в работе политики безопасности 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, отклоняются. Несоответствующие модули, существовавшие до применения политик Azure, отображаются в сведениях о нарушении политики. Несоответствующие модули pod, созданные после включения политик Azure, отклоняются, если для политик задано действие "Отклонить".
Просмотр политик в кластере kubectl get psp kubectl get constrainttemplate — возвращаются все политики.
Политика безопасности pod "Стандартный — привилегированный" По умолчанию при включении этой функции для ресурса создается привилегированная политика безопасности pod. Привилегированный режим не подразумевает ограничений, поэтому он эквивалентен отсутствию назначения политики Azure.
Политика безопасности Pod "Стандартный — базовый/по умолчанию" Пользователь устанавливает базовый ресурс политики безопасности pod. Политика Azure предоставляет встроенную базовую инициативу, которая сопоставляется с базовой политикой безопасности pod.
Политика безопасности Pod "Стандартный — ограниченный" Пользователь устанавливает ресурс с ограничением политики безопасности pod. Политика Azure предоставляет встроенную ограниченную инициативу, которая сопоставляется с ограниченной политикой безопасности pod.

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

Включить или отключить политику безопасности pod можно с помощью команды az aks update. В следующем примере выполняется включение политики безопасности pod для имени кластера myAKSCluster в группе ресурсов myResourceGroup.

Примечание

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

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

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

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

Чтобы просмотреть доступные политики, используйте команду 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. Используйте команду kubectl get rolebindings и выполните поиск по привязке default:privileged: в пространстве имен kube-system:

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

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

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 в расписание, прежде чем приступать к созданию собственных политик безопасности. В следующих разделах мы добавим несколько модулей в расписание, чтобы увидеть эти политики по умолчанию в действии.

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

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

Создайте пример пространства имен с именем psp-aks для тестовых ресурсов с помощью команды kubectl create namespace. Затем создайте учетную запись службы с именем nonadmin-user с помощью команды kubectl create serviceaccount:

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

Затем создайте объект RoleBinding для пользователя nonadmin-user, чтобы выполнять базовые действия в пространстве имен с помощью команды kubectl create rolebinding:

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

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

Чтобы подчеркнуть разницу между пользователем с правами администратора при использовании kubectl и обычным пользователем, который был создан в предыдущих шагах, создайте два псевдонима командной строки:

  • Псевдоним kubectl-admin предназначен для пользователя с правами администратора и ограничен пространством имен psp-aks.
  • Псевдоним 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 по умолчанию для модулей pod, политика privilege должна отклонить этот запрос.

Создайте файл 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

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

kubectl-nonadminuser apply -f nginx-privileged.yaml

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

$ kubectl-nonadminuser apply -f nginx-privileged.yaml

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 не удалось добавить в расписание. Давайте попробуем запустить этот же модуль NGINX без запроса на повышение привилегий.

Создайте файл 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

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

kubectl-nonadminuser apply -f nginx-unprivileged.yaml

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

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

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

Модуль не удается перевести на этап планирования, поэтому не требуется удалять ресурсы, чтобы продолжить.

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

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

Создайте файл 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

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

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

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

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

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, запрашивающих привилегированный доступ. Другие параметры, такие как runAsUser или разрешенные тома, не будут ограничены. Этот тип политики запрещает запрос привилегированного доступа, но в остальных случаях позволяет запускать в кластере запрошенные модули pod.

Создайте файл 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:
  - '*'

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

kubectl apply -f psp-deny-privileged.yaml

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

$ kubectl get psp

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, созданную в предыдущем шаге. Создайте файл 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

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

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

Теперь создайте объект ClusterRoleBinding, чтобы использовать ClusterRole, созданный в предыдущем шаге. Создайте файл 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

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

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

Примечание

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

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

Давайте попробуем снова создать непривилегированный модуль, применяя пользовательскую политику безопасности pod и привязку учетной записи пользователя для использования политики. Используйте тот же манифест nginx-privileged.yaml для создания модуля pod с помощью команды kubectl apply:

kubectl-nonadminuser apply -f nginx-unprivileged.yaml

Модуль pod успешно добавлен в расписание. При проверке состояния модуля с помощью команды kubectl get pods мы видим, что модуль имеет статус запущен:

$ kubectl-nonadminuser get pods

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

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

Удалите непривилегированный модуль NGINX с помощью команды kubectl delete и укажите имя манифеста YAML:

kubectl-nonadminuser delete -f nginx-unprivileged.yaml

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

Чтобы отключить политику безопасности pod, повторно выполните команду az aks update. В следующем примере выполняется выключение политики безопасности pod для кластера myAKSCluster в группе ресурсов myResourceGroup.

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

Затем удалите объекты ClusterRole и ClusterRoleBinding:

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

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

kubectl delete -f psp-deny-privileged.yaml

Наконец, удалите пространство имен psp-aks:

kubectl delete namespace psp-aks

Дальнейшие шаги

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

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