Использование Microsoft Entra ID для авторизации API Kubernetes в АКС

В этой статье показано, как авторизовать вызовы API Kubernetes в службе Azure Kubernetes (AKS) с помощью удостоверений идентификаторов Microsoft Entra. Авторизация Entra ID для Kubernetes API использует назначения ролей Azure RBAC для управления доступом к ресурсам Kubernetes. Для встроенных ресурсов Kubernetes назначьте одну из встроенных ролей AKS (например, azure Kubernetes Service RBAC Reader) в области кластера или пространства имен. Для пользовательских ресурсов (CRD) назначьте настраиваемую роль с условиями Azure ABAC, которые указывают, к каким группам или типам CRD назначенный может получить доступ. Два назначения ролей составляют: один предоставляет доступ к стандартным ресурсам Kubernetes, а другой предоставляет условный доступ к определенным пользовательским ресурсам.

Общие сведения о доступных параметрах авторизации API Kubernetes в AKS см. в концепциях авторизации кластера.

Перед тем как начать

• Вам потребуется azure CLI версии 2.24.0 или более поздней версии. Чтобы узнать версию, выполните команду az --version. Если необходимо установить или обновить, см. раздел Install Azure CLI.
• Вам нужен kubectl с минимальной версией 1.18.3.
• Для того чтобы добавить авторизацию с использованием Entra ID для API Kubernetes, перед этим на вашем кластере должна быть включена управляемая интеграция Microsoft Entra. Если необходимо включить управляемую интеграцию Microsoft Entra, см. раздел "Использование идентификатора Microsoft Entra в AKS".
• Новые назначения ролей могут занять до пяти минут для распространения и обновления сервером авторизации.
• Авторизация Entra ID для API Kubernetes требует, чтобы тенант Microsoft Entra, настроенный для аутентификации, совпадал с тенантом для подписки, содержащей ваш кластер AKS.

Создайте новый кластер AKS с управляемой интеграцией Microsoft Entra и авторизацией Entra ID

1. Создайте группу ресурсов Azure с помощью команды az group create.

   export RESOURCE_GROUP=<resource-group-name>
   export LOCATION=<azure-region>
   
   az group create --name $RESOURCE_GROUP --location $LOCATION
   

2. Создайте кластер AKS с управляемой интеграцией Microsoft Entra и управляемой авторизацией Entra ID с помощью команды az aks create.

   export CLUSTER_NAME=<cluster-name>
   
   az aks create \
       --resource-group $RESOURCE_GROUP \
       --name $CLUSTER_NAME \
       --enable-aad \
       --enable-azure-rbac \
       --generate-ssh-keys
   

   Ваш результат должен быть похож на следующий пример результата:

   "AADProfile": {
       "adminGroupObjectIds": null,
       "clientAppId": null,
       "enableAzureRbac": true,
       "managed": true,
       "serverAppId": null,
       "serverAppSecret": null,
       "tenantId": "****-****-****-****-****"
   }
   

Включение авторизации Entra ID в существующем кластере AKS

• Включите авторизацию Entra ID для API Kubernetes в существующем кластере AKS с помощью команды az aks update и флага --enable-azure-rbac.

  az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --enable-azure-rbac
  

Встроенные роли AKS

AKS предоставляет следующие встроенные роли:

Создание назначений ролей для доступа к кластеру

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

Для встроенных ресурсов Kubernetes настраиваемые определения ролей ссылались на соответствующее действие группы API в разделе Microsoft.ContainerService/managedClusters/. В следующем примере пользователь может читать только развертывания и ничего другого. Полный список возможных действий см. в разделе "Операции Microsoft.ContainerService". Сведения о фильтрации доступа к определенным группам или типам настраиваемых ресурсов см. в статье "Ограничение доступа к пользовательским ресурсам с помощью условий ABAC " далее в этой статье.

1. Чтобы создать собственные определения пользовательских ролей, скопируйте следующий файл, заменив <YOUR SUBSCRIPTION ID> собственный идентификатор подписки, а затем сохраните его как deploy-view.json.

   {
       "Name": "AKS Deployment Reader",
       "Description": "Lets you view all deployments in cluster/namespace.",
       "Actions": [],
       "NotActions": [],
       "DataActions": [
           "Microsoft.ContainerService/managedClusters/apps/deployments/read"
       ],
       "NotDataActions": [],
       "assignableScopes": [
           "/subscriptions/<YOUR SUBSCRIPTION ID>"
       ]
   }
   

2. Создайте определение роли, используя команду az role definition create, установите --role-definition на файл deploy-view.json, который вы создали на предыдущем шаге.

   az role definition create --role-definition @deploy-view.json 
   

3. Назначьте определение роли пользователю или другому удостоверению с помощью az role assignment create команды.

   az role assignment create --role "AKS Deployment Reader" --assignee <AAD-ENTITY-ID> --scope $AKS_ID
   

