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

Общие сведения о политике Azure для кластеров Kubernetes

  • Мақала

расширение Политика AzureGatekeeper версии 3— веб-перехватчик контроллера допуска для агента open Policy (OPA), который применяется в масштабе и защищает компоненты кластера централизованно, согласованно. Компоненты кластера включают модули pod, контейнеры и пространства имен.

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

Политика Azure для Kubernetes поддерживает следующие кластерные среды:

Внимание

Модель Helm надстройки Политики Azure и надстройка для обработчика AKS объявлены нерекомендуемыми. Следуйте инструкциям по удалению надстроек.

Обзор

После установки надстройки или расширения Политики Azure в кластерах Kubernetes, Политика Azure выполняет следующие функции:

  • проверяет назначения политик в кластере с помощью службы Политики Azure;
  • Развертывает определения политик в кластере в виде шаблона ограничения и ограничения пользовательских ресурсов или в качестве ресурса шаблона мутации (в зависимости от содержимого определения политики).
  • Сообщает службе Политики Azure сведения об аудите и соответствии.

Чтобы включить и использовать Политику Azure с кластером Kubernetes, выполните следующие действия.

  1. Настройте кластер Kubernetes и установите надстройку Служба Azure Kubernetes (AKS) или расширение Политика Azure для кластеров Kubernetes с поддержкой Arc (в зависимости от типа кластера).

    Примечание.

    Распространенные проблемы с установкой описаны в статье Устранение неполадок в надстройке политики Azure.

  2. Создание или использование примера определения Политики Azure для Kubernetes

  3. Назначение определения кластеру Kubernetes

  4. Дождитесь проверки.

  5. Ведение журнала и устранение неполадок

  6. Ознакомьтесь с ограничениями и рекомендациями в нашем разделе часто задаваемых вопросов

Установка надстройки Политики Azure для AKS

Надстройка Политика Azure для AKS входит в состав Kubernetes версии 1.27 с долгосрочной поддержкой (LTS).

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

  1. Зарегистрируйте поставщики ресурсов и предварительные версии функций.

    • Портал Azure:

      Microsoft.PolicyInsights Зарегистрируйте поставщиков ресурсов. Действия см. в разделе Поставщики и типы ресурсов.

    • Azure CLI:

      # Log in first with az login if you're not using Cloud Shell

# Provider register: Register the Azure Policy provider
az provider register --namespace Microsoft.PolicyInsights

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

  3. Кластер AKS должен быть поддерживаемой версией Kubernetes в Служба Azure Kubernetes (AKS). Используйте следующий скрипт для проверки версии кластера AKS:

    # Log in first with az login if you're not using Cloud Shell

# Look for the value in kubernetesVersion
az aks list

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

    Домен Порт
    data.policy.core.windows.net 443
    store.policy.core.windows.net 443
    login.windows.net 443
    dc.services.visualstudio.com 443

После завершения предварительных требований установите надстройку Политика Azure в кластере AKS, которой требуется управлять.

  • Портал Azure

    1. Запустите службу Azure Kubernetes на портале Azure, выбрав Все службы, а затем выполнив поиск и выбрав Службы Kubernetes.

    2. Выберите один из кластеров AKS.

    3. Выберите Политики в левой части страницы службы Kubernetes.

    4. На главной странице нажмите кнопку Включить надстройку.

  • Azure CLI

    # Log in first with az login if you're not using Cloud Shell

az aks enable-addons --addons azure-policy --name MyAKSCluster --resource-group MyResourceGroup

Чтобы убедиться, что установка надстройки прошла успешно и что объекты pod azure-policy и gatekeeper запущены, выполните следующую команду:

# azure-policy pod is installed in kube-system namespace
kubectl get pods -n kube-system

# gatekeeper pod is installed in gatekeeper-system namespace
kubectl get pods -n gatekeeper-system

Наконец, убедитесь, что последняя надстройка установлена, выполнив следующую команду Azure CLI, с заменой <rg> на имя группы ресурсов и <cluster-name> на имя кластера AKS: az aks show --query addonProfiles.azurepolicy -g <rg> -n <cluster-name>. Результат должен выглядеть примерно так, как в следующих выходных данных для кластеров с помощью субъектов-служб:

{
  "config": null,
  "enabled": true,
  "identity": null
}

