Azure DevOps에서 서비스 주체 및 관리 ID 사용

Azure DevOps Services

Microsoft Entra 서비스 주체 및 관리 ID를 애플리케이션 ID로 Azure DevOps Services 조직에 추가하여 조직 리소스에 대한 액세스 권한을 부여합니다. 대부분의 팀에서 이 기능은 회사에서 자동화 워크플로를 구동하는 애플리케이션을 인증할 때 PAT(개인용 액세스 토큰) 에 대한 실행 가능하고 선호되는 대안이 될 수 있습니다.

서비스 주체 및 관리 ID 정보

서비스 주체 는 지정된 테넌트에서 애플리케이션이 수행할 수 있는 작업을 정의하는 Microsoft Entra 애플리케이션 내의 보안 개체입니다. 애플리케이션 등록 프로세스 중에 Azure Portal에서 설정되며 Azure DevOps와 같은 Azure 리소스에 액세스하도록 구성됩니다. 조직에 서비스 주체를 추가하고 그 위에 권한을 설정하면 서비스 주체가 조직 리소스에 액세스할 수 있는 권한이 있는지 여부와 해당 리소스에 액세스할 수 있는 권한이 있는지 확인할 수 있습니다.

관리 ID 는 애플리케이션의 서비스 주체와 유사하게 작동하는 또 다른 Microsoft Entra 기능입니다. 이러한 개체는 Azure 리소스에 대한 ID를 제공하고 Microsoft Entra 인증을 지원하는 서비스에서 자격 증명을 공유하는 쉬운 방법을 허용합니다. Microsoft Entra ID가 자격 증명 관리 및 회전을 처리하므로 매력적인 옵션입니다. 관리 ID에 대한 설정은 Azure Portal에서 다르게 보일 수 있지만 Azure DevOps는 정의된 권한이 있는 조직의 새 애플리케이션 ID와 동일한 보안 개체를 처리합니다. 이 문서의 나머지 부분 전체에서는 지정하지 않는 한 관리 ID 및 서비스 주체를 서비스 주체로 상호 교환합니다.

다음 단계를 사용하여 이러한 ID를 Azure DevOps에 인증하여 스스로 작업을 수행할 수 있도록 합니다.

관리 ID 및 서비스 주체 구성

구현은 다를 수 있지만 개략적으로 다음 단계를 수행하면 워크플로에서 서비스 주체 사용을 시작하는 데 도움이 됩니다. 따라가려면 샘플 앱중 하나를 살펴보는 것이 좋습니다.

1. 새 관리 ID 또는 애플리케이션 서비스 주체 만들기

Azure Portal에서 애플리케이션 서비스 주체 또는 관리 ID 를 만듭니다.

옵션 1: 애플리케이션 서비스 주체 만들기

새 애플리케이션 등록을 만들면 애플리케이션 개체가 Microsoft Entra ID로 만들어집니다. 애플리케이션 서비스 주체는 지정된 테넌트에 대한 이 애플리케이션 개체의 표현입니다. 애플리케이션을 다중 테넌트 애플리케이션으로 등록하는 경우 애플리케이션이 추가되는 모든 테넌트의 애플리케이션 개체를 나타내는 고유한 서비스 주체 개체가 있습니다.

추가 정보:

• Microsoft Entra ID의 애플리케이션 및 서비스 주체 개체
• 서비스 주체 보안
• 포털을 사용하여 리소스에 액세스할 수 있는 Microsoft Entra 애플리케이션 및 서비스 주체 만들기

옵션 2: 관리 ID 만들기

Azure Portal에서 관리 ID를 만드는 것은 서비스 주체를 사용하여 애플리케이션을 설정하는 것과 크게 다릅니다. 만들기 프로세스를 시작하기 전에 먼저 만들려는 관리 ID 유형을 고려해야 합니다.

• 시스템 할당 관리 ID: 일부 Azure 서비스를 사용하면 서비스 인스턴스에서 직접 관리 ID를 사용하도록 설정할 수 있습니다. 시스템 할당 관리 ID를 사용하도록 설정하면 Microsoft Entra ID에서 ID가 생성됩니다. ID는 해당 서비스 인스턴스의 수명 주기와 연결됩니다. 리소스가 삭제되면 Azure에서 자동으로 ID를 삭제합니다. 의도적으로 해당 Azure 리소스만 이 ID를 사용하여 Microsoft Entra ID에서 토큰을 요청할 수 있습니다.
• 사용자 할당 관리 ID 사용자 할당 관리 ID 를 만들어서 관리 ID를 독립 실행형 Azure 리소스로 만들고 하나 이상의 Azure 서비스 인스턴스에 할당할 수도 있습니다. 사용자가 할당한 관리 ID는 이를 사용하는 리소스와 별도로 관리됩니다.

자세한 내용은 다음 문서 및 비디오를 참조하세요.

• Azure 리소스에 대한 관리 ID란?
• 사용자 할당 관리 ID 관리
• Azure Portal을 사용하여 VM에서 Azure 리소스에 대한 관리 ID 구성

2. Azure DevOps 조직에 서비스 주체 추가

Microsoft Entra 관리 센터에서 서비스 주체를 구성한 후에는 조직에 서비스 주체를 추가하여 Azure DevOps에서 동일한 작업을 수행해야 합니다. 사용자 페이지 또는 ServicePrincipalEntitlements API를 통해 추가할 수 있습니다. 대화형으로 로그인할 수 없으므로 조직, 프로젝트 또는 팀에 사용자를 추가할 수 있는 사용자 계정을 추가해야 합니다. 이러한 사용자는 "팀 및 프로젝트 관리자가 새 사용자를 초대하도록 허용" 정책을 사용하도록 설정된 경우 PCA(프로젝트 컬렉션 관리자) 또는 프로젝트 관리자 및 팀 관리자를 포함합니다.

PCA인 경우 서비스 주체에게 특정 프로젝트에 대한 액세스 권한을 부여하고 라이선스를 할당할 수도 있습니다. PCA가 아닌 경우 PCA에 연락하여 프로젝트 멤버 자격 또는 라이선스 액세스 수준을 업데이트해야 합니다.

3. 서비스 주체에 대한 사용 권한 설정

서비스 주체가 조직에 추가되면 표준 사용자 계정과 비슷하게 처리할 수 있습니다. 서비스 주체에 직접 권한을 할당하고, 보안 그룹 및 팀에 추가하고, 액세스 수준에 할당하고, 조직에서 제거할 수 있습니다. 서비스 주체에서 Service Principal Graph APIs CRUD 작업을 수행하는 데 사용할 수도 있습니다.

이러한 사용 권한 설정은 다른 Azure 리소스에 대한 Microsoft Entra 애플리케이션에서 애플리케이션 권한을 설정하는 데 사용하는 방법과 다를 수 있습니다. Azure DevOps는 Azure Portal을 통해 애플리케이션 등록에 사용할 수 있는 "애플리케이션 권한" 설정을 사용하지 않습니다. 이러한 애플리케이션 권한은 테넌트에 연결된 모든 조직에서 서비스 주체에 권한을 적용하며 Azure DevOps에서 사용할 수 있는 조직, 프로젝트 또는 개체 권한에 대한 지식이 없습니다. 서비스 주체에게 보다 세부적인 권한을 제공하기 위해 Microsoft Entra ID 대신 자체 권한 모델을 사용합니다.

4. 서비스 주체 관리

서비스 주체의 관리는 다음과 같은 주요 방법으로 사용자 계정과 다릅니다.

• 서비스 주체에는 전자 메일이 없으므로 전자 메일을 통해 조직에 초대할 수 없습니다.
• 현재 라이선스에 대한 그룹 규칙은 서비스 주체에 적용되지 않습니다. 서비스 주체에 액세스 수준을 할당하려는 경우 직접 할당하는 것이 가장 좋습니다.
• 서비스 주체는 Azure Portal에서 Microsoft Entra 그룹에 추가할 수 있습니다. 현재 Microsoft Entra 그룹 구성원 목록에 표시할 수 없도록 하는 기술적 제한이 있습니다. Azure DevOps 그룹에는 이 제한이 적용되지 않습니다. 즉, 서비스 주체는 여전히 자신이 속한 Microsoft Entra 그룹 위에 설정된 모든 그룹 권한을 상속합니다.
• Microsoft Entra 그룹의 사용자는 관리자가 그룹을 만들고 Microsoft Entra 그룹을 추가하기 때문에 Azure DevOps 조직의 일부가 아닙니다. Microsoft Entra 그룹의 사용자가 처음으로 조직에 로그인하면 발생하는 "구체화"라는 프로세스가 있습니다. 조직에 로그인하는 사용자는 라이선스를 부여해야 하는 사용자를 결정할 수 있습니다. 서비스 주체에 대한 로그인은 불가능하므로 관리자는 앞에서 설명한 대로 명시적으로 조직에 추가해야 합니다.
• Azure DevOps에서는 서비스 주체의 표시 이름 또는 아바타를 수정할 수 없습니다.
• 서비스 프린시펄은 다중 조직 청구이 선택된 경우에도 추가된 각 조직에서 라이선스를 받습니다.

5. Microsoft Entra ID 토큰 가져오기

(a) 프로그래밍 방식으로 Microsoft Entra ID 토큰 획득

관리 ID에 대한 액세스 토큰 획득은 Microsoft Entra ID 설명서와 함께 수행하여 수행할 수 있습니다. 서비스 주체 및 관리 ID대한 예제를 참조하세요.

반환된 액세스 토큰은 정의된 역할이 있는 JWT(JSON 웹 토큰)이며, 토큰을 전달자사용하여 조직 리소스에 액세스하는 데 사용할 수 있습니다.

(b) Azure CLI를 사용하여 Microsoft Entra ID 토큰 획득

임시 작업의 경우 Azure CLI를 통해 일회성 Microsoft Entra ID 토큰을 획득하는 것이 더 쉬울 수 있습니다. 이 방법은 API 호출 또는 git 복제 작업과 같이 정기적으로 순환할 영구 토큰이 필요하지 않은 작업에 선호됩니다.

필수 구성 요소

• Azure 테넌트 ID 및 구독 ID : 구독이 액세스하려는 Azure DevOps 조직에 연결된 테넌트와 연관되어 있는지 확인합니다. 테넌트 또는 구독 ID를 모르는 경우, Azure Portal에서 확인할 수 있습니다.
• Azure 앱 클라이언트 ID 및 클라이언트 시크릿
• Azure CLI

이러한 지침은 Databricks 문서에서 제공하며, 자세한 내용은 그들의 페이지에서 찾을 수 있습니다.

1. az devops login 명령을 사용하여 Azure CLI에 서비스 주체로 로그인합니다.
2. 화면의 지침에 따라 로그인을 완료합니다.

# To authenticate a service principal with a password or cert:
az login --service-principal -u <app-id> -p <password-or-cert> --tenant <tenant>

# To authenticate a managed identity:
az login --identity

3. 다음 명령을 입력하여 로그인한 서비스 주체에 대해 올바른 구독을 설정합니다.

az account set -s <subscription-id>

4. Azure DevOps 리소스 ID: az account get-access-token및 499b84ac-1321-427f-aa17-267ca6975798을 사용하여 Microsoft Entra ID 액세스 토큰을 생성합니다.

$accessToken = az account get-access-token --resource 499b84ac-1321-427f-aa17-267ca6975798 --query "accessToken" --output tsv

5. 이제 일반적인 명령을 사용할 az cli 수 있습니다. 헤더에 Bearer 토큰으로 전달하여 Azure DevOps API를 호출해 보겠습니다.

