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

Статья
08/02/2024

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

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

Необходимые компоненты

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

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

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

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

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

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

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

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

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

Примечание.

Политика Azure теперь использует новое свойство, известное как templateInfo, которое позволяет определить тип источника для шаблона ограничения. При определении шаблона TemplateInfo в определениях политик вам не нужно определять свойства ограниченияTemplate или ограничения . Вам по-прежнему необходимо определить apiGroups и типы. Дополнительные сведения см. в статье Действия политик 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
```
В этом примере показана базовая инициатива, влияющая только на развертывания, которые нарушают политики в коллекции. Разрешенные развертывания продолжают работать.
Удалите unprivileged pod NGINX с помощью kubectl delete команды и укажите имя манифеста YAML.
```
kubectl delete -f nginx-unprivileged.yaml
```

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

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

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

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

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

Общие сведения о Политике Azure
Политика Azure инициативы и политики для AKS
Удалите надстройку Политика Azure.

Поделиться через