Ограничение доступа к пользовательским ресурсам с помощью условий ABAC (предварительная версия)

Условия ABAC позволяют отбирать назначения ролей Entra ID для определенных групп и типов настраиваемых ресурсов (CRD) — централизованно из системы идентификации Microsoft Entra, без необходимости писать манифесты Role и RoleBinding для Kubernetes RBAC на уровне кластера. Дополнительные сведения о azure ABAC см. в статье "Что такое условия назначения ролей Azure?".

Когда следует использовать условия ABAC

Используйте эту функцию, если вы хотите:

• Ограничьте, какие группы CRD или типы может перечислить или получить назначенный пользователь.
• Централизованно обеспечивайте границы доступа к пользовательским ресурсам с помощью Microsoft Entra ID, без необходимости управления объектами RBAC Role и RoleBinding на каждом кластере.
• Различать между CRD, публикуемыми различными операторами (например, разрешить secrets-store.csi.x-k8s.io, блокируя security.istio.io).

Доступные атрибуты условия

При составлении условий для API Kubernetes в кластере AKS доступны следующие атрибуты запроса:

Добавьте условие ABAC к назначению роли

В следующем примере создается пользовательская роль Читатель AKS CRD, которая предоставляет доступ на чтение к пользовательским ресурсам, а затем назначается с условием, которое разрешает доступ secretproviderclasses только в secrets-store.csi.x-k8s.io группе (CRD, используемый поставщиком Azure Key Vault для драйвера CSI Хранилища секретов).

1. Сохраните следующее определение роли в файл с именем crd-reader.json, заменив <YOUR SUBSCRIPTION ID> его собственным идентификатором подписки.

   {
       "Name": "AKS CRD Reader",
       "Description": "Lets you read custom resources in the cluster.",
       "Actions": [],
       "NotActions": [],
       "DataActions": [
           "Microsoft.ContainerService/managedClusters/customresources/read"
       ],
       "NotDataActions": [],
       "assignableScopes": [
           "/subscriptions/<YOUR SUBSCRIPTION ID>"
       ]
   }
   

2. Создайте определение роли с помощью az role definition create команды.

   az role definition create --role-definition @crd-reader.json
   

3. Сохраните следующее условие в файл с именем abac-condition.txt. Условие позволяет некастомизированным ресурсам выполнять операции чтения без изменений, а операции чтения пользовательских ресурсов ограничивает определенной группой и типом.

   (
    (
     !(ActionMatches{'Microsoft.ContainerService/managedClusters/customresources/read'})
    )
    OR
    (
     @Request[Microsoft.ContainerService/managedClusters/customResources:group] StringEqualsIgnoreCase 'secrets-store.csi.x-k8s.io'
     AND
     @Request[Microsoft.ContainerService/managedClusters/customResources:kind] StringEqualsIgnoreCase 'secretproviderclasses'
    )
   )
   

4. Создайте назначение роли с условием, используя команду az role assignment create.

   az role assignment create \
       --role "AKS CRD Reader" \
       --assignee <AAD-ENTITY-ID> \
       --scope $AKS_ID \
       --condition "$(cat abac-condition.txt)" \
       --condition-version "2.0" \
       --description "Allow reads on SecretProviderClass resources only"
   

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

Проверьте условие

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

1. Получите учетные данные кластера с помощью az aks get-credentials команды.

   az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME
   

2. Список secretproviderclasses из secrets-store.csi.x-k8s.io группы, в которой разрешено условие. Команда должна успешно выполниться и вернуть либо существующие ресурсы, либо пустой список (или ошибку 'не найдено', если CRD не установлен на кластере).

   kubectl get secretproviderclasses.secrets-store.csi.x-k8s.io --all-namespaces
   

3. Список authorizationpolicies из группы Istio security.istio.io, который блокирует условие. Команда должна завершиться ошибкой Forbidden из веб-перехватчика авторизации Entra ID (при условии, что Istio CRD установлен в кластере; в противном случае kubectl возвращается ошибка 'не найден' до того, как сервер API достигнет веб-перехватчика авторизации).

   kubectl get authorizationpolicies.security.istio.io --all-namespaces
   

Очистите ресурсы

Отключение авторизации Entra ID

• Удалите авторизацию Entra ID с помощью команды az aks update с флагом --disable-azure-rbac.

  az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --disable-azure-rbac
  

Удаление назначения роли

Удаление определения роли

• Удалите определение пользовательской роли с помощью az role definition delete команды.

  az role definition delete --name "AKS Deployment Reader"
  

Удаление группы ресурсов и кластера AKS

Дальнейшие действия

Дополнительные сведения о проверке подлинности AKS, авторизации, Kubernetes RBAC и Azure RBAC см. в следующем разделе:

• Основные понятия авторизации кластера для AKS
• параметры доступа и удостоверения для AKS
• Что такое Azure RBAC?
• Что такое условия Azure ABAC?
• Операции Microsoft.ContainerService