И следующие выходные данные для кластеров с помощью управляемого удостоверения:

 {
   "config": null,
   "enabled": true,
   "identity": {
     "clientId": "########-####-####-####-############",
     "objectId": "########-####-####-####-############",
     "resourceId": "<resource-id>"
   }
 }

Установка расширения Политика Azure для Kubernetes с поддержкой Azure Arc

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

В этой статье описывается Создание, Отображение состояния расширения и Удаление политики Azure для расширения Kubernetes.

Общие сведения о платформе расширений см. в разделе Расширения кластера Azure Arc.

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

Если вы уже развернули Политика Azure для Kubernetes в кластере Azure Arc с помощью Helm напрямую без расширений, следуйте инструкциям по удалению диаграммы Helm. После завершения удаления можно продолжить.

  1. Убедитесь, что дистрибутив кластера Kubernetes поддерживается.

    Примечание.

    Политика Azure для расширения Arc поддерживается в следующих дистрибутивах Kubernetes.

  2. Убедитесь, что выполнены все распространенные предварительные требования для расширений Kubernetes, перечисленных здесь , включая подключение кластера к Azure Arc.

    Примечание.

    расширение Политика Azure поддерживается для кластеров Kubernetes с поддержкой Arc в этих регионах.

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

    Домен Порт
    data.policy.core.windows.net 443
    store.policy.core.windows.net 443
    login.windows.net 443
    dc.services.visualstudio.com 443

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

    Примечание.

    Чтобы включить поставщика ресурсов, выполните действия, описанные в разделе "Поставщики ресурсов" и "Типы ресурсов", либо выполните команду Azure CLI или Azure PowerShell.

    • Azure CLI

      # Log in first with az login if you're not using Cloud Shell
# Provider register: Register the Azure Policy provider
az provider register --namespace 'Microsoft.PolicyInsights'

    • Azure PowerShell

      # Log in first with Connect-AzAccount if you're not using Cloud Shell

# Provider register: Register the Azure Policy provider
Register-AzResourceProvider -ProviderNamespace 'Microsoft.PolicyInsights'

Создание расширения политики Azure

Примечание.

Обратите внимание на следующие сведения о создании расширения политики Azure.

  • Автоматическое обновление включено по умолчанию, что означает, что при развертывании каких-либо новых изменений дополнительный номер версии расширения политики Azure будет обновляться.
  • Все переменные прокси, переданные в качестве параметров в connectedk8s, будут распространены на расширение политики Azure для поддержки исходящего прокси-сервера.

Чтобы создать экземпляр расширения для кластера с поддержкой Arc, выполните следующую команду, подставив в <> свои значения:

az k8s-extension create --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --extension-type Microsoft.PolicyInsights --name <EXTENSION_INSTANCE_NAME>

Пример:

az k8s-extension create --cluster-type connectedClusters --cluster-name my-test-cluster --resource-group my-test-rg --extension-type Microsoft.PolicyInsights --name azurepolicy

Пример результата:

{
  "aksAssignedIdentity": null,
  "autoUpgradeMinorVersion": true,
  "configurationProtectedSettings": {},
  "configurationSettings": {},
  "customLocationSettings": null,
  "errorInfo": null,
  "extensionType": "microsoft.policyinsights",
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-test-rg/providers/Microsoft.Kubernetes/connectedClusters/my-test-cluster/providers/Microsoft.KubernetesConfiguration/extensions/azurepolicy",
 "identity": {
    "principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "tenantId": null,
    "type": "SystemAssigned"
  },
  "location": null,
  "name": "azurepolicy",
  "packageUri": null,
  "provisioningState": "Succeeded",
  "releaseTrain": "Stable",
  "resourceGroup": "my-test-rg",
  "scope": {
    "cluster": {
      "releaseNamespace": "kube-system"
    },
    "namespace": null
  },
  "statuses": [],
  "systemData": {
    "createdAt": "2021-10-27T01:20:06.834236+00:00",
    "createdBy": null,
    "createdByType": null,
    "lastModifiedAt": "2021-10-27T01:20:06.834236+00:00",
    "lastModifiedBy": null,
    "lastModifiedByType": null
  },
  "type": "Microsoft.KubernetesConfiguration/extensions",
  "version": "1.1.0"
}

Отображение расширения политики Azure

Чтобы проверить успешность создания экземпляра расширения и проверить метаданные расширения, выполните следующую команду, подставив в <> свои значения:

