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


Использование субъекта-службы со службой Azure Kubernetes

Для кластера AKS требуется субъект-служба Microsoft Entra или управляемое удостоверение для динамического создания других ресурсов Azure, например Azure Load Balancer или Реестр контейнеров Azure (ACR).

Для оптимальной безопасности и простоты использования корпорация Майкрософт рекомендует использовать управляемые удостоверения, а не субъекты-службы для авторизации доступа из кластера AKS к другим ресурсам в Azure. Управляемое удостоверение — это особый тип субъекта-службы, который можно использовать для получения учетных данных Microsoft Entra без необходимости управлять и защищать учетные данные. Дополнительные сведения об использовании управляемого удостоверения с кластером см. в статье "Использование управляемого удостоверения в AKS".

В этой статье показано, как создать и использовать субъект-службу с кластерами AKS.

Подготовка к работе

Чтобы создать субъект-службу Microsoft Entra, необходимо иметь разрешения на регистрацию приложения в клиенте Microsoft Entra и назначение приложения роли в подписке. Если у вас нет необходимых разрешений, необходимо попросить администратора microsoft Entra ID или подписки назначить необходимые разрешения или предварительно создать субъект-службу для использования с кластером AKS.

Если вы используете субъект-службу из другого клиента Microsoft Entra, при развертывании кластера существуют другие рекомендации. Возможно, у вас нет необходимых разрешений для чтения и записи данных из каталога. Дополнительные сведения см. в статье о том, какие разрешения пользователей по умолчанию доступны в идентификаторе Microsoft Entra ID?

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

  • При использовании Azure CLI требуется Azure CLI версии 2.0.59 или более поздней. Чтобы узнать версию, выполните команду az --version. Если вам необходимо выполнить установку или обновление, см. статью Установка Azure CLI 2.0.
  • Если вы используете Azure PowerShell, вам потребуется Azure PowerShell версии 5.0.0 или более поздней. Чтобы узнать версию, выполните команду Get-InstalledModule -Name Az. Если вам необходимо выполнить установку или обновление, см. статью об установке модуля Azure Az PowerShell.

Создание субъекта-службы

Создайте субъект-службу перед созданием кластера.

  1. Создайте субъект-службу с помощью az ad sp create-for-rbac команды.

    az ad sp create-for-rbac --name myAKSClusterServicePrincipal
    

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

    {
      "appId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
      "displayName": "myAKSClusterServicePrincipal",
      "name": "http://myAKSClusterServicePrincipal",
      "password": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
      "tenant": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
    }
    
  2. Скопируйте значения для appId выходных данных и password из нее. Они используются при создании кластера AKS в следующем разделе.

Указание субъект-службы для кластера AKS

  • Используйте существующий субъект-службу для нового кластера AKS с помощью az aks create команды и используйте --client-secret --service-principal параметры, чтобы указать appId выходные password данные, полученные в предыдущем разделе.

    az aks create \
        --resource-group myResourceGroup \
        --name myAKSCluster \
        --service-principal <appId> \
        --client-secret <password> \
        --generate-ssh-keys
    

    Примечание.

    Если вы используете существующий субъект-службу с настроенным секретом, убедитесь, что секрет не превышает 190 байт.

Делегирование прав доступа другим ресурсам Azure

Чтобы получить доступ к другим ресурсам, можно использовать субъект-службу для кластера AKS. Например, если вы хотите развернуть кластер AKS в существующей подсети виртуальной сети Azure, подключитесь к Реестр контейнеров Azure (ACR) или ключи доступа или секреты в хранилище ключей из кластера, необходимо делегировать доступ к этим ресурсам субъекту-службе. Чтобы делегировать доступ, назначьте роль управления доступом на основе ролей Azure (Azure RBAC) субъекту-службе.

Внимание

Для распространения разрешений, предоставленных субъекту-службе, связанному с кластером, может потребоваться 60 минут.

  • Создайте назначение роли с помощью az role assignment create команды. Укажите значение идентификатора приложения субъекта-службы для appId параметра. Укажите область назначения роли, например группу ресурсов или ресурс виртуальной сети. Назначение роли определяет, какие разрешения у субъекта-службы есть в ресурсе и в какой области.

    Например, чтобы назначить субъекту-службе разрешения на доступ к секретам в хранилище ключей, можно использовать следующую команду:

    az role assignment create \
        --assignee <appId> \
        --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>" \
        --role "Key Vault Secrets User"
    

    Примечание.

    Для --scope ресурса должен быть полный идентификатор ресурса, например /subscriptions/<guid>/resourceGroups/myResourceGroup или /subscriptions/guid>/resourceGroups/<myResourceGroupVnet/providers/Microsoft.Network/virtualNetworks/myVnet.

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