$apiVersion = "7.1-preview.1"
$uri = "https://dev.azure.com/${yourOrgname}/_apis/projects?api-version=${apiVersion}"
$headers = @{
    Accept = "application/json"
    Authorization = "Bearer $accessToken"
}
Invoke-RestMethod -Uri $uri -Headers $headers -Method Get | Select-Object -ExpandProperty value ` | Select-Object id, name

6. Microsoft Entra ID 토큰을 사용하여 Azure DevOps 리소스에 인증

다음 비디오 예제에서는 PAT 인증에서 서비스 주체의 토큰 사용으로 이동합니다. 먼저 인증에 클라이언트 암호를 사용한 다음 클라이언트 인증서 사용으로 이동합니다.

또 다른 예제에서는 Azure 함수 내에서 사용자 할당 관리 ID를 사용하여 Azure DevOps에 연결하는 방법을 보여 줍니다.

샘플 앱 컬렉션에서 앱 코드를 찾아 이러한 예제를 따릅니다.

Azure DevOps REST API 호출을 만드는 것 외에도 서비스 주체를 사용하여 인증하는 몇 가지 일반적인 시나리오는 다음 문서에서 찾을 수 있습니다.

• Nuget.exe 또는 dotnet사용하여 서비스 주체를 NuGet 피드에 연결합니다.
• 서비스 주체와 명령줄 통해 Visual Studio Marketplace에 확장을 게시합니다.
• 서비스 주체 또는 관리 ID가 Azure Pipelines에서 비밀 없는 서비스 연결을 만듭니다.
• Git 자격 증명 관리자 서비스 주체를 사용하여 리포지토리 복제

서비스 주체가 사용자와 어떻게 다른지

• Azure DevOps에서는 서비스 주체의 표시 이름 또는 아바타를 수정할 수 없습니다.
• 다중 조직 청구와 상관없이, 서비스 주체는 가입하는 각 조직에 대해 라이선스로 간주됩니다.
• 서비스 주체는 조직 소유자 또는 조직을 만들 수 없습니다.
• 서비스 주체는 PAT(개인용 액세스 토큰) 같은 토큰을 만들거나 SSH 키수 없습니다. 자체 Microsoft Entra ID 토큰을 생성하여 Azure DevOps REST API를 호출할 수 있습니다.
• 서비스 주체는 Azure DevOps OAuth지원하지 않습니다.

FAQ

Q: PAT 대신 서비스 주체 또는 관리 ID를 사용해야 하는 이유는 무엇인가요?

A: 많은 고객이 기존 PAT(개인용 액세스 토큰)를 대체하기 위해 서비스 주체 또는 관리 ID를 찾습니다. 이러한 PAT는 Azure DevOps 리소스를 사용하여 애플리케이션을 인증하는 데 사용하는 서비스 계정(공유 팀 계정)에 속하는 경우가 많습니다. PAT는 매번 힘들게 회전해야 합니다(최소 180일). 부적절하게 저장된 PAT는 잘못된 손에 들어가서 종종 더 긴 수명을 지속할 수 있습니다. Microsoft Entra 토큰은 매시간 만료되어 유출 시 전반적인 위험 요소를 제한합니다. 일반적인 PAT 시나리오에서대신 Microsoft Entra 토큰을 사용하는 방법을 탐색하는 몇 가지 예를 공유합니다.

서비스 주체를 사용하여 개인 액세스 토큰을 만들 수 없습니다.

Q: 서비스 주체 및 관리 ID에 대한 속도 제한은 무엇인가요?

A: 서비스 주체 및 관리 ID는 사용자와 동일한 속도 제한을.

Q: 이 기능을 사용하는 데 더 많은 비용이 들까요?

A: 서비스 주체 및 관리 ID는 액세스 수준에 따라 사용자와 비슷하게 가격이 책정됩니다. 한 가지 주목할 만한 변화는 서비스 주체에 대한 "다중 조직 청구"를 처리하는 방법과 관련이 있습니다. 사용자는 조직 수에 관계없이 하나의 라이선스로만 계산됩니다. 서비스 주체는 사용자가 소속된 각 조직당 하나의 라이선스로 계산됩니다. 이 시나리오는 표준 "사용자 할당 기반 청구"입니다.

Q: 다른 테넌트에서 내 조직에 관리 ID를 추가할 수 있나요?

A: 조직이 연결된 동일한 테넌트에서만 관리 ID를 추가할 수 있습니다. 그러나 모든 리소스가 있는 "리소스 테넌트"에서 관리 ID를 설정할 수 있는 해결 방법이 있습니다. 그런 다음, 조직이 연결된 "대상 테넌트"에서 서비스 주체가 사용하도록 설정할 수 있습니다. 해결 방법으로 다음 단계를 수행합니다.

1. 리소스 테넌트에 대한 Azure Portal에서 사용자 할당 관리 ID 를 만듭니다.
2. 가상 머신에 연결하고 이 관리 ID 를 할당합니다.
3. 키 자격 증명 모음을 만들고 인증서를 생성합니다("PEM" 형식일 수 없습니다). 이 인증서를 생성하면 이름이 같은 비밀도 생성되며 나중에 사용합니다.
4. 키 자격 증명 모음에서 프라이빗 키를 읽을 수 있도록 관리 ID에 대한 액세스 권한을 부여합니다. "Get/List" 권한이 있는 키 자격 증명 모음에 액세스 정책을 만들고("비밀 권한" 아래에서" "보안 주체 선택" 아래에서 관리 ID를 검색합니다.
5. 만든 인증서를 "CER" 형식으로 다운로드하여 인증서의 프라이빗 부분이 포함되지 않도록 합니다.
6. 대상 테넌트에 새 애플리케이션 등록을 만듭니다.
7. "인증서 및 비밀" 탭에서 다운로드한 인증서를 이 새 애플리케이션에 업로드합니다.
8. 액세스하려는 Azure DevOps 조직에 이 애플리케이션의 서비스 주체를 추가하고 필요한 권한으로 서비스 주체를 설정해야 합니다.
9. 이 코드 샘플에서 관리 ID 인증서를 사용하는 이 서비스 주체에서 Microsoft Entra 액세스 토큰을 가져옵니다.

public static async Task<string> GetSecret(string keyVaultName, string secretName)
{
	var keyVaultUri = new Uri("https://" + keyVaultName + ".vault.azure.net");
	var client = new SecretClient(keyVaultUri, new ManagedIdentityCredential());
	var keyVaultSecret = await client.GetSecretAsync(secretName);

	var secret = keyVaultSecret.Value;
	return secret.Value;
}

private static async Task<AuthenticationResult> GetAppRegistrationAADAccessToken(string applicationClientID, string appTenantId)
{
	IConfidentialClientApplication app;

	byte[] privateKeyBytes = Convert.FromBase64String(GetSecret(keyVaultName, secretName));
	X509Certificate2 certificateWithPrivateKey = new X509Certificate2(privateKeyBytes, (string)null, X509KeyStorageFlags.MachineKeySet);

	app = ConfidentialClientApplicationBuilder.Create(applicationClientID)
		.WithCertificate(certificateWithPrivateKey)
		.WithAuthority(new Uri(string.Format(CultureInfo.InvariantCulture, "https://login.microsoftonline.com/{0}", appTenantId)))
		.Build();
	app.AddInMemoryTokenCache();

	string AdoAppClientID = "499b84ac-1321-427f-aa17-267ca6975798/.default";
	string[] scopes = new string[] { AdoAppClientID };

	var result = await app.AcquireTokenForClient(scopes).ExecuteAsync();

	return result;
}

잠재적 오류

이름 또는 식별자가 '{repoName}'인 Git 리포지토리가 없거나 시도 중인 작업에 대한 권한이 없습니다.

서비스 주체가 리포지토리에 액세스하려면 최소한 "기본" 라이선스 이 있는지 확인합니다. "이해 관계자" 라이선스만으로는 충분하지 않습니다.

개체 ID가 '{provided objectId}'인 서비스 주체를 만들지 못했습니다.

조직에 연결된 테넌트에 서비스 주체 provided objectId 가 없습니다. 한 가지 일반적인 이유는 서비스 주체의 개체 ID 대신 앱 등록의 개체 ID를 전달하기 때문입니다. 서비스 주체는 지정된 테넌트에 대한 애플리케이션을 나타내는 개체이며 애플리케이션 자체가 아닙니다. 테 service principal object ID 넌트의 "엔터프라이즈 애플리케이션" 페이지에서 찾을 수 있습니다. 애플리케이션의 이름을 검색하고 반환되는 "엔터프라이즈 애플리케이션" 결과를 선택합니다. 이 결과는 서비스 주체/엔터프라이즈 애플리케이션의 페이지이며 이 페이지에 있는 개체 ID를 사용하여 Azure DevOps에서 서비스 주체를 만들 수 있습니다.

액세스 거부: {ID of the caller identity} 이 작업을 수행하려면 리소스에 대한 다음 권한이 필요합니다. 사용자 추가

이 오류는 다음 이유 중 하나 때문일 수 있습니다.

• 조직의 소유자, 프로젝트 컬렉션 관리자 또는 프로젝트 또는 팀 관리자가 아닙니다.
• 프로젝트 또는 팀 관리자이지만 '팀 및 프로젝트 관리자가 새 사용자를 초대하도록 허용' 정책을 사용할 수 없습니다.
• 새 사용자를 초대할 수 있는 프로젝트 또는 팀 관리자이지만 새 사용자를 초대할 때 라이선스를 할당하려고 합니다. 프로젝트 또는 팀 관리자는 새 사용자에게 라이선스를 할당할 수 없습니다. 새 초대된 사용자는 새 사용자의 기본 액세스 수준에 추가됩니다. 라이선스 액세스 수준을 변경하려면 PCA에 문의하세요.

Azure DevOps Graph 목록 API는 조직에 서비스 주체가 있다는 것을 알고 있음에도 불구하고 빈 목록을 반환합니다.

반환할 사용자 페이지가 더 많더라도 Azure DevOps Graph 목록 API는 빈 목록을 반환할 수 있습니다. 목록을 continuationToken 반복하는 데 사용하며 결국 서비스 주체가 반환되는 페이지를 찾을 수 있습니다. 반환 continuationToken 되는 경우 API를 통해 더 많은 결과를 사용할 수 있음을 의미합니다. 이 논리를 개선할 계획이 있지만 현재 첫 번째 X 결과가 비어 있을 수 있습니다.

TF401444: 웹 브라우저에서 {tenantId'tenantId\servicePrincipalObjectId'}로 한 번 이상 로그인하여 서비스에 액세스할 수 있습니다.

서비스 주체가 조직에 초대되지 않은 경우 다음 오류가 발생할 수 있습니다. 서비스 주체가 적절한 조직에 추가되고 필요한 리소스에 액세스하는 데 필요한 모든 권한이 있는지 확인합니다.

관련된 문서

• 샘플 앱을 탐색하기
• 서비스 주체 정보 권한 API 참조 검토
• 서비스 주체 Graph API 참조 검토