az k8s-extension show --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --name <EXTENSION_INSTANCE_NAME>

Пример:

az k8s-extension show --cluster-type connectedClusters --cluster-name my-test-cluster --resource-group my-test-rg --name azurepolicy

Чтобы убедиться, что установка расширения прошла успешно и что объекты pod azure-policy и gatekeeper запущены, выполните следующую команду:

# azure-policy pod is installed in kube-system namespace
kubectl get pods -n kube-system

# gatekeeper pod is installed in gatekeeper-system namespace
kubectl get pods -n gatekeeper-system

Удаление расширения политики Azure

Чтобы удалить экземпляр расширения, выполните следующую команду, подставив в <> свои значения:

az k8s-extension delete --cluster-type connectedClusters --cluster-name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --name <EXTENSION_INSTANCE_NAME>

Создать определение политики.

Языковая структура Политики Azure для управления Kubernetes соответствует языковой структуре существующих определений политик. Существуют примеры файлов определений, которые можно назначить в встроенной библиотеке политик Политика Azure, которую можно использовать для управления компонентами кластера.

Политика Azure для Kubernetes также поддерживает создание пользовательских определений на уровне компонента для кластеров Служба Azure Kubernetes и кластеров Kubernetes с поддержкой Azure Arc. Примеры шаблонов ограничений и шаблонов мутаций доступны в библиотеке сообщества Gatekeeper. Расширение Visual Studio Code Политика Azure можно использовать для преобразования существующего шаблона ограничения или шаблона мутации в пользовательское определение политики Политика Azure.

В режиме Microsoft.Kubernetes.Data поставщика ресурсов для управления кластерами Kubernetes используются операции аудита, запрета, отключения и изменения.

Аудит и запрет должны предоставлять details свойства, относящиеся к работе с OPA Constraint Framework и Gatekeeper версии 3.

В рамках свойств details.templateInfo или details.constraintInfo в определении политики Политика Azure передает универсальный код ресурса (URI) или Base64Encoded значение этих настраиваемыхresourceDefinitions(CRD) надстройке. Rego — это язык, поддерживаемый OPA и Gatekeeper для проверки запросов к кластеру Kubernetes. Поддерживая существующий стандарт управления Kubernetes, Политика Azure позволяет повторно использовать существующие правила и объединять их с Политикой Azure для формирования унифицированной отчетности о совместимости с облачными технологиями. Дополнительные сведения о Rego см. в этой статье.

Назначение определения политики

Чтобы назначить определение политики кластеру Kubernetes, необходимо назначить соответствующие операции назначения политики управления доступом Azure на основе ролей (Azure RBAC). Встроенные роли Azure Участник политики ресурсов и Владелец включают эти операции. Дополнительные сведения см. в Разрешения Azure RBAC в политике Azure.

Чтобы найти встроенные политики для управления кластером с помощью портала Azure, выполните следующие действия. Если используется пользовательское определение политики, выполните поиск по имени или категории, в которой она была создана.

  1. Запустите службу Политики Azure на портале Azure. На панели слева выберите Все службы, а затем выполните поиск по запросу Политика и выберите этот пункт.

  2. Выберите Определения на левой панели страницы "Политика Azure".

  3. В раскрывающемся списке "Категория" щелкните Выбрать все, чтобы очистить фильтр, а затем выберите Kubernetes.

  4. Выберите определение политики, а затем нажмите кнопку Назначить.

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

    Примечание.

    При назначении политики Azure для определения Kubernetes Область должна включать ресурс кластера.

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

  7. Задайте для принудительного применения политики одно из следующих значений:

    • Включено — принудительно применить политику в кластере. Запросы на допуск Kubernetes с нарушениями отклоняются.

    • Отключено — не выполнять принудительного применения политики в кластере. Запросы на допуск Kubernetes с нарушениями не отклоняются. Результаты оценки соответствия по-прежнему доступны. При развертывании новых определений политик для запуска кластеров отключенный параметр полезен для тестирования определения политики, так как запросы на прием с нарушениями не запрещаются.

  8. Выберите Далее.

  9. Установка значений параметра

    • Чтобы исключить пространства имен Kubernetes из оценки политики, укажите список пространств имен в параметре Исключения пространства имен. Рекомендация заключается в исключении: kube-system, gatekeeper-system и azure-arc.

  10. Выберите Review + create (Просмотреть и создать).

