Microsoft Entra 서비스 계정을 사용하여 컨테이너 레지스트리에 대한 푸시, 풀 또는 기타 접근 권한을 부여할 수 있습니다. 서비스 주체를 사용하면 "헤드리스" 서비스 및 애플리케이션에 대한 액세스를 제공할 수 있습니다.
서비스 계정이란 무엇인가요?
Microsoft Entra ID 서비스 계정은 사용자의 구독 내 Azure 리소스에 접근할 수 있는 권한을 제공합니다. 서비스 계정은 리소스에 접근해야 하는 애플리케이션, 서비스 또는 플랫폼과 같은 “서비스”를 위한 사용자 계정이라고 생각할 수 있습니다. 서비스 계정에는 사용자가 지정한 특정 리소스에 대해서만 접근 권한이 부여되도록 설정할 수 있습니다. 그런 다음 애플리케이션이나 서비스가 해당 리소스에 접근할 수 있도록 서비스 계정의 자격 증명을 사용하도록 구성합니다.
Azure Container Registry의 경우, 사용자의 Azure 개인 레지스트리에 대해 가져오기, 푸시 및 가져오기, 또는 기타 권한을 가진 Microsoft Entra 서비스 계정을 생성할 수 있습니다. 전체 목록은 Azure Container Registry Entra 권한 및 역할 개요를 참조하세요.
서비스 계정을 사용하는 이유는 무엇인가요?
Microsoft Entra 서비스 계정을 사용하면 개인 컨테이너 레지스트리에 대해 제한된 범위의 접근 권한을 부여할 수 있습니다. 각 애플리케이션이나 서비스마다 별도의 서비스 계정을 생성하고, 레지스트리에 대한 접근 권한을 각각 맞춤 설정하는 것이 좋습니다. 또한 서비스와 애플리케이션 간에 자격 증명을 공유하지 않아도 되므로, 원하는 서비스 계정(즉, 해당 애플리케이션)에 대해서만 자격 증명을 교체하거나 접근 권한을 철회할 수 있습니다.
예를 들어 웹 애플리케이션에는 이미지 pull 접근 권한만 제공하는 서비스 계정을 사용하도록 구성하고, 빌드 시스템에는 push와 pull 접근 권한을 모두 제공하는 서비스 계정을 사용하도록 구성할 수 있습니다. 애플리케이션 개발 팀 인력에 변화가 있으면, 빌드 시스템에 영향을 주지 않으면서 서비스 주체 자격 증명을 순환할 수 있습니다.
서비스 주체를 사용하는 경우
헤드리스 시나리오에서 레지스트리 접근을 제공하기 위해 서비스 계정을 사용해야 합니다. 즉, 컨테이너 이미지를 자동화된 방식으로 또는 다른 형태로 무인 상태에서 푸시하거나 풀해야 하는 애플리케이션, 서비스, 또는 스크립트를 의미합니다. 예를 들어:
가져오기: Kubernetes, DC/OS, Docker Swarm 등과 같은 오케스트레이션 시스템으로 레지스트리에서 컨테이너를 배포합니다. 또한 레지스트리에서 App Service, Batch, Service Fabric 등과 같은 관련 Azure 서비스로 이미지를 가져올 수도 있습니다.
팁
Azure 컨테이너 레지스트리에서 이미지를 가져오기 위해 여러 Kubernetes 시나리오에서는 서비스 계정을 사용하는 것이 권장됩니다. AKS(Azure Kubernetes Service)를 사용하면 자동화된 메커니즘을 사용해 클러스터의 관리 ID를 사용하도록 설정하여 대상 레지스트리를 인증할 수도 있습니다.
- Push: 컨테이너 이미지를 빌드하고 Azure Pipelines 또는 Jenkins와 같은 지속적 통합 및 배포 솔루션을 사용하여 레지스트리에 푸시합니다.
레지스트리에 개별적으로 접근할 때, 예를 들어 개발 워크스테이션으로 컨테이너 이미지를 수동으로 가져오는 경우에는 레지스트리 접근을 위해 개인 Microsoft Entra 계정을 사용하는 것이 권장됩니다(예: az acr login 사용).
서비스 주체 만들기
사용자의 컨테이너 레지스트리에 접근할 수 있는 서비스 계정을 생성하려면 Azure Cloud Shell 또는 로컬에 설치된 Azure CLI에서 다음 스크립트를 실행합니다. 이 스크립트는 Bash 셸 환경에 맞게 작성되어 있습니다.
스크립트를 실행하기 전에 ACR_NAME 변수 값을 사용자의 컨테이너 레지스트리 이름으로 수정해야 합니다.
SERVICE_PRINCIPAL_NAME 값은 사용자의 Microsoft Entra 테넌트 내에서 고유해야 합니다. "'http://acr-service-principal' already exists." 오류가 발생하는 경우에는 서비스 계정에 대해 다른 이름을 지정해야 합니다.
필요에 따라 --role 명령의 값을 수정 하여 다른 권한을 부여할 수 있습니다. 역할의 전체 목록은 Azure Container Registry Entra 권한 및 역할 개요를 참조하세요.
스크립트를 실행한 후에는 서비스 계정의 ID와 비밀번호 값을 기록해 두어야 합니다. 자격 증명이 있으면 컨테이너 레지스트리를 서비스 주체로 인증하도록 애플리케이션과 서비스를 구성할 수 있습니다.
#!/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"
기존에 생성된 서비스 계정을 사용합니다.
기존 서비스 주체에 레지스트리 액세스 권한을 부여하려면 서비스 주체에 새 역할을 할당해야 합니다. 새 서비스 주체를 만드는 것과 마찬가지로 역할 할당을 수행하여 서비스 주체에 권한을 부여해야 합니다. Azure Container Registry Entra 권한 및 역할 개요를 참조하세요.
다음 스크립트는 az role assignment create 명령을 사용하여 변수에 SERVICE_PRINCIPAL_ID 지정한 서비스 주체에 끌어오기 권한을 부여합니다. 다른 수준의 접근 권한을 부여하려는 경우에는 --role 값을 적절하게 조정합니다.
#!/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
샘플 스크립트
GitHub에서 Azure CLI에 대한 이전 샘플 스크립트 및 Azure PowerShell에 대한 버전을 찾을 수 있습니다.
서비스 계정으로 인증하기
컨테이너 레지스트리에 대한 액세스 권한이 부여된 서비스 주체가 있으면 "헤드리스" 서비스 및 애플리케이션에 액세스하기 위한 자격 증명을 구성하거나 docker login 명령을 사용하여 해당 자격 증명을 입력할 수 있습니다. 다음 값을 사용합니다.
- 사용자 이름 - 서비스 계정의 애플리케이션(클라이언트) ID
- 암호 - 서비스 주체의 암호(클라이언트 암호)
사용자 이름 값의 형식은 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx입니다.
팁
az ad sp credential reset 명령을 실행하여 서비스 주체의 암호(클라이언트 암호)를 다시 생성할 수 있습니다.
Azure 서비스에서 자격 증명을 사용합니다.
Azure 컨테이너 레지스트리와 인증하는 모든 Azure 서비스에서 서비스 계정 자격 증명을 사용할 수 있습니다. 여러 시나리오에서 레지스트리의 관리자 자격 증명 대신 서비스 계정 자격 증명을 사용할 수 있습니다.
Docker login에서 사용하기
서비스 계정을 사용하여 docker login를 실행할 수 있습니다. 다음 예제에서 서비스 주체 애플리케이션 ID는 환경 변수 $SP_APP_ID로 전달되고 암호는 변수 $SP_PASSWD로 전달됩니다. Docker 자격 증명을 관리하기 위한 권장 방법은 docker login 명령 참조를 확인하십시오.
# Log in to Docker with service principal credentials
docker login myregistry.azurecr.io --username $SP_APP_ID --password $SP_PASSWD
로그인하면 Docker가 자격 증명을 캐시합니다.
인증서와 함께 사용
서비스 계정에 인증서를 추가한 경우, 인증서 기반 인증으로 Azure CLI에 로그인한 후 az acr login 명령을 사용하여 레지스트리에 접근할 수 있습니다. CLI를 사용할 때 비밀번호 대신 인증서를 비밀로 사용하면 추가적인 보안이 제공됩니다.
서비스 계정을 생성할 때 자체 서명 인증서를 만들 수 있습니다. 또는 기존 서비스 계정에 하나 이상의 인증서를 추가할 수 있습니다. 예를 들어, 이 문서의 스크립트 중 하나를 사용하여 레지스트리에서 이미지를 가져오거나 푸시할 권한이 있는 서비스 계정을 생성하거나 업데이트하는 경우, az ad sp credential reset 명령을 사용하여 인증서를 추가할 수 있습니다.
인증서가 포함된 서비스 계정을 사용하여 Azure CLI에 로그인하려면, 인증서는 PEM 형식이어야 하며 개인 키를 포함해야 합니다. 인증서가 요구되는 형식이 아닌 경우, openssl과 같은 도구를 사용하여 변환하십시오. 서비스 계정을 사용하여 CLI에 로그인하기 위해 az login을 실행할 때, 서비스 계정의 애플리케이션 ID와 Active Directory 테넌트 ID도 함께 제공해야 합니다. 다음 예제에서는 이러한 값을 환경 변수로 보여줍니다.
az login --service-principal --username $SP_APP_ID --tenant $SP_TENANT_ID --password /path/to/cert/pem/file
그런 다음, az acr login을 실행하여 레지스트리를 사용해 인증합니다.
az acr login --name myregistry
CLI는 레지스트리와의 세션을 인증하기 위해 az login을 실행할 때 생성된 토큰을 사용합니다.
교차 테넌트 시나리오에 대한 서비스 주체 만들기
서비스 계정은 하나의 Microsoft Entra ID(테넌트)에 있는 컨테이너 레지스트리에서 이미지를 가져와 다른 테넌트의 서비스나 애플리케이션에서 사용해야 하는 Azure 시나리오에서도 사용할 수 있습니다. 예를 들어, 조직에서 테넌트 A에서 애플리케이션을 실행하는데, 테넌트 B의 공유 컨테이너 레지스트리에서 이미지를 가져와야 할 수 있습니다.
다른 테넌트 간 시나리오에서 컨테이너 레지스트리와 인증할 수 있는 서비스 계정을 생성하려면:
- 테넌트 A에서 다중 테넌트 앱(서비스 계정)를 생성합니다.
- 테넌트 B에서 앱 프로비전
- 테넌트 B의 레지스트리에서 끌어올 수 있는 서비스 주체 권한 부여
- 테넌트 A의 서비스나 애플리케이션을 새로 생성한 서비스 계정을 사용하도록 인증 방식을 업데이트합니다.
예제 단계는 컨테이너 레지스트리에서 다른 AD 테넌트의 AKS 클러스터로 이미지 끌어오기를 참조하세요.
서비스 주체 갱신
서비스 주체는 1년의 유효 기간으로 만들어집니다. 유효 기간을 1년 이상 연장하거나 az ad sp credential reset 명령을 사용하여 원하는 만료 날짜를 제공할 수 있습니다.
다음 단계
Azure 컨테이너 레지스트리와 인증할 수 있는 다른 시나리오에 대해서는 인증 개요를 참조하십시오.
컨테이너 레지스트리용 서비스 계정 자격 증명을 저장하고 가져오기 위해 Azure 키 볼트를 사용하는 예제는 ACR 작업을 사용하여 컨테이너 이미지 빌드 및 배포 튜토리얼을 참조하십시오.