Hizmet sorumlularıyla Azure Container Registry kimlik doğrulaması

Kapsayıcı kayıt defterinize gönderme, çekme veya başka erişim sağlamak için Bir Microsoft Entra hizmet sorumlusu kullanabilirsiniz. Hizmet sorumlusu kullanarak "başsız" hizmetlere ve uygulamalara erişim sağlayabilirsiniz.

Hizmet sorumlusu nedir?

Microsoft Entra ID hizmet sorumluları , aboneliğinizdeki Azure kaynaklarına erişim sağlar. Hizmet sorumlusunu bir hizmet için kullanıcı kimliği olarak düşünebilirsiniz; burada "hizmet", kaynaklara erişmesi gereken herhangi bir uygulama, hizmet veya platformdur. Erişim haklarının kapsamı yalnızca belirttiğiniz kaynaklarla belirlenmiş bir hizmet sorumlusu yapılandırabilirsiniz. Ardından uygulamanızı veya hizmetinizi bu kaynaklara erişmek için hizmet sorumlusunun kimlik bilgilerini kullanacak şekilde yapılandırın.

Azure Container Registry bağlamında, Azure'daki özel kayıt defterinize yönelik çekme, gönderme ve çekme veya diğer izinlerle bir Microsoft Entra hizmet sorumlusu oluşturabilirsiniz. Tam liste için bkz . Azure Container Registry rolleri ve izinleri.

Hizmet sorumlusu neden kullanılır?

Microsoft Entra hizmet sorumlusu kullanarak özel kapsayıcı kayıt defterinize kapsamlı erişim sağlayabilirsiniz. Her biri kayıt defterinize özel erişim haklarına sahip her uygulama veya hizmetiniz için farklı hizmet sorumluları oluşturun. Ayrıca, hizmetler ve uygulamalar arasında kimlik bilgilerinin paylaşılmasını önleyebileceğiniz için, kimlik bilgilerini döndürebilir veya yalnızca seçtiğiniz hizmet sorumlusu (ve dolayısıyla uygulama) için erişimi iptal edebilirsiniz.

Örneğin, derleme sisteminiz hem hem de pushpull erişim sağlayan bir hizmet sorumlusu kullanırken, web uygulamanızı yalnızca görüntü pull erişimi sağlayan bir hizmet sorumlusu kullanacak şekilde yapılandırın. Uygulamanızın geliştirilmesi el değiştirirse, derleme sistemini etkilemeden hizmet sorumlusu kimlik bilgilerini döndürebilirsiniz.

Hizmet sorumlusu ne zaman kullanılır?

Başsız senaryolarda kayıt defteri erişimi sağlamak için bir hizmet sorumlusu kullanmanız gerekir. Başka bir ifadeyle, kapsayıcı görüntülerini otomatik veya başka bir şekilde katılımsız bir şekilde göndermesi veya çekmesi gereken bir uygulama, hizmet veya betik. Örneğin:

  • Çekme: Kapsayıcıları bir kayıt defterinden Kubernetes, DC/OS ve Docker Swarm gibi düzenleme sistemlerine dağıtın. Kapsayıcı kayıt defterlerinden App Service, Batch, Service Fabric ve diğerleri gibi ilgili Azure hizmetlerine de çekebilirsiniz.

    İpucu

    Azure kapsayıcı kayıt defterinden görüntü çekmek için çeşitli Kubernetes senaryolarında hizmet sorumlusu önerilir. Azure Kubernetes Service (AKS) ile, kümenin yönetilen kimliğini etkinleştirerek hedef kayıt defteriyle kimlik doğrulaması yapmak için otomatik bir mekanizma da kullanabilirsiniz.

    • Gönderme: Azure Pipelines veya Jenkins gibi sürekli tümleştirme ve dağıtım çözümlerini kullanarak kapsayıcı görüntüleri oluşturun ve bunları bir kayıt defterine gönderin.

Bir kayıt defterine bireysel erişim için, örneğin geliştirme iş istasyonunuza el ile bir kapsayıcı görüntüsü çektiğinizde, kayıt defteri erişimi için kendi Microsoft Entra kimliğinizi kullanmanızı öneririz (örneğin, az acr login ile).

Hizmet sorumlusu oluşturma

Kapsayıcı kayıt defterinize erişimi olan bir hizmet sorumlusu oluşturmak için Azure Cloud Shell'de aşağıdaki betiği veya Azure CLI'nın yerel yüklemesini çalıştırın. Betik Bash kabuğu için biçimlendirilir.

