Аутентификация с помощью реестра контейнеров Azure из Службы Azure KubernetesAuthenticate with Azure Container Registry from Azure Kubernetes Service

При использовании реестра контейнеров Azure (ACR) со Службой Azure Kubernetes (AKS) необходимо установить механизм аутентификации.When you're using Azure Container Registry (ACR) with Azure Kubernetes Service (AKS), an authentication mechanism needs to be established. В этой статье описаны рекомендуемые конфигурации для аутентификации между этими двумя службами Azure.This article details the recommended configurations for authentication between these two Azure services.

Необходимо настроить только один из этих методов проверки подлинности.You only need to configure one of these authentication methods. Наиболее распространенным подходом является предоставление доступа с помощью субъекта-службы AKS.The most common approach is to grant access using the AKS service principal. При необходимости вы можете предоставить доступ с помощью секретов Kubernetes.If you have specific needs, you can optionally grant access using Kubernetes secrets.

В этой статье предполагается, что вы уже создали кластер AKS и у вас есть доступ к кластеру через клиент командной строки kubectl.This article assumes that you've already created an AKS cluster and you are able to access the cluster with the kubectl command-line client. Если вместо этого вы хотите создать кластер и настроить доступ к реестру контейнеров во время создания кластера, см. раздел учебник. Развертывание кластера AKS или Проверка подлинности с помощью реестра контейнеров Azure из службы Kubernetes Azure (Предварительная версия).If instead you want to create a cluster and configure access to a container registry at cluster creation time, see Tutorial: Deploy an AKS cluster or Authenticate with Azure Container Registry from Azure Kubernetes Service (preview).

Предоставление AKS доступа к ACRGrant AKS access to ACR

Когда вы создаете кластер AKS, Azure также создает субъект-службу для взаимодействия кластера с другими ресурсами Azure.When you create an AKS cluster, Azure also creates a service principal to support cluster operability with other Azure resources. Автоматически созданный субъект-службу можно использовать для аутентификации в реестре ACR.You can use this auto-generated service principal for authentication with an ACR registry. Для этого в Azure AD нужно назначить субъекту-службе кластера роль, у которой есть доступ к реестру контейнеров.To do so, you need to create an Azure AD role assignment that grants the cluster's service principal access to the container registry.

Используйте следующий скрипт для предоставления субъекту-службе, созданному службой AKS, доступа к реестру контейнеров Azure с правами на извлечение данных.Use the following script to grant the AKS-generated service principal pull access to an Azure container registry. Прежде чем выполнять этот скрипт, измените переменные AKS_* и ACR_* в соответствии с условиями своей среды.Modify the AKS_* and ACR_* variables for your environment before running the script.

#!/bin/bash

AKS_RESOURCE_GROUP=myAKSResourceGroup
AKS_CLUSTER_NAME=myAKSCluster
ACR_RESOURCE_GROUP=myACRResourceGroup
ACR_NAME=myACRRegistry

# Get the id of the service principal configured for AKS
CLIENT_ID=$(az aks show --resource-group $AKS_RESOURCE_GROUP --name $AKS_CLUSTER_NAME --query "servicePrincipalProfile.clientId" --output tsv)

# Get the ACR registry resource id
ACR_ID=$(az acr show --name $ACR_NAME --resource-group $ACR_RESOURCE_GROUP --query "id" --output tsv)

# Create role assignment
az role assignment create --assignee $CLIENT_ID --role acrpull --scope $ACR_ID

Доступ с помощью секрета KubernetesAccess with Kubernetes secret

В некоторых случаях вы не сможете назначить необходимую роль субъекту-службе, который автоматически создала служба AKS, чтобы предоставить ему доступ к ACR.In some instances, you might not be able to assign the required role to the auto-generated AKS service principal granting it access to ACR. Например, модель безопасности вашей организации может ограничивать ваши права в клиенте Azure Active Directory, необходимые для назначения роли субъекту-службе, который создала служба AKS.For example, due to your organization's security model, you might not have sufficient permissions in your Azure Active Directory tenant to assign a role to the AKS-generated service principal. Для назначения роли для субъекта-службы требуется, чтобы у учетной записи Azure AD было разрешение на запись к клиенту Azure AD.Assigning a role to a service principal requires your Azure AD account to have write permission to your Azure AD tenant. Если у вас нет такого разрешения, вы можете создать новый субъект-службу и предоставить ему доступ к реестру контейнера, используя секрет Kubernetes для получения образа.If you don't have permission, you can create a new service principal, then grant it access to the container registry using a Kubernetes image pull secret.

Создать субъект-службу можно с помощью следующего скрипта. Учетные данные этого субъекта-службы вы укажете в качестве секрета Kubernetes для получения образа.Use the following script to create a new service principal (you'll use its credentials for the Kubernetes image pull secret). Прежде чем выполнять этот скрипт, измените переменную ACR_NAME в соответствии с условиями своей среды.Modify the ACR_NAME variable for your environment before running the script.

#!/bin/bash

ACR_NAME=myacrinstance
SERVICE_PRINCIPAL_NAME=acr-service-principal

# Populate the ACR login server and resource id.
ACR_LOGIN_SERVER=$(az acr show --name $ACR_NAME --query loginServer --output tsv)
ACR_REGISTRY_ID=$(az acr show --name $ACR_NAME --query id --output tsv)

# Create acrpull role assignment with a scope of the ACR resource.
SP_PASSWD=$(az ad sp create-for-rbac --name http://$SERVICE_PRINCIPAL_NAME --role acrpull --scopes $ACR_REGISTRY_ID --query password --output tsv)

# Get the service principal client id.
CLIENT_ID=$(az ad sp show --id http://$SERVICE_PRINCIPAL_NAME --query appId --output tsv)

# Output used when creating Kubernetes secret.
echo "Service principal ID: $CLIENT_ID"
echo "Service principal password: $SP_PASSWD"

Теперь учетные данные субъекта-службы можно хранить в Kubernetesном секрете на Извлечение образа, который будет ссылаться на кластер AKS при работе с контейнерами.You can now store the service principal's credentials in a Kubernetes image pull secret, which your AKS cluster will reference when running containers.

Чтобы создать секрет Kubernetes, используйте следующую команду kubectl.Use the following kubectl command to create the Kubernetes secret. Замените <acr-login-server> полным доменным именем вашего реестра контейнеров Azure (в формате "acrname.azurecr.io").Replace <acr-login-server> with the fully qualified name of your Azure container registry (it's in the format "acrname.azurecr.io"). Замените <service-principal-ID> и <service-principal-password> значениями, полученными при выполнении предыдущего скрипта.Replace <service-principal-ID> and <service-principal-password> with the values you obtained by running the previous script. Замените <email-address> на любой адрес электронной почты правильного формата.Replace <email-address> with any well-formed email address.

kubectl create secret docker-registry acr-auth --docker-server <acr-login-server> --docker-username <service-principal-ID> --docker-password <service-principal-password> --docker-email <email-address>

Теперь вы можете использовать секрет Kubernetes в развертываниях pod, указывая его имя (в нашем примере это acr-auth) в параметре imagePullSecrets.You can now use the Kubernetes secret in pod deployments by specifying its name (in this case, "acr-auth") in the imagePullSecrets parameter:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: acr-auth-example
spec:
  template:
    metadata:
      labels:
        app: acr-auth-example
    spec:
      containers:
      - name: acr-auth-example
        image: myacrregistry.azurecr.io/acr-auth-example
      imagePullSecrets:
      - name: acr-auth