Hizmet sorumlularını ve yönetilen kimlikleri kullanma

  • Makale

Azure DevOps Services

Kuruluş kaynaklarınıza erişim vermek için Azure DevOps kuruluşlarınıza Microsoft Entra hizmet sorumlularını ve yönetilen kimlikleri ekleyin. Birçok ekip için bu özellik, şirketinizdeki power automation iş akışlarına sahip uygulamaların kimliğini doğruladığınızda kişisel erişim belirteçlerine (PAT) uygun ve tercih edilen bir alternatif olabilir.

Hizmet sorumluları ve yönetilen kimlikler hakkında

Hizmet sorumluları , belirli bir kiracıda bir uygulamanın neler yapabileceğini tanımlayan bir Microsoft Entra uygulaması içindeki güvenlik nesneleridir. Bunlar, uygulama kayıt işlemi sırasında Azure portalında ayarlanır ve Azure DevOps gibi Azure kaynaklarına erişecek şekilde yapılandırılır. Kuruluşunuza hizmet sorumluları ekleyerek ve bunların üzerinde izinler ayarlayarak, bir hizmet sorumlusunun kuruluş kaynaklarınıza ve hangilerine erişme yetkisine sahip olduğunu belirleyebiliriz.

Yönetilen kimlikler , bir uygulamanın hizmet sorumlularına benzer şekilde davranan başka bir Microsoft Entra özelliğidir. Bu nesneler Azure kaynakları için kimlikler sağlar ve Microsoft Entra kimlik doğrulamasını destekleyen hizmetlerin kimlik bilgilerini paylaşması için kolay bir yol sağlar. Bunlar cazip bir seçenektir çünkü Kimlik bilgileri yönetimi ve döndürme işlemleri Microsoft Entra Id tarafından gerçekleştirilir. Yönetilen kimlik kurulumu Azure portalında farklı görünse de, Azure DevOps her iki güvenlik nesnesini de tanımlı izinlere sahip bir kuruluştaki yeni kimlikle aynı şekilde ele alır. Bu makalenin geri kalanında, belirtilmediği sürece yönetilen kimlikleri ve hizmet sorumlularını birbirinin yerine hizmet sorumlusu olarak adlandıracağız.

Bu kimliklerin kendileri adına eylem gerçekleştirmesine izin vermek üzere Azure DevOps'ta kimlik doğrulaması yapmak için aşağıdaki adımları kullanın.

Yönetilen kimlikleri ve hizmet sorumlularını yapılandırma

Uygulamanız farklılık gösterebilir, ancak üst düzeyde aşağıdaki adımlar iş akışınızda hizmet sorumlularını kullanmaya başlamanıza yardımcı olur. Örnek uygulamalarımızdan birine göz atarak bir örneği kendiniz takip edebilirsiniz.

1. Yeni yönetilen kimlik veya uygulama hizmet sorumlusu oluşturma

Azure portalında bir uygulama hizmet sorumlusu veya yönetilen kimlik oluşturun.

Uygulama hizmet sorumlusu oluşturma

Yeni bir uygulama kaydı oluşturduğunuzda, Microsoft Entra Id içinde bir uygulama nesnesi oluşturulur. Uygulama hizmeti sorumlusu , belirli bir kiracı için bu uygulama nesnesinin bir gösterimidir. Bir uygulamayı çok kiracılı bir uygulama olarak kaydettiğinizde, uygulamanın eklendiği her kiracı için uygulama nesnesini temsil eden benzersiz bir hizmet sorumlusu nesnesi vardır.

Daha fazla bilgi:

Yönetilen kimlik oluşturma

Azure portalında yönetilen kimlikler oluşturmak, hizmet sorumlularıyla uygulama ayarlamaktan önemli ölçüde farklıdır. Oluşturma işlemine başlamadan önce, önce hangi tür yönetilen kimlik oluşturmak istediğinizi göz önünde bulundurmanız gerekir:

  • Sistem tarafından atanan yönetilen kimlik: Bazı Azure hizmetleri, yönetilen kimliği doğrudan bir hizmet örneğinde etkinleştirmenize olanak tanır. Sistem tarafından atanan yönetilen kimliği etkinleştirdiğinizde, Microsoft Entra Kimliği'nde bir kimlik oluşturulur. Kimlik, söz konusu hizmet örneğinin yaşam döngüsüne bağlıdır. Kaynak silindiğinde Azure sizin için kimliği otomatik olarak siler. Tasarım gereği, yalnızca bu Azure kaynağı Microsoft Entra ID’den belirteç istemek için bu kimliği kullanabilir.
  • Kullanıcı tarafından atanan yönetilen kimlik Ayrıca, kullanıcı tarafından atanan bir yönetilen kimlik oluşturarak ve bunu bir Azure hizmetinin bir veya daha fazla örneğine atayarak tek başına Azure kaynağı olarak bir yönetilen kimlik oluşturabilirsiniz. Kullanıcı tarafından atanan yönetilen kimlikler için kimlik, onu kullanan kaynaklardan ayrı olarak yönetilir.

Daha fazla bilgi için aşağıdaki makalelere ve videoya bakın:

2. Azure DevOps kuruluşunda hizmet sorumlularını ekleme ve yönetme

Microsoft Entra yönetim merkezinde hizmet sorumlularını yapılandırdıktan sonra, hizmet sorumlularını kuruluşunuza ekleyerek Azure DevOps'ta da aynı işlemi yapmanız gerekir. Bunları Kullanıcılar sayfasından veya ServicePrincipalEntitlements API'leri ile ekleyebilirsiniz. Etkileşimli olarak oturum açamadıklarına göre kuruluşa, projeye veya takıma kullanıcı ekleyebilen bir kullanıcı hesabının bunları eklemesi gerekir. Bu tür kullanıcılar, "Ekip ve proje yöneticilerinin yeni kullanıcıları davet etmelerine izin ver" ilkesi etkinleştirildiğinde Project Collection Yönetici istrators (PCA) veya Project Yönetici istrators ve Team Yönetici istrators içerir.

İpucu

Kuruluşa hizmet sorumlusu eklemek için uygulamanın veya yönetilen kimliğin görünen adını girin. API aracılığıylaServicePrincipalEntitlementsprogram aracılığıyla bir hizmet sorumlusu eklemeyi seçerseniz, uygulamanın nesne kimliğini değil hizmet sorumlusunun nesne kimliğini geçirmeyi unutmayın.

PCA'ysanız, belirli projelere hizmet sorumlusu erişimi verebilir ve lisans atayabilirsiniz. PCA değilseniz, proje üyeliklerini veya lisans erişim düzeylerini güncelleştirmek için PCA'ya ulaşmanız gerekir.

Screenshot of service principals and managed identities in the Users Hub.

Not

Yalnızca kuruluşunuzun bağlı olduğu kiracı için yönetilen kimlik veya hizmet sorumlusu ekleyebilirsiniz. Farklı bir kiracıdaki yönetilen kimliğe erişmek için SSS'deki geçici çözüme bakın.

Hizmet sorumlularınız kuruluşa eklendikten sonra bunları standart kullanıcı hesaplarına benzer şekilde değerlendirebilirsiniz. İzinleri doğrudan bir hizmet sorumlusuna atayabilir, güvenlik gruplarına ve ekiplere ekleyebilir, herhangi bir erişim düzeyine atayabilir ve kuruluştan kaldırabilirsiniz. CruD işlemlerini hizmet sorumlularında gerçekleştirmek için de kullanabilirsiniz Service Principal Graph APIs .

Hizmet sorumlularının yönetimi, aşağıdaki temel yollarla kullanıcı hesaplarından farklıdır:

  • Hizmet sorumlularının e-postaları yoktur ve bu nedenle e-posta yoluyla bir kuruluşa davet edilemezler.
  • Lisanslama için grup kuralları şu anda hizmet sorumluları için geçerli değildir. Bir hizmet sorumlusuna erişim düzeyi atamak istiyorsanız, bunu doğrudan yapmak en iyisidir.
  • Hizmet sorumluları Microsoft Entra gruplarına (Azure portalında) eklenebiliyor olsa da, bunları Microsoft Entra grup üyeleri listesinde görüntüleyebilmemizi engelleyen geçerli bir teknik sınırlamamız vardır. Bu sınırlama Azure DevOps grupları için geçerli değildir. Öte yandan hizmet sorumlusu, ait olduğu Bir Microsoft Entra grubunun üzerinde ayarlanan tüm grup izinlerini devralmaya devam eder.
  • Bir Microsoft Entra grubundaki tüm kullanıcılar, bir yönetici bir grup oluşturup buna bir Microsoft Entra grubu eklediğinden hemen bir Azure DevOps kuruluşunun parçası değildir. Microsoft Entra grubundan bir kullanıcı kuruluşta ilk kez oturum açtığında gerçekleşen "gerçekleştirme" adlı bir sürecimiz var. Bir kuruluşta oturum açan bir kullanıcı, hangi kullanıcılara lisans verilmesi gerektiğini belirlememize olanak tanır. Hizmet sorumluları için oturum açma mümkün olmadığından, yöneticinin bunu daha önce açıklandığı gibi kuruluşa açıkça eklemesi gerekir.
  • Azure DevOps'ta hizmet sorumlusu görünen adını veya avatarı değiştiremezsiniz.
  • Hizmet sorumlusu, çok kuruluşlu faturalama seçili olsa bile eklendiği her kuruluş için lisans olarak sayılır.

3. Microsoft Entra ID belirteci ile Azure DevOps kaynaklarına erişme

Microsoft Entra Id belirteci alma

Yönetilen kimlik için erişim belirteci alma işlemi, Microsoft Entra Id belgeleriyle birlikte izlenerek yapılabilir. Daha fazla bilgi için hizmet sorumluları ve yönetilen kimlik örneklerine bakın.

Döndürülen erişim belirteci, belirteç taşıyıcı olarak kullanılarak kuruluş kaynaklarına erişmek için kullanılabilen, tanımlı rollere sahip bir JWT'dir.

Azure DevOps kaynaklarda kimlik doğrulaması yapmak için Microsoft Entra Id belirtecini kullanma

Aşağıdaki video örneğinde PAT ile kimlik doğrulamasından hizmet sorumlusundan belirteç kullanmaya geçiyoruz. Kimlik doğrulaması için bir istemci gizli dizisi kullanarak başlıyoruz, ardından istemci sertifikası kullanmaya geçiyoruz.

  • Hizmet sorumluları Microsoft Entra Id gruplarına (Azure portalında) eklenebiliyor olsa da, bunları Microsoft Entra ID grubu üyeleri listesinde görüntüleyebilmemizi engelleyen geçerli bir teknik sınırlamamız vardır. Bu sınırlama Azure DevOps grupları için geçerli değildir. Buna rağmen hizmet sorumlusu, ait olduğu Bir Microsoft Entra Id grubunun üzerinde ayarlanan tüm grup izinlerini devralmaya devam eder.
  • Microsoft Entra Id grubundaki tüm kullanıcılar, bir yöneticinin bir grup oluşturup buna bir Microsoft Entra Id grubu eklemesi nedeniyle bir Azure DevOps kuruluşunun hemen bir parçası olmaz. Microsoft Entra ID grubundan bir kullanıcı kuruluşta ilk kez oturum açtığında gerçekleşen "gerçekleştirme" adlı bir işlemimiz var. Bir kuruluşta oturum açan bir kullanıcı, hangi kullanıcılara lisans verilmesi gerektiğini belirlememize olanak tanır. Hizmet sorumluları için oturum açma mümkün olmadığından, yöneticinin bunu daha önce açıklandığı gibi kuruluşa açıkça eklemesi gerekir.
  • Azure DevOps'ta hizmet sorumlusu görünen adını veya avatarı değiştiremezsiniz.
  • Hizmet sorumlusu, çok kuruluşlu faturalama seçili olsa bile eklendiği her kuruluş için lisans olarak sayılır.

Başka bir örnek, bir Azure İşlevi içinde Kullanıcı Tarafından Atanan Yönetilen Kimlik kullanarak Azure DevOps'a bağlanmayı gösterir.

Örnek uygulamalar koleksiyonumuzda uygulama kodunu bularak bu örneklerle birlikte izleyin.

Hizmet sorumluları Azure DevOps REST API'lerini çağırmak ve çoğu eylemi gerçekleştirmek için kullanılabilir, ancak aşağıdaki işlemlerle sınırlıdır:

  • Hizmet sorumluları kuruluş sahibi olamaz veya kuruluş oluşturamaz.
  • Hizmet sorumluları, kişisel erişim belirteçleri (PAT) veya SSH Anahtarları gibi belirteçler oluşturamaz. Kendi Microsoft Entra Id belirteçlerini oluşturabilirler ve bu belirteçler Azure DevOps REST API'lerini çağırmak için kullanılabilir.
  • Hizmet sorumluları için Azure DevOps OAuth'u desteklemiyoruz.

Not

Belirteç oluşturmak için Azure DevOps ile ilişkili Kaynak URI'lerini değil yalnızca Uygulama Kimliği'ni kullanabilirsiniz.

SSS

Genel

S: Pat yerine neden hizmet sorumlusu veya yönetilen kimlik kullanmalıyım?

Y: Müşterilerimizin çoğu mevcut pat (kişisel erişim belirteci) yerine bir hizmet sorumlusu veya yönetilen kimlik arar. Bu tür PAT'ler genellikle Azure DevOps kaynaklarıyla bir uygulamanın kimliğini doğrulamak için bunları kullanan bir hizmet hesabına (paylaşılan ekip hesabı) aittir. PAT'lar her zaman zahmetli bir şekilde döndürülmelidir (en az 180 gün). PAT'ler yalnızca taşıyıcı belirteçler olduğundan, yani kullanıcının kullanıcı adını ve parolasını temsil eden belirteç dizeleri olduğundan, kolayca yanlış kişinin eline geçebilecekleri için kullanılması son derece risklidir. Microsoft Entra belirteçlerinin süresi saatte bir dolar ve yeni bir erişim belirteci almak için yenileme belirteci ile yeniden oluşturulmalıdır ve bu da sızdırıldığında genel risk faktörünü sınırlar.

Kişisel erişim belirteci oluşturmak için hizmet sorumlusu kullanamazsınız.

S: Hizmet sorumluları ve yönetilen kimliklerdeki hız sınırları nelerdir?

Y: Şu anda hizmet sorumluları ve yönetilen kimlikler kullanıcılarla aynı hız sınırlarına sahiptir.

S: Bu özelliği kullanmanın maliyeti daha mı yüksek olacak?

Y: Hizmet sorumluları ve yönetilen kimlikler, erişim düzeyine göre kullanıcılara benzer şekilde fiyatlanır. Önemli bir değişiklik, hizmet sorumluları için "çok kuruluşlu faturalamayı" nasıl ele aldığımızla ilgili. Kaç kuruluşta yer aldıkları fark etmez, kullanıcılar tek bir lisans olarak sayılır. Hizmet sorumluları, kullanıcının içinde olduğu her kuruluş için bir lisans olarak sayılır. Bu senaryo standart "kullanıcı ataması tabanlı faturalama" ile benzerdir.

S: Azure CLI ile hizmet sorumlusu veya yönetilen kimlik kullanabilir miyim?

Y: Evet! Azure CLI'da PAT isteyen her yerde Microsoft Entra ID erişim belirteçlerini de kabul edebilirsiniz. CLI ile kimlik doğrulaması yapmak için bir Microsoft Entra belirtecini nasıl geçirebileceğini öğrenmek için bu örneklere bakın.

# 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

Şimdi bir Microsoft Entra belirteci (Azure DevOps kaynağının UUID değeri) 499b84ac-1321-427f-aa17-267ca6975798alıp üst bilgilerde belirteç olarak Bearer geçirerek bir Azure DevOps API'sini çağırmayı deneyelim:

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

Artık komutları her zamanki gibi kullanabilirsiniz az cli .

S: Kuruluşuma farklı bir kiracıdan yönetilen kimlik ekleyebilir miyim?

Y: Yönetilen kimliği yalnızca kuruluşunuzun bağlı olduğu kiracıdan ekleyebilirsiniz. Ancak, tüm kaynaklarınızın bulunduğu "kaynak kiracısında" yönetilen kimlik ayarlamanıza olanak tanıyan bir geçici çözüme sahibiz. Ardından, kuruluşunuzun bağlı olduğu "hedef kiracıda" bir hizmet sorumlusu tarafından kullanılmasını etkinleştirebilirsiniz. Geçici çözüm olarak aşağıdaki adımları uygulayın:

  1. Kaynak kiracınız için Azure portalında kullanıcı tarafından atanan bir yönetilen kimlik oluşturun.
  2. Sanal makineye Bağlan ve bu yönetilen kimliği ona atayın.
  3. Bir anahtar kasası oluşturun ve bir sertifika oluşturun ("PEM" türünde olamaz). Bu sertifikayı oluşturduğunuzda, daha sonra kullandığımız aynı ada sahip bir gizli dizi de oluşturulur.
  4. Anahtar kasasından özel anahtarı okuyabilmesi için yönetilen kimliğe erişim verin. Anahtar kasasında "Al/Listele" izinleriyle bir erişim ilkesi oluşturun ("Gizli dizi izinleri" altında ve "Sorumluyu seç" altında yönetilen kimliği arayın.)
  5. Oluşturulan sertifikayı ,sertifikanızın özel bölümünü içermemesini sağlayan "CER" biçiminde indirin.
  6. Hedef kiracıda yeni bir uygulama kaydı oluşturun.
  7. İndirilen sertifikayı "Sertifikalar ve gizli diziler" sekmesinde bu yeni uygulamaya yükleyin.
  8. Bu uygulamanın hizmet sorumlusunu erişmek istediğimiz Azure DevOps kuruluşuna ekleyin ve gerekli izinlerle hizmet sorumlusunu ayarlamayı unutmayın.
  9. Yönetilen kimlik sertifikasını kullanan bu hizmet sorumlusundan bir Microsoft Entra erişim belirteci almak için aşağıdaki kod örneğine bakın:

Not

Sertifikaları her zaman olduğu gibi düzenli olarak döndürmeniz gerekir.

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;
}

Yapıtlar

S: Akışlara bağlanmak için hizmet sorumlusu kullanabilir miyim?

Y: Evet, bir hizmet sorumlusuyla herhangi bir Azure Artifacts akışına bağlanabilirsiniz. Aşağıdaki örneklerde NuGet, npm ve Maven için Bir Microsoft Entra ID belirteci ile nasıl bağlanabileceğinizi göstereceğiz, ancak diğer akış türlerinin de çalışması gerekir.

Microsoft Entra belirteci ile NuGet proje kurulumu

  1. Projenize .csproj veya .sln dosyasıyla aynı klasöre bir nuget.config dosyası ekleyin.

    <?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="FeedName" value="https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/<PROJECT_NAME>/_packaging/<FEED_NAME>/nuget/v3/index.json" />
  </packageSources>
</configuration>

  2. Hizmet sorumlunuz için bir Microsoft Entra Id belirteci alın.

  3. Kimlik bilgilerinizle kimlik doğrulaması yapmak için aşağıdaki komutu çalıştırın ve ardından setapikey komutunu kullanarak belirtecinizi ekleyin. Bu komut, akış kaynağınızı nuget.config'inize ekler:

    nuget sources add -name <FEED_NAME> -source <SOURCE_URL> -username <USERNAME> -password <PASSWORD>

nuget setapikey <YOUR_ACCESS_TOKEN> -source <SOURCE_URL>

Microsoft Entra belirteçleriyle npm proje kurulumu

Not

vsts-npm-auth aracı Microsoft Entra erişim belirteçlerini desteklemez.

  1. projenize, ile package.jsonaynı dizinde bir .npmrc ekleyin.

    registry=https://pkgs.dev.azure.com/Fabrikam/_packaging/FabrikamFeed/npm/registry/ 
always-auth=true

  2. Hizmet sorumlunuz veya yönetilen kimliğiniz için bir erişim belirteci alın.

  3. Bu kodu cihazınıza ${user.home}/.npmrc ekleyin ve yer tutucuyu [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] önceki adımdaki erişim belirteci ile değiştirin.

    //pkgs.dev.azure.com/Fabrikam/_packaging/FabrikamFeed/npm/:_authToken=[AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN]

Microsoft Entra belirteçleriyle Maven proje kurulumu

  1. Depoyu hem sizin hem de bölümlerinize pom.xml<repositories><distributionManagement> ekleyin.

    <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>

  2. Hizmet Sorumlunuz veya Yönetilen Kimliğiniz için bir erişim belirteci alın.

  3. dosyasını ${user.home}/.m2 ekleyin veya düzenleyin settings.xml ve yer tutucuyu [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] önceki adımdaki erişim belirteci ile değiştirin.

    <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>

Market

S: Visual Studio Market'te uzantı yayımlamak için hizmet sorumlusu kullanabilir miyim?

Y: Evet. Aşağıdaki adımları uygulayın.

  1. Yayımcı hesabına üye olarak bir hizmet sorumlusu ekleyin. Profiller - Al'ı kullanarak hizmet sorumlusunun kimliğini profilinden alabilirsiniz. Ardından, önceki adımdaki kimliği kullanarak hizmet sorumlusunu yayımcıya üye olarak ekleyebilirsiniz.

  2. SP kullanarak TFX CLI aracılığıyla uzantı yayımlama. SP erişim belirteci kullanmak için aşağıdaki TFX CLI komutunu yürütür:

tfx extension publish --publisher my-publisher --vsix my-publisher.my-extension-1.0.0.vsix --auth-type pat -t <AAD_ACCESS_TOKEN>

Pipelines

S: Bir hizmet bağlantısı içinde yönetilen kimlik kullanabilir miyim? Hizmet bağlantımdaki hizmet sorumlusu için gizli dizileri nasıl daha kolay döndürebilirim? Gizli dizileri bir hizmet bağlantısında depolamaktan tamamen kaçınabilir miyim?

openID Bağlan protokolunu kullanarak iş yükü kimlik federasyonu Azure desteği; bu sayede Azure Pipelines'da hizmet sorumluları tarafından desteklenen gizli dizi içermeyen hizmet bağlantıları veya Microsoft Entra Id'de federasyon kimlik bilgileriyle yönetilen kimlikler oluşturabiliriz. Yürütme işlemi kapsamında işlem hattı kendi iç belirtecini bir Microsoft Entra belirteci ile değiştirebilir ve böylece Azure kaynaklarına erişim elde edebilir. Bu mekanizma uygulandıktan sonra üründe mevcut olan diğer Azure hizmet bağlantısı türlerine göre önerilir. Bu mekanizma, diğer OIDC uyumlu hizmet sağlayıcılarıyla gizli dizi içermeyen dağıtımlar ayarlamak için de kullanılabilir. Bu mekanizma önizleme aşamasındadır.

Repos

S: Depo kopyalama gibi git işlemlerini yapmak için hizmet sorumlusu kullanabilir miyim?

Y: Git'in PowerShell betiğindeki bir depoyu kopyalaması için PAT yerine hizmet sorumlusunun Microsoft Entra ID belirtecini nasıl geçirdiğimize ilişkin aşağıdaki örneği inceleyin.

$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}

İpucu

Belirtecinizi daha güvenli tutmak için kimlik bilgilerinizi her seferinde girmenize gerek kalmaması için kimlik bilgileri yöneticilerini kullanın. Ortam değişkeni değiştirilirse, PAT'ler yerine Microsoft Entra belirteçlerini (yani Microsoft Identity OAuth belirteçlerini) kabul edebilen Git Kimlik Bilgileri Yöneticisi'ni öneririz.