Или воспользуйтесь кратким руководством Назначение политики с помощью портала для поиска и назначения политики Kubernetes. Найдите определение политики Kubernetes вместо примеров виртуальных машин аудита.

Внимание

Встроенные определения политик доступны для кластеров Kubernetes в категории Kubernetes. Список встроенных определений политик см. в Образцы Kubernetes.

Оценка политики

Надстройка сверяет назначения политик со службой Политики Azure на наличие изменений каждые 15 минут. Во время этого цикла обновления надстройка проверяет наличие изменений. Эти изменения активируют операции создания, обновления или удаления шаблонов ограничений и ограничений.

В кластере Kubernetes, если пространство имен имеет метку, соответствующую кластеру, запросы на допуск с нарушениями не отклоняются. Результаты оценки соответствия по-прежнему доступны.

  • Кластер Kubernetes с поддержкой Azure Arc: admission.policy.azure.com/ignore

Примечание.

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

Каждые 15 минут надстройка вызывает полную проверку кластера. После сбора сведений, полученных в ходе полной проверки, и выполненных в режиме реального времени оценок Gatekeeper попыток внести изменения в кластер надстройка отправляет результаты в Политику Azure для включения их в сведения о соответствии подобно любому назначению Политики Azure. Во время цикла аудита возвращаются только результаты активных назначений политик. Результаты аудита также могут отображаться как нарушения, указанные в поле состояния ограничения, завершившегося сбоем. Дополнительные сведения о ресурсах, не соответствующих требованиям, см. в разделе Сведения о компоненте для режимов поставщиков ресурсов.

Примечание.

Каждый отчет о соответствии в Политике Azure для кластеров Kubernetes включает все нарушения за последние 45 минут. Метка времени указывает, когда произошло нарушение.

Другие замечания:

  • Если подписка кластера зарегистрирована в Microsoft Defender для облака, политики Kubernetes Microsoft Defender для облака применяются к кластеру автоматически.

  • Если политика запрета применяется к кластеру с существующими ресурсами Kubernetes, все существующие ресурсы, которые не соответствуют новой политике, продолжают выполняться. Когда несоответствующий ресурс перераспределяется на другой узел, Gatekeeper блокирует создание ресурсов.

  • Если в кластере есть политика запрета, которая проверяет ресурсы, пользователь не получает сообщение об отказе при создании развертывания. Например, рассмотрим развертывание Kubernetes, содержащее replicasets и модули pod. Когда пользователь выполняется kubectl describe deployment $MY_DEPLOYMENT, он не возвращает сообщение об отклонении в рамках событий. Однако kubectl describe replicasets.apps $MY_DEPLOYMENT возвращает события, связанные с отклонением.

Примечание.

Контейнеры инициализации могут быть включены во время оценки политики. Чтобы узнать, включены ли контейнеры инициализации, просмотрите CRD для следующего или аналогичного объявления:

input_containers[c] {
   c := input.review.object.spec.initContainers[_]
}

Конфликты шаблонов ограничений

Если шаблоны ограничений имеют одно и то же имя метаданных ресурса, но определение политики ссылается на источник в различных расположениях, определения политик считаются конфликтующими. Пример. Два определения политики ссылались на один и тот же template.yaml файл, хранящийся в разных исходных расположениях, таких как хранилище шаблонов Политика Azure (store.policy.core.windows.net) и GitHub.

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

Ведение журнала

Pod-модули azure-policy и gatekeeper, являющиеся контроллерами/контейнерами Kubernetes, хранят журналы в кластере Kubernetes. Как правило, журналы политики Azure можно использовать для устранения проблем с приемом политик в кластере и отчетах о соответствии требованиям. Журналы pod диспетчера шлюза-контроллера можно использовать для устранения неполадок со средой выполнения. Журналы pod pod шлюза-аудита можно использовать для устранения неполадок с аудитом существующих ресурсов. Журналы можно предоставить на странице Insights (Аналитические сведения) кластера Kubernetes. Дополнительные сведения см. в статье Мониторинг производительности кластера Kubernetes с помощью Azure Monitor для контейнеров.

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

# Get the azure-policy pod name installed in kube-system namespace
kubectl logs <azure-policy pod name> -n kube-system

# Get the gatekeeper pod name installed in gatekeeper-system namespace
kubectl logs <gatekeeper pod name> -n gatekeeper-system

Если вы пытаетесь устранить неполадки с определенным кодом ComplianceReasonCode, который отображается в результатах соответствия требованиям, вы можете найти журналы pod azure-policy для этого кода, чтобы увидеть полную сопутствующую ошибку.

Дополнительные сведения см. в статье об отладке Gatekeeper в документации по Gatekeeper.

Просмотр артефактов Gatekeeper

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

  1. kubeconfig Настройка для кластера.

    Для кластера Службы Azure Kubernetes используйте следующий Azure CLI:

    # Set context to the subscription
az account set --subscription <YOUR-SUBSCRIPTION>

# Save credentials for kubeconfig into .kube in your home folder
az aks get-credentials --resource-group <RESOURCE-GROUP> --name <CLUSTER-NAME>

  2. Проверка подключения к кластеру.

    Выполните команду kubectl cluster-info. В случае успешного выполнения каждая служба отвечает по URL-адресу, в котором она выполняется.

Просмотр шаблонов ограничений надстройки

Чтобы просмотреть шаблоны ограничений, скачанные надстройкой, выполните команду kubectl get constrainttemplates. Шаблоны ограничений, начинающиеся с k8sazure, установлены надстройкой.

Просмотр шаблонов мутаций надстроек

Чтобы просмотреть шаблоны мутаций, скачанные надстройкой, запустите kubectl get assignkubectl get assignmetadataи kubectl get modifyset.

Получение сопоставлений политик Azure

Чтобы определить сопоставление между шаблоном ограничения, загруженным в кластер, и определением политики, используйте kubectl get constrainttemplates <TEMPLATE> -o yaml. Результаты выглядят как следующие данные.

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
    annotations:
    azure-policy-definition-id: /subscriptions/<SUBID>/providers/Microsoft.Authorization/policyDefinitions/<GUID>
    constraint-template-installed-by: azure-policy-addon
    constraint-template: <URL-OF-YAML>
    creationTimestamp: "2021-09-01T13:20:55Z"
    generation: 1
    managedFields:
    - apiVersion: templates.gatekeeper.sh/v1beta1
    fieldsType: FieldsV1
...

<SUBID> — это идентификатор подписки, а <GUID> — идентификатор определения сопоставленной политики. <URL-OF-YAML> — это исходное расположение шаблона ограничения, загружаемого надстройкой для установки в кластере.

Получив имена шаблонов ограничений, скачанных надстройкой, их можно использовать для просмотра связанных ограничений. Используйте kubectl get <constraintTemplateName> для получения списка. Ограничения, установленные надстройкой, начинаются с azurepolicy-.

Просмотр сведений об ограничениях

Ограничение содержит сведения о нарушениях и сопоставлениях с определением и назначением политики. Чтобы просмотреть подробные сведения, используйте kubectl get <CONSTRAINT-TEMPLATE> <CONSTRAINT> -o yaml. Результаты выглядят как следующие данные.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAzureContainerAllowedImages
metadata:
  annotations:
    azure-policy-assignment-id: /subscriptions/<SUB-ID>/resourceGroups/<RG-NAME>/providers/Microsoft.Authorization/policyAssignments/<ASSIGNMENT-GUID>
    azure-policy-definition-id: /providers/Microsoft.Authorization/policyDefinitions/<DEFINITION-GUID>
    azure-policy-definition-reference-id: ""
    azure-policy-setdefinition-id: ""
    constraint-installed-by: azure-policy-addon
    constraint-url: <URL-OF-YAML>
  creationTimestamp: "2021-09-01T13:20:55Z"
spec:
  enforcementAction: deny
  match:
    excludedNamespaces:
    - kube-system
    - gatekeeper-system
    - azure-arc
  parameters:
    imageRegex: ^.+azurecr.io/.+$
status:
  auditTimestamp: "2021-09-01T13:48:16Z"
  totalViolations: 32
  violations:
  - enforcementAction: deny
    kind: Pod
    message: Container image nginx for container hello-world has not been allowed.
    name: hello-world-78f7bfd5b8-lmc5b
    namespace: default
  - enforcementAction: deny
    kind: Pod
    message: Container image nginx for container hello-world has not been allowed.
    name: hellow-world-89f8bfd6b9-zkggg

