Aracılığıyla paylaş

Azure DevOps'ta hizmet sorumlularını ve yönetilen kimlikleri kullanma

Azure DevOps Services

Not

Azure Active Directory (Azure AD) artık Microsoft Entra Id'dir. Daha fazla bilgi için bkz. Azure AD için yeni ad.

Microsoft Entra hizmet sorumlularını ve yönetilen kimlikleri Azure DevOps Services kuruluşlarınıza uygulama kimlikleri olarak ekleyerek kuruluş kaynaklarınıza erişim izni verin. Birçok ekip için bu özellik, şirketinizdeki otomasyon iş akışlarını destekleyen uygulamaları doğrularken kişisel erişim belirteçlerine (PAT) kıyasla geçerli 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 uygulama kimliğiyle 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. Takip etmek içinörnek uygulamalarımızdan birine bakmayı göz önünde bulundurun.

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

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

1. Seçenek: Uygulama hizmet sorumlusu oluşturma

Yeni bir uygulama kaydı oluşturduğunuzda, Microsoft Entra Id içinde bir uygulama nesnesi oluşturulur. Uygulama hizmet asıl nesnesi, 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 için aşağıdaki makalelere bakın:

2. Seçenek: 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ğı, bu kimliği Microsoft Entra ID’den belirteç istemek için 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şuna hizmet sorumlusu ekleme

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 Proje Koleksiyonu Yöneticileri (PCA) veya Proje Yöneticileri ve Ekip Yöneticileri'ni içerir.

İpucu

Kuruluşa hizmet sorumlusu eklemek için uygulamanın veya yönetilen kimliğin görünen adını girin. ServicePrincipalEntitlements APIaracılığıyla program aracılığıyla 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.

Kullanıcılar Hub'ında hizmet sorumlularının ve yönetilen kimliklerin ekran görüntüsü.

Not

Yalnızca kuruluşunuzun bağlı olduğu kiracı için yönetilen kimlik veya hizmet sorumlusu ekleyebilirsiniz. Hizmet ilkeleri, aynı anda birden fazla kiracıya erişmek için çok kiracılı hale getirilebilir. Yönetilen kimlikler yalnızca tek bir kiracıya ait olabilir. Farklı bir kiracıdaki yönetilen kimliğe erişmek için SSS'deki geçici çözümü inceleyin.

3. Hizmet sorumlusunda izinleri ayarlama

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. Hizmet sorumlularında CRUD işlemlerini gerçekleştirmek için Service Principal Graph APIs'i de kullanabilirsiniz.

Bu izinlerin ayarlanması, diğer Azure kaynakları için bir Microsoft Entra uygulamasında uygulama izinlerini ayarlamaya alışma yönteminizden farklı olabilir. Azure DevOps, Azure portalı üzerinden uygulama kayıtlarında kullanılabilen "Uygulama izinleri" kurulumuna güvenmez. Bu uygulama izinleri, kiracıya bağlı tüm kuruluşlarda hizmet sorumlusuna izinler uygular ve Azure DevOps'ta sağlanan kuruluş, proje veya nesne izinleri hakkında bilgi sahibi değildir. Hizmet sorumlularına daha ayrıntılı izinler sunmak için Microsoft Entra Kimlikleri yerine kendi izin modelimizi kullanırız.

4. Hizmet sorumlusunu yönetme

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) eklenebilir. Şu anda bunları Microsoft Entra grup üyeleri listesinde görüntüleyebilmemizi engelleyen bir teknik sınırlama vardır. Bu sınırlama Azure DevOps grupları için geçerli değildir. Bununla birlikte, hizmet sorumlusu, ait olduğu Microsoft Entra grubunun üzerinde belirlenen tüm grup izinlerini devralmaya devam eder.
  • Bir Microsoft Entra grubundaki kullanıcılar, bir yöneticinin bir grup oluşturup buna bir Microsoft Entra grubu eklemesi nedeniyle 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 sorumluları, çok kuruluşlu faturalama seçili olsa bile, eklendikleri her kuruluşta lisans alır.

5. Microsoft Entra ID belirteci edinin

Bir Microsoft Entra ID jetonunu program aracılığıyla alma

Yönetilen kimlik için bir erişim simgesi almak, Microsoft Entra ID belgelerini takip ederek yapılabilir. hizmet sorumluları ve yönetilen kimliklerörneklerine bakın.

Döndürülen erişim belirteci, tanımlanan rollere sahip bir JSON web belirtecidir (JWT), Taşıyıcıolarak belirteci kullanarak kuruluş kaynaklarına erişmek için kullanılabilir.

Geçici işlemler için Azure CLI aracılığıyla tek seferlik bir Microsoft Entra ID belirteci almak daha kolay olabilir. Bu yaklaşım, API çağrıları veya git kopyalama işlemleri gibi düzenli olarak döndürülecek kalıcı belirteç gerektirmeyen işlemler için tercih edilir.

6. Azure DevOps kaynaklarda kimlik doğrulaması yapmak için Microsoft Entra ID belirtecini kullanın

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.

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 örnekleri takip edin.

Azure DevOps REST API çağrıları yapmanın yanı sıra hizmet sorumlularıyla kimlik doğrulaması yapmaya yönelik bazı yaygın senaryolar şu belgelerde bulunabilir:

Hizmet sorumlularının kullanıcılardan farkı

  • Azure DevOps'ta hizmet sorumlusu görünen adını veya avatarı değiştiremezsiniz.
  • Hizmet ilkesi, çok kuruluşlu faturalamaolsa bile katıldığı her kuruluş için lisans olarak sayılı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. Azure DevOps REST API'lerini çağırmak için kendi Microsoft Entra ID belirteçlerini oluşturabilirler.
  • Hizmet sorumluları Azure DevOps OAuthdesteklemez.

Sıkça Sorulan Sorular

Soru: 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). Uygun şekilde saklanmayan PAT'ler yanlış ellere geçebilir ve genellikle daha uzun olan ömrü boyunca kullanılabilir. Microsoft Entra jetonlarının süresi her saat dolar ve sızdırıldığında genel risk faktörünü sınırlar. Yaygın PAT senaryoları içinyerine Microsoft Entra belirtecini nasıl keşfedebileceğinize ilişkin bazı örnekleri paylaşıyoruz.

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

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

Hizmet ilke sahipleri 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: 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 bir 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. Bir sanal makineye bağlayın ve bu yönetilen kimliği ona atayın.
  3. Bir anahtar kasası oluşturun ve bir sertifika oluşturun (türünde PEMolamaz). Bu sertifikayı oluşturduğunuzda, daha sonra kullandığımız aynı ada sahip bir gizli anahtar da oluşturulur.
  4. Anahtar kasasından özel anahtarı okuyabilmesi için yönetilen kimliğe erişim verin. Anahtar kasasında "Gizli izinler" altında "Al/Listele hakları" ile bir erişim ilkesi oluşturun ve "Temel seç" altında yönetilen kimliği arayın.
  5. Oluşturulan sertifikayı, sertifikanızın CER özel bölümünü içermemesini sağlayan biçimde 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. Bu kod örneğiyle yönetilen kimlik sertifikasını kullanan bu hizmet sorumlusundan bir Microsoft Entra erişim belirteci alın:

Not

Sertifikalarınızı her zaman düzenli olarak döndürün.

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

Olası hatalar

Adı veya tanımlayıcısı '{repoName}' olan Git deposu yok veya denediğiniz işlem için izinleriniz yok.

Hizmet sorumlusunun depolara erişmek için en az bir "Temel" lisans olduğundan emin olun. "Paydaş" lisansı yeterli değildir.

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

Kuruluşunuza bağlı kiracıda provided objectId hizmet ilkesi 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} bu eylemi gerçekleştirmek için kaynak Kullanıcılar üzerinde aşağıdaki izinlere sahip olmalıdır: 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'si, kuruluşta hizmet sorumluları olduğunu bilmemize rağmen boş bir liste döndürür

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 continuationToken ile kullanın, sonunda hizmet ilkelerinin 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 edilmezse, 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.