Реестр контейнеров Azure

Если вы используете Реестр контейнеров Azure (ACR) как хранилище образов контейнера, необходимо предоставить субъекту-службе разрешения для кластера AKS на чтение и извлечение образов. Мы рекомендуем использовать az aks create или az aks update команду для интеграции с реестром и назначить соответствующую роль субъекту-службе. Подробные инструкции см. в разделе Аутентификация с помощью Реестра контейнеров Azure из службы контейнеров Azure.

Сеть

Вы можете использовать расширенное сетевое взаимодействие, где виртуальная сеть и подсеть или общедоступные IP-адреса находятся в другой группе ресурсов. Назначьте встроенную роль Участник сетей в подсети виртуальной сети. Кроме того, можно создать настраиваемую роль с разрешениями на доступ к сетевым ресурсам в этой группе ресурсов. Дополнительные сведения см. в разделе Разрешения службы AKS.

Хранилище

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

Экземпляры контейнеров Azure

Если вы используете интеграцию Virtual Kubelet и AKS и решили запустить службу "Экземпляры контейнеров Azure" (ACI) в группе ресурсов, отличной от группы для кластера AKS, предоставьте субъекту-службе кластера AKS разрешения Участник на доступ к группе ресурсов ACI.

Другие вопросы

При использовании AKS и субъекта-службы Microsoft Entra рассмотрите следующее:

  • Субъект-служба для Kubernetes является частью конфигурации кластера, но не используйте это удостоверение для развертывания кластера.
  • По умолчанию учетные данные субъекта-службы действительны в течение одного года. Вы можете обновить или сменить учетные данные субъекта-службы в любое время.
  • Каждый субъект-служба связан с приложением Microsoft Entra. Субъект-службу для кластера Kubernetes можно связать с любым допустимым именем приложения Microsoft Entra (например: https://www.contoso.org/example). URL-адрес приложения не обязательно должен быть реальной конечной точкой.
  • При указании идентификатора клиента субъект-службы используйте значение appId.
  • На виртуальных машинах узла агента в кластере Kubernetes учетные данные субъекта-службы хранятся в /etc/kubernetes/azure.json файле.
  • При удалении кластера AKS, созданного с помощью az aks create команды, созданный субъект-служба не удаляется автоматически.
    • Чтобы удалить субъект-службу, выполните запрос к servicePrincipalProfile.clientId кластера и удалите его с помощью az ad sp delete команды. Замените значения параметра -g для имени группы ресурсов и -n параметра для имени кластера:

      az ad sp delete --id $(az aks show \
        --resource-group myResourceGroup \
        --name myAKSCluster \
        --query servicePrincipalProfile.clientId \
        --output tsv)
      

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

Azure CLI кэширует учетные данные субъекта-службы для кластеров AKS. Если срок действия этих учетных данных истекает, во время развертывания кластера AKS могут возникнуть ошибки. Если вы выполните az aks create команду и получите сообщение об ошибке, аналогичное приведенному ниже, это может указывать на проблему с учетными данными кэшированного субъекта-службы:

Operation failed with status: 'Bad Request'.
Details: The credentials in ServicePrincipalProfile were invalid. Please see https://aka.ms/aks-sp-help for more details.
(Details: adal: Refresh request failed. Status Code = '401'.

Вы можете проверить дату окончания срока действия учетных данных субъекта-службы с помощью az ad app credential list команды с запросом "[].endDateTime" .

az ad app credential list \
    --id <app-id> \
    --query "[].endDateTime" \
    --output tsv

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

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

Azure CLI может выполняться в нескольких средах оболочки, но с небольшими вариантами формата. Если вы столкнулись с непредвиденными результатами команд Azure CLI, см. статью Как успешно использовать Azure CLI.

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

Дополнительные сведения о субъектах-службах Microsoft Entra см. в разделе "Объекты приложения и субъекта-службы".

Сведения об обновлении учетных данных см. в статье Обновление или смена учетных данных субъекта-службы в AKS.