Защита кластеров Служба Azure Kubernetes (AKS) с помощью Политика Azure

Статья
06/21/2023

Вы можете применять и применять встроенные политики безопасности в кластерах Служба Azure Kubernetes (AKS) с помощью Политика Azure. Политика Azure помогает применять стандарты организации и оценивать соответствие требованиям в масштабе. После установки надстройки Политика Azure для AKS можно применить к кластеру отдельные определения политик или группы определений политик, называемых инициативами (иногда называемыми наборами политик). Полный список определений политик и инициатив AKS см. в статье Встроенные определения в Политике Azure для Службы Azure Kubernetes.

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

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

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

Назначение встроенного определения политики или инициативы

Вы можете применить определение политики или инициативу в портал Azure, выполнив следующие действия.

Перейдите к службе Политика Azure в портал Azure с именем Политика.
Выберите Определения на левой панели страницы "Политика Azure".
В разделе Категории выберите Kubernetes.
Выберите определение политики или инициативу, которую необходимо применить. В этом примере выберите инициативу Базовые стандарты безопасности pod кластера Kubernetes для рабочих нагрузок на основе Linux .
Выберите Назначить.
Задайте для параметра Область группу ресурсов кластера AKS с включенной надстройкой Политика Azure.
Выберите страницу Параметры и измените Действие с audit на deny, чтобы заблокировать новые развертывания, нарушающие базовую инициативу. Можно также добавить дополнительные пространства имен для исключения из оценки. В этом примере оставьте значения по умолчанию.
Выберите Просмотр и создание>Создать, чтобы отправить назначение политики.

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

Пользовательские политики позволяют определять правила использования Azure. Например, можно применить следующие типы правил:

обеспечения безопасности;
управления затратами;
соблюдения требований организации (например к именованию или расположению).

Перед созданием пользовательской политики просмотрите список общих шаблонов и примеров, чтобы узнать, нет ли уже подходящего варианта.

Пользовательские определения политик записываются в формате JSON. Дополнительные сведения о создании пользовательской политики см. в статьях Структура определения службы "Политика Azure" и Создание определения пользовательской политики.

Примечание

Политика Azure теперь использует новое свойство templateInfo, которое позволяет определить тип источника для шаблона ограничения. При определении templateInfo в определениях политик не нужно определять свойства constraintTemplate или constraint . По-прежнему необходимо определить группы api и типы. Дополнительные сведения см. в статье Действия политик Azure.

После создания настраиваемого определения политики ознакомьтесь с пошаговым руководством по назначению политики для кластера Kubernetes.

Проверка выполнения Политика Azure

Убедитесь, что назначения политик применяются к кластеру с помощью следующей kubectl get команды.

kubectl get constrainttemplates

Примечание

Для синхронизации назначений политики в каждом кластере может потребоваться до 20 минут.

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

NAME                                     AGE
k8sazureallowedcapabilities              23m
k8sazureallowedusersgroups               23m
k8sazureblockhostnamespace               23m
k8sazurecontainerallowedimages           23m
k8sazurecontainerallowedports            23m
k8sazurecontainerlimits                  23m
k8sazurecontainernoprivilege             23m
k8sazurecontainernoprivilegeescalation   23m
k8sazureenforceapparmor                  23m
k8sazurehostfilesystem                   23m
k8sazurehostnetworkingports              23m
k8sazurereadonlyrootfilesystem           23m
k8sazureserviceallowedports              23m

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

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

Создайте файл с именем 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.15.5-alpine
      securityContext:
        privileged: true

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

kubectl apply -f nginx-privileged.yaml

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

Error from server ([denied by azurepolicy-container-no-privilege-00edd87bf80f443fa51d10910255adbc4013d590bec3d290b4f48725d4dfbdf9] Privileged container is not allowed: nginx-privileged, securityContext: {"privileged": true}): error when creating "privileged.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by azurepolicy-container-no-privilege-00edd87bf80f443fa51d10910255adbc4013d590bec3d290b4f48725d4dfbdf9] Privileged container is not allowed: nginx-privileged, securityContext: {"privileged": true}

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

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

В предыдущем примере образ контейнера автоматически пытался использовать привилегированные права для привязки NGINX к порту 80. Инициатива политики отклоняет этот запрос, поэтому модуль 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.15.5-alpine

Создайте модуль pod с помощью kubectl apply команды и укажите имя манифеста YAML.
```
kubectl apply -f nginx-unprivileged.yaml
```
Проверьте состояние модуля pod с помощью kubectl get pods команды .
```
kubectl get pods
```
Выходные данные должны выглядеть примерно так, как показано в следующем примере, который показывает, что модуль pod успешно запланирован и имеет состояние Выполняется:
```
NAME                 READY   STATUS    RESTARTS   AGE
nginx-unprivileged   1/1     Running   0          18s
```
В этом примере показана базовая инициатива, затрагивающая только развертывания, нарушающие политики в коллекции. Разрешенные развертывания продолжают работать.
Удалите непривилегированную группу kubectl delete pod NGINX с помощью команды и укажите имя манифеста YAML.
```
kubectl delete -f nginx-unprivileged.yaml
```

Отключение политики или инициативы

Вы можете удалить базовую инициативу в портал Azure, выполнив следующие действия.

Перейдите в область Политика на портал Azure.
Выберите Назначения.
Нажмите кнопку ... рядом с инициативой базовых стандартов безопасности pod кластера Kubernetes для рабочей нагрузки на основе Linux .
Выберите действие Удалить назначение.

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

Дополнительные сведения о работе Политика Azure см. в следующих статьях: