Azure DevOps에서 서비스 주체 및 관리 ID 사용
Azure DevOps Services
참고 항목
Azure Active Directory는 이제 Microsoft Entra ID입니다. 자세한 내용은 Azure AD의 새 이름을 참조하세요.
Azure DevOps Services 조직에 Microsoft Entra 서비스 주체 및 관리 ID를 추가하여 조직 리소스에 대한 액세스 권한을 부여합니다. 대부분의 팀에서 이 기능은 회사에서 자동화 워크플로를 구동하는 애플리케이션을 인증할 때 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 를 만듭니다.
애플리케이션 서비스 주체 만들기
새 애플리케이션 등록을 만들면 애플리케이션 개체가 Microsoft Entra ID로 만들어집니다. 애플리케이션 서비스 주체는 지정된 테넌트에 대한 이 애플리케이션 개체의 표현입니다. 애플리케이션을 다중 테넌트 애플리케이션으로 등록하는 경우 애플리케이션이 추가되는 모든 테넌트의 애플리케이션 개체를 나타내는 고유한 서비스 주체 개체가 있습니다.
추가 정보:
- Microsoft Entra ID의 애플리케이션 및 서비스 주체 개체
- 서비스 주체 보안
- 포털을 사용하여 리소스에 액세스할 수 있는 Microsoft Entra 애플리케이션 및 서비스 주체 만들기
관리 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는 이를 사용하는 리소스와 별도로 관리됩니다.
자세한 내용은 다음 문서 및 비디오를 참조하세요.
2. Azure DevOps 조직에 서비스 주체 추가
Microsoft Entra 관리 센터에서 서비스 주체를 구성한 후에는 조직에 서비스 주체를 추가하여 Azure DevOps에서 동일한 작업을 수행해야 합니다. 사용자 페이지 또는 ServicePrincipalEntitlements API를 통해 추가할 수 있습니다. 대화형으로 로그인할 수 없으므로 조직, 프로젝트 또는 팀에 사용자를 추가할 수 있는 사용자 계정을 추가해야 합니다. 이러한 사용자는 "팀 및 프로젝트 관리자가 새 사용자를 초대하도록 허용" 정책을 사용하도록 설정된 경우 PCA(프로젝트 컬렉션 관리자) 또는 프로젝트 관리자 및 팀 관리자를 포함합니다.
팁
조직에 서비스 주체를 추가하려면 애플리케이션 또는 관리 ID의 표시 이름을 입력합니다. API를 통해 ServicePrincipalEntitlements
프로그래밍 방식으로 서비스 주체를 추가하도록 선택하는 경우 애플리케이션의 개체 ID가 아닌 서비스 주체의 개체 ID를 전달해야 합니다.
PCA인 경우 서비스 주체에게 특정 프로젝트에 대한 액세스 권한을 부여하고 라이선스를 할당할 수도 있습니다. PCA가 아닌 경우 PCA에 연락하여 프로젝트 멤버 자격 또는 라이선스 액세스 수준을 업데이트해야 합니다.
참고 항목
조직이 연결된 테넌트에 대한 관리 ID 또는 서비스 주체만 추가할 수 있습니다. 다른 테넌트에서 관리 ID에 액세스하려면 FAQ의 해결 방법을 참조하세요.
3. 서비스 주체에 대한 사용 권한 설정
서비스 주체가 조직에 추가되면 표준 사용자 계정과 비슷하게 처리할 수 있습니다. 서비스 주체에 직접 권한을 할당하고, 보안 그룹 및 팀에 추가하고, 액세스 수준에 할당하고, 조직에서 제거할 수 있습니다. 서비스 주체에서 Service Principal Graph APIs
CRUD 작업을 수행하는 데 사용할 수도 있습니다.
이는 다른 Azure 리소스에 대한 Microsoft Entra 애플리케이션에서 애플리케이션 권한을 설정하는 데 사용되는 방법과 다를 수 있습니다. Azure DevOps는 Azure Portal을 통해 애플리케이션 등록에 사용할 수 있는 "애플리케이션 권한" 설정을 사용하지 않습니다. 이러한 애플리케이션 권한은 테넌트에 연결된 모든 조직에서 서비스 주체에 권한을 적용하며 Azure DevOps에서 사용할 수 있는 추가 조직, 프로젝트 또는 개체 권한에 대한 지식이 없습니다. 서비스 주체에게 보다 세부적인 권한을 제공하기 위해 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 토큰을 사용하여 Azure DevOps 리소스에 액세스
Microsoft Entra ID 토큰 가져오기
관리 ID에 대한 액세스 토큰 획득은 Microsoft Entra ID 설명서와 함께 수행하여 수행할 수 있습니다. 자세한 내용은 서비스 주체 및 관리 ID에 대한 예제를 참조하세요.
반환된 액세스 토큰은 정의된 역할이 있는 JWT로, 토큰 을 전달자로 사용하여 조직 리소스에 액세스하는 데 사용할 수 있습니다.
Microsoft Entra ID 토큰을 사용하여 Azure DevOps 리소스 인증
다음 비디오 예제에서는 PAT 인증에서 서비스 주체의 토큰 사용으로 이동합니다. 먼저 인증에 클라이언트 암호를 사용한 다음 클라이언트 인증서 사용으로 이동합니다.
- Azure Portal에서 서비스 주체를 Microsoft Entra ID 그룹에 추가할 수 있지만 Microsoft Entra ID 그룹 구성원 목록에 표시할 수 없도록 하는 현재 기술 제한이 있습니다. Azure DevOps 그룹에는 이 제한이 적용되지 않습니다. 즉, 서비스 주체는 여전히 자신이 속한 Microsoft Entra ID 그룹 위에 설정된 모든 그룹 권한을 상속합니다.
- 관리자가 그룹을 만들고 Microsoft Entra ID 그룹을 추가하기 때문에 Microsoft Entra ID 그룹의 모든 사용자가 즉시 Azure DevOps 조직의 일부가 되는 것은 아닙니다. Microsoft Entra ID 그룹의 사용자가 처음으로 조직에 로그인하면 발생하는 "구체화"라는 프로세스가 있습니다. 조직에 로그인하는 사용자는 라이선스를 부여해야 하는 사용자를 결정할 수 있습니다. 서비스 주체에 대한 로그인은 불가능하므로 관리자는 앞에서 설명한 대로 명시적으로 조직에 추가해야 합니다.
- Azure DevOps에서는 서비스 주체의 표시 이름 또는 아바타를 수정할 수 없습니다.
- 서비스 주체는 다중 조직 청구가 선택된 경우에도 추가되는 각 조직에 대한 라이선스로 계산됩니다.
또 다른 예제에서는 Azure 함수 내에서 사용자 할당 관리 ID를 사용하여 Azure DevOps에 연결하는 방법을 보여 줍니다.
샘플 앱 컬렉션에서 앱 코드를 찾아 이러한 예제를 따릅니다.
서비스 주체를 사용하여 Azure DevOps REST API를 호출하고 대부분의 작업을 수행할 수 있지만 다음 작업에서는 제한됩니다.
- 서비스 주체는 조직 소유자 또는 조직을 만들 수 없습니다.
- 서비스 주체는 개인용 액세스 토큰(PAT) 또는 SSH 키와 같은 토큰을 만들 수 없습니다. 자체 Microsoft Entra ID 토큰을 생성할 수 있으며 이러한 토큰을 사용하여 Azure DevOps REST API를 호출할 수 있습니다.
- 서비스 주체에 대한 Azure DevOps OAuth는 지원되지 않습니다.
참고 항목
토큰을 생성하기 위해 Azure DevOps와 연결된 리소스 URI가 아닌 애플리케이션 ID만 사용할 수 있습니다.
FAQ
일반
Q: PAT 대신 서비스 주체 또는 관리 ID를 사용해야 하는 이유는 무엇인가요?
A: 많은 고객이 기존 PAT(개인용 액세스 토큰)를 대체하기 위해 서비스 주체 또는 관리 ID를 찾습니다. 이러한 PAT는 Azure DevOps 리소스를 사용하여 애플리케이션을 인증하는 데 사용하는 서비스 계정(공유 팀 계정)에 속하는 경우가 많습니다. PAT는 매번 힘들게 회전해야 합니다(최소 180일). PAT는 단순히 전달자 토큰이므로 사용자의 사용자 이름과 암호를 나타내는 토큰 문자열을 의미하므로 잘못된 사람의 손에 쉽게 들어갈 수 있으므로 사용하기가 매우 위험합니다. Microsoft Entra 토큰은 1시간마다 만료되며 새 액세스 토큰을 가져오려면 새로 고침 토큰으로 다시 생성되어야 하며, 이는 유출 시 전반적인 위험 요소를 제한합니다.
서비스 주체를 사용하여 개인 액세스 토큰을 만들 수 없습니다.
Q: 서비스 주체 및 관리 ID에 대한 속도 제한은 무엇인가요?
A: 현재 서비스 주체 및 관리 ID에는 사용자와 동일한 속도 제한이 있습니다 .
Q: 이 기능을 사용하는 데 더 많은 비용이 들까요?
A: 서비스 주체 및 관리 ID는 액세스 수준에 따라 사용자와 비슷하게 가격이 책정됩니다. 한 가지 주목할 만한 변화는 서비스 주체에 대한 "다중 조직 청구"를 처리하는 방법과 관련이 있습니다. 사용자는 조직 수에 관계없이 하나의 라이선스로만 계산됩니다. 서비스 주체는 사용자가 소속된 각 조직당 하나의 라이선스로 계산됩니다. 이 시나리오는 표준 "사용자 할당 기반 청구"입니다.
Q: Azure CLI에서 서비스 주체 또는 관리 ID를 사용할 수 있나요?
A: 예! Azure CLI에서 PAT를 요청하는 모든 곳에서 Microsoft Entra ID 액세스 토큰을 수락할 수도 있습니다. CLI를 사용하여 인증하기 위해 Microsoft Entra 토큰을 전달하는 방법은 다음 예제를 참조하세요.
# To authenticate with a command: After typing this command, the az devops login will prompt you to enter a token. You can add an Entra ID token too! Not just a PAT.
az devops login
# 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
이제 Microsoft Entra 토큰(Azure DevOps 리소스의 UUID) 499b84ac-1321-427f-aa17-267ca6975798
을 가져와서 헤더에 토큰으로 전달하여 Azure DevOps API를 Bearer
호출해 보겠습니다.
Write-Host "Obtain access token for Service Connection identity..."
$accessToken = az account get-access-token --resource 499b84ac-1321-427f-aa17-267ca6975798 --query "accessToken" --output tsv
Write-Host "Use access token with Azure DevOps REST API to list projects in the organization..."
$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
이제 일반적인 명령을 사용할 az cli
수 있습니다.
Q: 다른 테넌트에서 내 조직에 관리 ID를 추가할 수 있나요?
A: 조직이 연결된 동일한 테넌트에서만 관리 ID를 추가할 수 있습니다. 그러나 모든 리소스가 있는 "리소스 테넌트"에서 관리 ID를 설정할 수 있는 해결 방법이 있습니다. 그런 다음, 조직이 연결된 "대상 테넌트"에서 서비스 주체가 사용하도록 설정할 수 있습니다. 해결 방법으로 다음 단계를 수행합니다.
- 리소스 테넌트에 대한 Azure Portal에서 사용자 할당 관리 ID 를 만듭니다.
- 가상 머신에 연결하고 이 관리 ID 를 할당합니다.
- 키 자격 증명 모음을 만들고 인증서를 생성합니다("PEM" 형식일 수 없습니다). 이 인증서를 생성하면 이름이 같은 비밀도 생성되며 나중에 사용합니다.
- 키 자격 증명 모음에서 프라이빗 키를 읽을 수 있도록 관리 ID에 대한 액세스 권한을 부여합니다. "Get/List" 권한이 있는 키 자격 증명 모음에 액세스 정책을 만들고("비밀 권한" 아래에서" "보안 주체 선택" 아래에서 관리 ID를 검색합니다.
- 만든 인증서를 "CER" 형식으로 다운로드하여 인증서의 프라이빗 부분이 포함되지 않도록 합니다.
- 대상 테넌트에 새 애플리케이션 등록을 만듭니다.
- "인증서 및 비밀" 탭에서 다운로드한 인증서를 이 새 애플리케이션에 업로드합니다.
- 액세스하려는 Azure DevOps 조직에 이 애플리케이션의 서비스 주체를 추가하고 필요한 권한으로 서비스 주체를 설정해야 합니다.
- 관리 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;
}
Artifacts
Q: 서비스 주체를 사용하여 피드에 연결할 수 있나요?
A: 예, 서비스 주체를 사용하여 Azure Artifacts 피드에 연결할 수 있습니다. 다음 예제에서는 NuGet, npm 및 Maven에 대한 Microsoft Entra ID 토큰과 연결하는 방법을 보여 주지만 다른 피드 형식도 작동해야 합니다.
Microsoft Entra 토큰을 사용하여 NuGet 프로젝트 설정
최신 NuGet이 있는지 확인합니다.
Azure Artifacts 자격 증명 공급자를 다운로드하고 설치합니다.
프로젝트에 .csproj 또는 .sln 파일과 동일한 폴더에 nuget.config 파일을 추가합니다.
프로젝트 범위 피드:
<?xml version="1.0" encoding="utf-8"?> <configuration> <packageSources> <clear /> <add key="<FEED_NAME>" value="https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/<PROJECT_NAME>/_packaging/<FEED_NAME>/nuget/v3/index.json" /> </packageSources> </configuration>
조직 범위 피드:
<?xml version="1.0" encoding="utf-8"?> <configuration> <packageSources> <clear /> <add key="<FEED_NAME>" value="https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/_packaging/<FEED_NAME>/nuget/v3/index.json" /> </packageSources> </configuration>
아래와 같이 ARTIFACTS_CREDENTIALPROVIDER_FEED_ENDPOINTS 환경 변수를 설정하고 피드 URL, 서비스 주체의 애플리케이션(클라이언트) ID 및 서비스 주체 인증서 경로를 지정합니다.
PowerShell:
$env:ARTIFACTS_CREDENTIALPROVIDER_FEED_ENDPOINTS = @' { "endpointCredentials": [ { "endpoint": "<FEED_URL>", "clientId": "<SERVICE_PRINCIPAL_APPLICATION_(CLIENT)_ID>", "clientCertificateFilePath": "<SERVICE_PRINCIPAL_CERTIFICATE_PATH>" } ] } '@
Bash:
export ARTIFACTS_CREDENTIALPROVIDER_FEED_ENDPOINTS='{ "endpointCredentials": [ { "endpoint": "<FEED_URL>", "clientId": "<SERVICE_PRINCIPAL_APPLICATION_(CLIENT)_ID>", "clientCertificateFilePath": "<SERVICE_PRINCIPAL_CERTIFICATE_PATH>" } ] }'
Microsoft Entra 토큰을 사용하여 npm 프로젝트 설정
참고 항목
vsts-npm-auth 도구는 Microsoft Entra 액세스 토큰을 지원하지 않습니다.
프로젝트와
.npmrc
동일한 디렉터리에 프로젝트에 추가합니다package.json
.registry=https://pkgs.dev.azure.com/Fabrikam/_packaging/FabrikamFeed/npm/registry/ always-auth=true
서비스 주체 또는 관리 ID에 대한 액세스 토큰을 가져옵니다.
이 코드를 사용자
${user.home}/.npmrc
에 추가하고 자리 표시자를[AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN]
이전 단계의 액세스 토큰으로 바꿉다.//pkgs.dev.azure.com/Fabrikam/_packaging/FabrikamFeed/npm/:_authToken=[AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN]
Microsoft Entra 토큰을 사용하여 Maven 프로젝트 설정
리포지토리를 's 및
<distributionManagement>
섹션 모두에<repositories>
추가합니다pom.xml
.<repository> <id>Fabrikam</id> <url>https://pkgs.dev.azure.com/Fabrikam/_packaging/FabrikamFeed/maven/v1</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>true</enabled> </snapshots> </repository>
서비스 주체 또는 관리 ID에 대한 액세스 토큰을 가져옵니다.
파일을
${user.home}/.m2
추가하거나 편집settings.xml
하고 자리 표시자를[AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN]
이전 단계의 액세스 토큰으로 바꿉다.<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd"> <servers> <server> <id>Fabrikam</id> <username>Fabrikam</username> <password>[AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN]</password> </server> </servers> </settings>
Marketplace
Q: 서비스 주체를 사용하여 Visual Studio Marketplace에 확장을 게시할 수 있나요?
A: 예. 다음 단계를 수행하세요.
게시자 계정에 서비스 주체를 멤버로 추가합니다. 프로필 - 가져오기를 사용하여 프로필에서 서비스 주체의 ID를 가져올 수 있습니다. 그런 다음 이전 단계의 ID를 사용하여 서비스 주체를 게시자에 멤버로 추가할 수 있습니다.
SP를 사용하여 TFX CLI를 통해 확장을 게시합니다. 다음 TFX CLI 명령을 실행하여 SP 액세스 토큰을 사용합니다.
tfx extension publish --publisher my-publisher --vsix my-publisher.my-extension-1.0.0.vsix --auth-type pat -t <AAD_ACCESS_TOKEN>
Pipelines
Q: 서비스 연결 내에서 관리 ID를 사용할 수 있나요? 서비스 연결에서 서비스 주체에 대한 비밀을 더 쉽게 회전하려면 어떻게 해야 하나요? 서비스 연결에 비밀을 아예 저장하지 않아도 되나요?
openID Connect 프로토콜을 사용하여 워크로드 ID 페더레이션을 Azure 지원. 이를 통해 Microsoft Entra ID에서 페더레이션된 자격 증명을 사용하여 서비스 주체 또는 관리 ID에서 지원되는 Azure Pipelines에서 비밀 없는 서비스 연결을 만들 수 있습니다. 실행의 일환으로 파이프라인은 자체 내부 토큰을 Microsoft Entra 토큰과 교환하여 Azure 리소스에 액세스할 수 있습니다. 구현된 후에는 현재 존재하는 다른 유형의 Azure 서비스 연결보다 제품에서 이 메커니즘을 사용하는 것이 좋습니다. 이 메커니즘을 사용하여 다른 OIDC 규격 서비스 공급자와 비밀 없는 배포를 설정할 수도 있습니다. 이 메커니즘은 미리 보기로 제공됩니다.
리포지토리
Q: 서비스 주체를 사용하여 리포지토리 복제와 같은 git 작업을 수행할 수 있나요?
A: PowerShell 스크립트에서 리포지토리를 복제하기 위해 PAT 대신 서비스 주체의 Microsoft Entra ID 토큰을 전달한 방법의 다음 예제를 참조하세요.
$ServicePrincipalAadAccessToken = 'Entra ID access token of a service principal'
git -c http.extraheader="AUTHORIZATION: bearer $ServicePrincipalAadAccessToken" clone https://dev.azure.com/{yourOrgName}/{yourProjectName}/_git/{yourRepoName}
팁
토큰을 더 안전하게 유지하려면 자격 증명 관리자를 사용하여 매번 자격 증명을 입력할 필요가 없습니다. 환경 변수가 변경될 경우 PAT 대신 Microsoft Entra 토큰(즉, Microsoft Identity OAuth 토큰)을 수락할 수 있는 Git 자격 증명 관리자를 사용하는 것이 좋습니다.
Azure CLI에서 액세스 토큰을 가져와 git fetch를 호출하는 방법에 대한 유용한 팁:
- 리포지토리의 Git 구성을 엽니다.
git config -e
- Azure DevOps 리소스의 UUID
00000000-0000-0000-0000-000000000000
가 있는 다음 줄을 추가합니다.
[credential]
helper = "!f() { test \"$1\" = get && echo \"password=$(az account get-access-token --resource 00000000-0000-0000-0000-000000000000 --query accessToken -o tsv)\"; }; f"
- 다음을 사용하여 작동하는지 테스트합니다.
GIT_TRACE=1 GCM_TRACE=1 GIT_CURL_VERBOSE=1 git fetch
잠재적 오류
개체 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'}로 한 번 이상 로그인하여 서비스에 액세스할 수 있습니다.
서비스 주체가 조직에 초대되지 않은 경우 다음 오류가 발생할 수 있습니다. 서비스 주체가 적절한 조직에 추가되고 필요한 리소스에 액세스하는 데 필요한 모든 권한이 있는지 확인합니다.