Betiği çalıştırmadan önce değişkeni kapsayıcı kayıt defterinizin adıyla güncelleştirin ACR_NAME . Değer SERVICE_PRINCIPAL_NAME , Microsoft Entra kiracınızda benzersiz olmalıdır. "'http://acr-service-principal' already exists." hatası alırsanız hizmet sorumlusu için farklı bir ad belirtin.

Farklı izinler vermek istiyorsanız, isteğe bağlı olarak az ad sp create-for-rbac komutundaki değeri değiştirebilirsiniz--role. Rollerin tam listesi için bkz . ACR rolleri ve izinleri.

Betiği çalıştırdıktan sonra hizmet sorumlusunun kimliğini ve parolasını not alın. Kimlik bilgilerine sahip olduktan sonra, uygulama ve hizmetlerinizi hizmet sorumlusu olarak kapsayıcı kayıt defterinizde kimlik doğrulaması yapmak üzere yapılandırabilirsiniz.

#!/bin/bash
# This script requires Azure CLI version 2.25.0 or later. Check version with `az --version`.

# Modify for your environment.
# ACR_NAME: The name of your Azure Container Registry
# SERVICE_PRINCIPAL_NAME: Must be unique within your AD tenant
ACR_NAME=$containerRegistry
SERVICE_PRINCIPAL_NAME=$servicePrincipal

# Obtain the full registry ID
ACR_REGISTRY_ID=$(az acr show --name $ACR_NAME --query "id" --output tsv)
# echo $registryId

# Create the service principal with rights scoped to the registry.
# Default permissions are for docker pull access. Modify the '--role'
# argument value as desired:
# acrpull:     pull only
# acrpush:     push and pull
# owner:       push, pull, and assign roles
PASSWORD=$(az ad sp create-for-rbac --name $SERVICE_PRINCIPAL_NAME --scopes $ACR_REGISTRY_ID --role acrpull --query "password" --output tsv)
USER_NAME=$(az ad sp list --display-name $SERVICE_PRINCIPAL_NAME --query "[].appId" --output tsv)

# Output the service principal's credentials; use these in your services and
# applications to authenticate to the container registry.
echo "Service principal ID: $USER_NAME"
echo "Service principal password: $PASSWORD"

Mevcut hizmet sorumlusunu kullanma

Mevcut hizmet sorumlusuna kayıt defteri erişimi vermek için hizmet sorumlusuna yeni bir rol atamanız gerekir. Yeni bir hizmet sorumlusu oluştururken olduğu gibi çekme, gönderme ve çekme ve sahip erişimi de ve diğerleri arasında yer alabilirsiniz.

Aşağıdaki betik, değişkende SERVICE_PRINCIPAL_ID belirttiğiniz bir hizmet sorumlusuna çekme izinleri vermek için az role assignment create komutunu kullanır. --role Farklı bir erişim düzeyi vermek istiyorsanız değeri ayarlayın.

#!/bin/bash
# Modify for your environment. The ACR_NAME is the name of your Azure Container
# Registry, and the SERVICE_PRINCIPAL_ID is the service principal's 'appId' or
# one of its 'servicePrincipalNames' values.
ACR_NAME=$containerRegistry
SERVICE_PRINCIPAL_ID=$servicePrincipal

# Populate value required for subsequent command args
ACR_REGISTRY_ID=$(az acr show --name $ACR_NAME --query id --output tsv)

# Assign the desired role to the service principal. Modify the '--role' argument
# value as desired:
# acrpull:     pull only
# acrpush:     push and pull
# owner:       push, pull, and assign roles
az role assignment create --assignee $SERVICE_PRINCIPAL_ID --scope $ACR_REGISTRY_ID --role acrpull

Örnek betikler

GitHub'da Azure CLI için önceki örnek betiklerin yanı sıra Azure PowerShell sürümlerini bulabilirsiniz:

Hizmet sorumlusuyla kimlik doğrulaması

Kapsayıcı kayıt defterinize erişim izni vermiş olduğunuz bir hizmet sorumlunuz olduğunda, "başsız" hizmetlere ve uygulamalara erişim için kimlik bilgilerini yapılandırabilir veya komutunu kullanarak docker login bunları girebilirsiniz. Aşağıdaki değerleri kullanın:

  • Kullanıcı adı - hizmet sorumlusu uygulama (istemci) kimliği
  • Parola - hizmet sorumlusu parolası (istemci gizli dizisi)

Kullanıcı adı değeri biçimindedirxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.

İpucu

az ad sp credential reset komutunu çalıştırarak hizmet sorumlusunun parolasını (istemci gizli dizisi) yeniden oluşturabilirsiniz.

Azure hizmetleriyle kimlik bilgilerini kullanma

