Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Для кластера 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.
Создание субъекта-службы
Создайте субъект-службу перед созданием кластера.
Создайте служебный принципал с помощью команды
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" }
Скопируйте значения
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.
Хранилище
Если вам нужно получить доступ к существующим ресурсам диска в другой группе ресурсов, назначьте один из следующих наборов разрешений роли:
- Создайте пользовательскую роль и определите разрешения Microsoft.Compute/disks/read и Microsoft.Compute/disks/write роли, или
- В группе ресурсов назначьте встроенную роль участника виртуальной машины.
Экземпляры контейнеров 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.
Azure Kubernetes Service