Устранение неполадок надстройки

Дополнительные сведения об устранении неполадок надстройки для Kubernetes см. в разделе Kubernetes статьи об устранении неполадок политики Azure.

Чтобы Политика Azure расширения для связанных с расширением Arc проблем, перейдите в раздел:

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

надстройка Политика Azure для журнала изменений AKS

Надстройка Политика Azure для AKS имеет номер версии, указывающий версию образа надстройки. Так как в надстройке появилась поддержка функций, номер версии увеличивается.

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

Определение версии надстройки в кластере

Надстройка Политика Azure использует стандартную схему семантического управления версиями для каждой версии. Чтобы определить используемую версию надстройки Политика Azure, можно выполнить следующую команду:kubectl get pod azure-policy-<unique-pod-identifier> -n kube-system -o json | jq '.spec.containers[0].image'

Чтобы определить версию Gatekeeper, которую использует надстройка Политика Azure, можно выполнить следующую команду:kubectl get pod gatekeeper-controller-<unique-pod-identifier> -n gatekeeper-system -o json | jq '.spec.containers[0].image'

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

Доступные версии надстроек для каждой версии кластера AKS

1.7.1

Знакомство с CEL и VAP. Язык общих выражений (CEL) — это язык выражений kubernetes, который можно использовать для объявления правил проверки политики. Проверка функции политики допуска (VAP) обеспечивает оценку политики в дереве, снижает задержку запроса на прием и повышает надежность и доступность. Поддерживаемые действия проверки включают запрет, предупреждение и аудит. Пользовательская разработка политик для CEL/VAP разрешена, и существующие пользователи не должны преобразовывать его Rego в CEL, так как они будут поддерживаться и использоваться для применения политик. Чтобы использовать CEL и VAP, пользователям необходимо зарегистрировать флаг AKS-AzurePolicyK8sNativeValidation компонента в Microsoft.ContainerService пространстве имен. Дополнительные сведения см. в документации по gatekeeper.

Улучшения безопасности.

  • Выпущено сентября 2024 г.
  • Kubernetes 1.27+ (поколение VAP поддерживается только в версии 1.30+)
  • Вратарь 3.17.1

1.7.0

Введя расширение, функция сдвига влево, которая позволяет заранее узнать, будут ли ресурсы рабочей нагрузки (развертывания, реплики, задания и т. д.) создавать модули pod. Расширение не должно изменять поведение политик; скорее, она просто сдвигает оценку политик с областью действия pod, которые выполняются во время приема рабочей нагрузки, а не во время приема pod. Однако для выполнения этой оценки необходимо создать и оценить модуль pod, основанный на спецификации pod, определенной в рабочей нагрузке, которая может иметь неполные метаданные. Например, модуль pod what-if не будет содержать соответствующие ссылки владельца. Из-за этого небольшого риска изменения поведения политики мы представляем расширение как отключенное по умолчанию. Чтобы включить расширение для заданного определения политики, задайте значение .policyRule.then.details.source All. Встроенные модули будут обновлены в ближайшее время, чтобы включить параметризацию этого поля. Если вы протестируете определение политики и обнаружите, что модуль pod what-if, созданный для оценки, является неполным, можно также использовать мутацию с источником Generated для изменения модулей pod what-if. Дополнительные сведения об этом параметре см. в документации по Gatekeeper.

Улучшения безопасности.

  • Выпущено июля 2024 г.
  • Kubernetes 1.27+
  • Gatekeeper 3.16.3

1.6.1

Улучшения безопасности.

  • Выпущено в мае 2024 г.
  • Gatekeeper 3.14.2

1.5.0

Улучшения безопасности.

  • Выпущено в мае 2024 г.
  • Kubernetes 1.27+
  • Gatekeeper 3.16.3

1.4.0

Включает мутацию и внешние данные по умолчанию. Дополнительное изменение веб-перехватчика и повышение проверки ограничения времени ожидания веб-перехватчика может добавить задержку для вызовов в худшем случае. Также представлена поддержка просмотра определения политики и задания версии определения в результатах соответствия требованиям.

  • Выпущено в мае 2024 г.
  • Kubernetes 1.25+
  • Gatekeeper 3.14.0

1.3.0

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

  • Выпущено за февраль 2024 г.
  • Kubernetes 1.25+
  • Gatekeeper 3.14.0