Azure kapsayıcı kayıt defteriyle kimlik doğrulaması yapılan herhangi bir Azure hizmetinden hizmet sorumlusu kimlik bilgilerini kullanabilirsiniz. Çeşitli senaryolar için kayıt defterinin yönetici kimlik bilgileri yerine hizmet sorumlusu kimlik bilgilerini kullanın.

Docker oturum açma bilgileriyle kullanma

Bir hizmet sorumlusu kullanarak çalıştırabilirsiniz docker login . Aşağıdaki örnekte, hizmet sorumlusu uygulama kimliği ortam değişkenine $SP_APP_IDve parola değişkenine $SP_PASSWDgeçirilir. Docker kimlik bilgilerini yönetmeye yönelik önerilen uygulamalar için docker oturum açma komutu başvurusuna bakın.

# Log in to Docker with service principal credentials
docker login myregistry.azurecr.io --username $SP_APP_ID --password $SP_PASSWD

Oturum açtıktan sonra Docker kimlik bilgilerini önbelleğe alır.

Sertifika ile kullanma

Hizmet sorumlunuza bir sertifika eklediyseniz, sertifika tabanlı kimlik doğrulamasıyla Azure CLI'da oturum açabilir ve ardından bir kayıt defterine erişmek için az acr login komutunu kullanabilirsiniz. Sertifikayı parola yerine gizli dizi olarak kullanmak, CLI kullandığınızda ek güvenlik sağlar.

Bir hizmet sorumlusu oluşturduğunuzda otomatik olarak imzalanan bir sertifika oluşturulabilir. Veya var olan bir hizmet sorumlusuna bir veya daha fazla sertifika ekleyin. Örneğin, bir hizmet sorumlusunu kayıt defterinden görüntü çekme veya gönderme haklarıyla oluşturmak veya güncelleştirmek için bu makaledeki betiklerden birini kullanıyorsanız az ad sp credential reset komutunu kullanarak bir sertifika ekleyin.

Azure CLI'da oturum açmak için hizmet sorumlusunu sertifikayla kullanmak için sertifikaNıN PEM biçiminde olması ve özel anahtarı içermesi gerekir. Sertifikanız gerekli biçimde değilse, bunu dönüştürmek için gibi openssl bir araç kullanın. Hizmet sorumlusunu kullanarak CLI'da oturum açmak için az login komutunu çalıştırdığınızda, hizmet sorumlusunun uygulama kimliğini ve Active Directory kiracı kimliğini de sağlayın. Aşağıdaki örnekte bu değerler ortam değişkenleri olarak gösterilmektedir:

az login --service-principal --username $SP_APP_ID --tenant $SP_TENANT_ID  --password /path/to/cert/pem/file

Ardından, kayıt defteriyle kimlik doğrulaması yapmak için az acr login komutunu çalıştırın:

az acr login --name myregistry

CLI, kayıt defteriyle oturumunuzun kimliğini doğrulamak için çalıştırdığınızda az login oluşturulan belirteci kullanır.

Kiracılar arası senaryolar için hizmet sorumlusu oluşturma

Hizmet sorumlusu, bir Microsoft Entra Kimliği'ndeki (kiracı) kapsayıcı kayıt defterinden başka bir hizmet veya uygulamaya görüntü çekmeyi gerektiren Azure senaryolarında da kullanılabilir. Örneğin, bir kuruluş A Kiracısı'nda B Kiracısı'ndaki paylaşılan bir kapsayıcı kayıt defterinden görüntü çekmesi gereken bir uygulama çalıştırabilir.

Kiracılar arası bir senaryoda kapsayıcı kayıt defteriyle kimlik doğrulaması yapabilecek bir hizmet sorumlusu oluşturmak için:

  • Kiracı A'da çok kiracılı uygulama (hizmet sorumlusu) oluşturma
  • Uygulamayı B Kiracısında sağlama
  • Hizmet sorumlusuna B Kiracısı'ndaki kayıt defterinden çekme izinleri verme
  • Yeni hizmet sorumlusunu kullanarak kimlik doğrulaması yapmak için A Kiracısı'ndaki hizmeti veya uygulamayı güncelleştirme

Örneğin, bkz . Kapsayıcı kayıt defterinden farklı bir AD kiracısında AKS kümesine görüntü çekme.

Hizmet sorumlusu yenilemesi

Hizmet sorumlusu bir yıllık geçerlilik ile oluşturulur. Geçerliliği bir yıldan daha fazla uzatma seçenekleriniz vardır veya komutunu kullanarak az ad sp credential reset seçtiğiniz süre sonu tarihini sağlayabilirsiniz.

Sonraki adımlar