Git fetch çağrısı yapmak için Azure CLI'dan erişim belirtecini alma hakkında yararlı bir ipucu:

  1. Deponuzun Git yapılandırmasını açın:
git config -e
  1. Azure DevOps kaynağının UUID 499b84ac-1321-427f-aa17-267ca6975798değerinin olduğu aşağıdaki satırları ekleyin:
[credential]
    helper = "!f() { test \"$1\" = get && echo \"password=$(az account get-access-token --resource 499b84ac-1321-427f-aa17-267ca6975798 --query accessToken -o tsv)\"; }; f"
  1. Aşağıdakini kullanarak çalışıp çalışmadığını test edin:
GIT_TRACE=1 GCM_TRACE=1 GIT_CURL_VERBOSE=1 git fetch

Olası hatalar

'{provided objectId}' nesne kimliğine sahip hizmet sorumlusu oluşturulamadı

Kuruluşunuza bağlı kiracıda ile hizmet provided objectId sorumlusu yoktur. Yaygın nedenlerden biri, hizmet sorumlusunun nesne kimliği yerine uygulama kaydının nesne kimliğini geçirmenizdir. Hizmet sorumlusunun, belirli bir kiracı için uygulamayı temsil eden bir nesne olduğunu, uygulamanın kendisi olmadığını unutmayın. , service principal object ID kiracınızın "Kurumsal Uygulamalar" sayfasında bulunabilir. Uygulamanın adını arayın ve döndüren "Kurumsal Uygulama" sonucunu seçin. Bu sonuç, hizmet sorumlusu /kurumsal uygulamanın sayfasıdır ve Azure DevOps'ta hizmet sorumlusu oluşturmak için bu sayfada bulunan Nesne Kimliğini kullanabilirsiniz.

Erişim Reddedildi: {ID of the caller identity} öğesinin bu eylemi gerçekleştirmek için kaynak Kullanıcılar üzerinde aşağıdaki izinlere ihtiyacı var: Kullanıcı Ekle

Bu hatanın nedeni aşağıdakilerden biri olabilir:

  • Kuruluşun sahibi, proje koleksiyonu yöneticisi veya proje ya da ekip yöneticisi değilsiniz.
  • Proje veya ekip yöneticisisiniz, ancak 'Ekip ve proje yöneticilerinin yeni kullanıcıları davet etmelerine izin ver' ilkesi devre dışı bırakıldı.
  • Yeni kullanıcıları davet edebilen bir proje veya ekip yöneticisisiniz, ancak yeni bir kullanıcı davet ettiğinizde lisans atamaya çalışıyorsunuz. Proje veya ekip yöneticilerinin yeni kullanıcılara lisans atamasına izin verilmez. Davet edilen tüm yeni kullanıcılar, yeni kullanıcılar için varsayılan erişim düzeyinde eklenir. Lisans erişim düzeyini değiştirmek için bir PCA'ya başvurun.

Azure DevOps Graph Listesi API'sinde kuruluşta hizmet sorumluları olduğunu bilmemize rağmen boş liste döndürülüyor

Döndürülecek daha fazla kullanıcı sayfası olsa bile Azure DevOps Graph Listesi API'si boş bir liste döndürebilir. Listeleri yinelemek için öğesini continuationToken kullanın; sonunda hizmet sorumlularının döndürüldüğü bir sayfa bulabilirsiniz. continuationToken döndürülürse, BU API aracılığıyla daha fazla sonuç olduğu anlamına gelir. Bu mantık üzerinde geliştirme planlarımız olsa da, şu anda ilk X sonuçlarının boş döndürülmesi mümkündür.

TF401444: Hizmete erişimi etkinleştirmek için web tarayıcısında en az bir kez {tenantId'tenantId\servicePrincipalObjectId'} olarak oturum açın.

Hizmet sorumlusu kuruluşa davet edildiyse aşağıdaki hatayla karşılaşabilirsiniz. Hizmet sorumlusunun uygun kuruluşa eklendiğinden ve gerekli kaynaklara erişmek için gereken tüm izinlere sahip olduğundan emin olun.