1.2.1

  • Выпущено за октябрь 2023 г.
  • Kubernetes 1.25+
  • Gatekeeper 3.13.3

1.1.0

  • Выпущено июля 2023 г.
  • Kubernetes 1.27+
  • Gatekeeper 3.11.1

1.0.1

  • Выпущено в июне 2023 г.
  • Kubernetes 1.24+
  • Gatekeeper 3.11.1

1.0.0

Политика Azure для Kubernetes теперь поддерживает изменение для исправления кластеров AKS в масштабе!

Удаление надстройки

Удаление надстройки из AKS

Чтобы удалить надстройку "Политика Azure" из кластера AKS, используйте либо портал Azure, либо Azure CLI.

  • Портал Azure

    1. Запустите службу Azure Kubernetes на портале Azure, выбрав Все службы, а затем выполнив поиск и выбрав Службы Kubernetes.

    2. Выберите кластер AKS, в котором необходимо отключить надстройку Политики Azure.

    3. Выберите Политики в левой части страницы службы Kubernetes.

    4. На главной странице нажмите кнопку Отключить надстройку.

  • Azure CLI

    # Log in first with az login if you're not using Cloud Shell

az aks disable-addons --addons azure-policy --name MyAKSCluster --resource-group MyResourceGroup

Удаление надстройки из Kubernetes с поддержкой Azure Arc

Примечание.

Модель Helm надстройки политики Azure теперь устарела. Вместо этого следует выбрать расширение Политика Azure для Kubernetes с поддержкой Azure Arc.

Чтобы удалить надстройку Политики Azure и Gatekeeper из кластера Kubernetes с поддержкой Azure Arc, выполните следующую команду Helm:

helm uninstall azure-policy-addon

Удаление надстройки из Обработчика AKS

Примечание.

Продукт AKS Engine теперь не рекомендуется использовать для клиентов общедоступного облака Azure. Рекомендуется использовать Служба Azure Kubernetes (AKS) для управляемых kubernetes или поставщика API кластера Azure для самостоятельно управляемых Kubernetes. Нет новых функций, запланированных; этот проект будет обновлен только для CVEs и аналогично, с Kubernetes 1.24 в качестве окончательной версии для получения обновлений.

Чтобы удалить надстройку Политики Azure и Gatekeeper из кластера Обработчика AKS, используйте метод, соответствующий способу установки надстройки.

  • Если установка выполнена путем задания свойства addons в определении кластера для Обработчика AKS:

    повторно разверните определение кластера в Обработчике AKS после изменения значения свойства addons для azure-policy на false:

    "addons": [
  {
    "name": "azure-policy",
    "enabled": false
  }
]

    Дополнительные сведения см. в Обработчик AKS. Отключение надстройки Политики Azure.

  • При установке с диаграммами Helm выполните следующую команду Helm:

    helm uninstall azure-policy-addon

Ограничения

  • Для общих определений Политика Azure и ограничений назначений просмотрите задокументированные ограничения Политика Azure
  • Надстройку политики Azure для Kubernetes можно развернуть только в пулах узлов Linux.
  • Максимальное количество модулей pod, поддерживаемых надстройкой Политика Azure для каждого кластера: 10 000
  • Максимальное число несоответствующих записей в каждой политике на один кластер: 500.
  • Максимальное число несоответствующих записей на подписку: 1 миллион.
  • Параметры Gatekeeper вне функционала надстройки политики Azure не поддерживаются. Перед включением надстройки политики Azure удалите все компоненты, установленные Gatekeeper в прошлый раз.
  • Причины несоответствия недоступны для режима поставщика ресурсов Microsoft.Kubernetes.Data. Используйте Сведения о компоненте.
  • Компонентные исключения не поддерживаются для режимов поставщика ресурсов. Поддержка параметров доступна в определениях Политика Azure для исключения и включения определенных пространств имен.
  • metadata.gatekeeper.sh/requires-sync-data Использование заметки в шаблоне ограничения для настройки репликации данных из кластера в кэш OPA в настоящее время разрешено только для встроенных политик. Причина заключается в том, что это может значительно увеличить использование ресурсов pod gatekeeper, если не используется тщательно.

Настройка конфигурации Gatekeeper

Изменение конфигурации Gatekeeper не поддерживается, так как она содержит критически важные параметры безопасности. Изменения конфигурации согласованы.

