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


Использование служебного принципала с Azure Kubernetes Service (AKS)

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

Для оптимальной безопасности и простоты использования Microsoft рекомендует использовать управляемые удостоверения, а не служебные принципы для авторизации доступа из кластера 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 и параметры --service-principal и --client-secret, чтобы указать 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 разрешения на чтение и извлечение (pull) образов. Мы рекомендуем использовать команду 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.