Использование data.inventory в шаблонах ограничений

В настоящее время несколько встроенных политик используют репликацию данных, которая позволяет пользователям синхронизировать существующие ресурсы в кластере с кэшем OPA и ссылаться на них во время оценки AdmissionReview запроса. Политики репликации данных можно различать по присутствию data.inventory в Rego и присутствию metadata.gatekeeper.sh/requires-sync-data заметки, которая сообщает Политика Azure надстройке, какие ресурсы необходимо кэшировать для правильной оценки политики. Этот процесс отличается от автономного вратаря, где эта заметка является описательным, а не предписательным.

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

При удалении заметки может возникнуть ошибка, но надстройка политики не синхронизирует необходимые ресурсы для этого шаблона ограничения в кэш. Таким образом, политики будут оцениваться по пустому data.inventory (если встроенные не назначены, которые реплицируют необходимые ресурсы). Это приведет к вводу в заблуждение результатов соответствия. Как отмечалось ранее, изменение конфигурации вручную для кэширования необходимых ресурсов также запрещено.

Следующие ограничения применяются только к надстройке политики Azure для AKS:

Часто задаваемые вопросы

Что такое надстройка Политика Azure или расширение Политика Azure развертывается в кластере при установке?

Для работы надстройки Политики Azure требуется три компонента Gatekeeper: один pod аудита и две реплики pod веб-перехватчика. Также устанавливается один модуль pod Политика Azure и один модуль веб-перехватчика Политика Azure.

Сколько ресурсов следует ожидать, что надстройка или расширение Политика Azure будут использоваться в каждом кластере?

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

Ниже приведены оценки, которые помогут вам спланировать:

  • Для менее чем 500 модулей pod в одном кластере с ограничением максимум 20: два виртуальных ЦП и 350 МБ памяти для каждого компонента.
  • Для более чем 500 модулей pod в одном кластере с ограничением в 40: три виртуальных ЦП и 600 МБ памяти на каждый компонент.

Можно ли применять Политика Azure для определений Kubernetes в модулях pod Windows?

Pod-модули Windows не поддерживают контексты безопасности. Таким образом, некоторые из определений Политика Azure, такие как запрет доступа к корневым привилегиям, не могут быть эскалации в модулях pod Windows и применяться только к модулям pod Linux.

Какой тип диагностических данных собирается с помощью надстройки Политика Azure?

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

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

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

  • Версия агента надстройки Политики Azure
  • Тип кластера
  • Регион кластера
  • Группа ресурсов кластера
  • ИД ресурса кластера
  • ИД подписки кластера
  • Ос кластера (пример: Linux)
  • Кластерный город (пример: Сиэтл)
  • Штат кластера или провинция (пример: Вашингтон)
  • Страна кластера или регион (пример: США)
  • Исключения и ошибки, обнаруженные надстройкой Политики Azure во время установки агента при оценке политики
  • Число определений политик Gatekeeper, не установленных надстройкой Политики Azure

Какие общие рекомендации следует учитывать при установке надстройки Политика Azure?

  • Используйте пул системных узлов с отметкой CriticalAddonsOnly для планирования pod-модулей Gatekeeper. Дополнительные сведения см. в разделе Использование пулов системных узлов.
  • Защита исходящего трафика кластера AKS Дополнительные сведения см. в разделе Управление исходящим трафиком для узлов кластера.
  • Если кластер включен aad-pod-identity , модули pod Node Managed Identity (NMI) изменяют узлы для перехвата вызовов конечной точки метаданных iptables экземпляра Azure. Такая конфигурация обеспечивает перехват модулем NMI любого запроса к конечной точке метаданных, даже если модуль pod не использует aad-pod-identity.
  • AzurePodIdentityException CRD можно настроить для информирования о aad-pod-identity том, что все запросы к конечной точке метаданных, поступающие из модуля pod, который соответствует меткам, определенным в CRD, должны быть прокси-серверы без обработки в NMI. Системные модули pod с kubernetes.azure.com/managedby: aks меткой в пространстве имен kube-system следует исключить aad-pod-identity , настроив AzurePodIdentityException CRD. Дополнительные сведения см. в разделе Отключение aad-pod-identity для конкретного pod-модуля или приложения. Чтобы настроить исключение, установите mic-exception YAML.

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