Použití instančních objektů a spravovaných identit v Azure DevOps

Služby Azure DevOps

Služební entity a spravované identifikátory poskytují škálovatelné a zabezpečené ověřování pro automatizační pracovní postupy Azure DevOps. Tyto typy identit Microsoft Entra nabízejí lepší zabezpečení nad tradičními tokeny patového přístupu (PAT). Používají automatickou správu přihlašovacích údajů, kratší životnost tokenů a řízení přístupu na podnikové úrovni.

Výhody služebních principálů a spravovaných identit

Vylepšené zabezpečení

• Krátkodobé tokeny: Platnost tokenů Microsoft Entra vyprší každou hodinu, což snižuje riziko vystavení v porovnání s PAT (což může trvat až jeden rok).
• Automatická obměně: Spravované identity zpracovávají obměnu přihlašovacích údajů automaticky.
• Žádné uložené tajné kódy: Nutnost ukládat dlouhodobé přihlašovací údaje v kódu nebo konfiguraci se eliminuje.

Provozní excelentnost

• Centralizovaná správa: Řízení přístupu prostřednictvím zásad Microsoft Entra ID a oprávnění Azure DevOps
• Možnosti auditu: Sledování vzorů ověřování a přístupu prostřednictvím komplexního protokolování
• Efektivní škálování: Podpora scénářů podnikové automatizace bez závislostí jednotlivých uživatelů

Moderní ověřování

• Založené na standardech: Používá protokoly OAuth 2.0 a OpenID Connect.
• Podpora vícefaktorového ověřování: Dědí zásady zabezpečení organizace.
• Podmíněný přístup: Použije pokročilé zásady zabezpečení na základě kontextu.

Principy instančních objektů a spravovaných identit

Principály služby

Objekty hlavní služby jsou objekty Microsoft Entra, které představují aplikace v rámci klienta. Definují, co může aplikace dělat, ke kterým prostředkům má přístup a kdo ji může používat. Služební principály se vytvoří automaticky, když zaregistrujete aplikaci v Microsoft Entra ID a poskytnete zabezpečený způsob, jak se aplikace ověřují a přistupují k prostředkům.

Klíčové charakteristiky

• Jsou vytvořeny prostřednictvím registrace aplikace v Microsoft Entra ID.
• Podpora víceklientských scénářů
• Vyžaduje explicitní správu přihlašovacích údajů (certifikáty nebo tajné klíče klienta).
• Jsou ideální pro aplikace, které se potřebují ověřovat v různých prostředích.

Spravované identity

Spravované identity jsou speciálním typem služebního principu, který Azure spravuje automaticky. Eliminují potřebu vývojářů spravovat přihlašovací údaje tím, že poskytují automaticky spravovanou identitu v Microsoft Entra ID pro prostředky Azure.

Typy spravovaných identit

Spravovaná identita přiřazená systémem:

• Automaticky vytvořené a svázané s konkrétním prostředkem Azure.
• Životní cyklus spravovaný Azure (odstraněný při odstranění prostředku)
• Relace 1:1 s prostředkem Azure
• Nejvhodnější pro aplikace nasazené v jednom prostředku Azure.

Spravovaná identita přiřazená uživatelem:

• Vytvořeno jako samostatný prostředek Azure.
• Dá se přiřadit k několika prostředkům Azure.
• Životní cyklus se spravuje nezávisle na přidružených prostředcích.
• Nejvhodnější pro aplikace, které běží na více prostředcích nebo potřebují sdílenou identitu.

Kdy použít každý typ:

• Instanční objekty: nasazení mezi cloudy, kanály kontinuální integrace a průběžného doručování (CI/CD), aplikace mimo Azure.
• Spravované identity přiřazené systémem: Jednoúčelové aplikace prostředků Azure (Azure Functions, Azure App Service).
• Spravované identity přiřazené uživatelem: Aplikace s více prostředky, scénáře sdílených identit.

Průvodce implementací

Postupujte podle těchto kroků k implementaci servisních principálů nebo spravovaných identit pro ověřování v Azure DevOps. Kompletní příklady kódu najdete v našich ukázkových aplikacích.

Krok 1: Vytvoření identity

Zvolte odpovídající typ identity na základě vašeho scénáře nasazení.

Možnost A: Vytvoření servisního principála (registrace aplikace)

Služební identity dobře fungují pro kanály CI/CD, scénáře napříč cloudovými prostředími a aplikace, které potřebují flexibilní možnosti nasazení.

1. Zaregistrujte aplikaci v Centru pro správu Microsoft Entra.

2. Přejděte na Registrace> aplikacíNová registrace.

3. Konfigurace aplikace:

   • Název: Použijte popisný název aplikace.
   • Typy účtů: Vyberte odpovídající podporu tenanta.
   • Identifikátor URI přesměrování: Pro scénáře mezi službami ponechte prázdné hodnoty.

4. Vytvoření přihlašovacích údajů pro ověřování:

   • Doporučeno: Nahrajte certifikát pro lepší zabezpečení.
   • Alternativní: Vytvoření tajného klíče klienta (vyžaduje pravidelnou obměnu).

Důležité

Když zaregistrujete aplikaci, Azure vytvoří objekt aplikace i objekt role služby. Při přidání do Azure DevOps použijte ID objektu instančního objektu (v podokně Podnikové aplikace ), nikoli ID objektu aplikace.

Další informace najdete v následujících článcích:

• Objekty aplikace a servisního účtu v Microsoft Entra ID
• Vytvoření principálu služby

Možnost B: Vytvoření spravované identity

Spravované identity poskytují nejjednodušší prostředí ověřování pro aplikace hostované v Azure.

Pro spravovanou identitu přiřazenou systémem:

1. Přejděte k prostředku Azure, jako je App Service nebo aplikace Azure Functions.
2. Přejděte dopřiřazeného systému>.
3. Přepněte stav na Zapnuto.
4. Vyberte Uložit a uložte konfiguraci.

Pro spravovanou identitu přiřazenou uživatelem:

1. Vytvořte spravovanou identitu na webu Azure Portal.
2. Přejděte na Vytvoření prostředku>Spravovaná identita.
3. Nakonfigurujte základní nastavení a vytvořte prostředek.
4. Podle potřeby přiřaďte prostředky.

Další informace najdete v následujících článcích:

• Přehled spravovaných identit
• Správa spravovaných identit přiřazených uživatelem

Krok 2: Přidání identity do Azure DevOps

Po vytvoření identity v Microsoft Entra ID ji přidejte do organizace Azure DevOps a udělte tak přístup k prostředkům.

Požadavky

• Role správce kolekce projektů
• Role správce projektu nebo správce týmu, když zásady pozvání umožňují správcům týmu přidávat uživatele.

Přidání identity

Přidání identity prostřednictvím portálu Azure DevOps:

1. Přejděte naUživatelé> organizace.

2. Vyberte Přidat uživatele.

3. Zadejte zobrazovaný název služebního hlavního objektu nebo spravované identity.

4. Vyberte odpovídající úroveň přístupu a přístup k projektu.

5. Pošlete pozvánku.

   

Přidejte identitu prostřednictvím kódu programu:

K automatizaci procesu použijte rozhraní REST API ServicePrincipalEntitlements .

Další aspekty:

• Vyhledejte správné ID: V centru pro správu Microsoft Entra použijte ID objektu instančního objektu v podokně Podnikové aplikace , nikoli ID objektu registrace aplikace.
• Omezení tenanta: Identity můžete přidat jenom ze stejného tenanta, ke kterému je vaše organizace Azure DevOps připojená. Scénáře napříč tenanty najdete v alternativním řešení nejčastějších dotazů.

Krok 3: Konfigurace oprávnění

Nakonfigurujte jemná oprávnění pro pověřeného zástupce služby nebo spravovanou identitu v prostředí Azure DevOps. Na rozdíl od jiných služeb Azure používá Azure DevOps svůj vlastní model oprávnění místo oprávnění aplikace Microsoft Entra.

Možnosti oprávnění:

• Přímé přiřazení: Přiřaďte oprávnění přímo identitě.
• Členství ve skupinách: Přidejte do skupin zabezpečení Azure DevOps nebo Microsoft Entra.
• Úrovně přístupu: Přiřaďte odpovídající úroveň licence (Basic, Basic + Test Plans nebo Předplatitel sady Visual Studio).

Osvědčené postupy:

• Použít nejnižší oprávnění: Udělte jenom minimální potřebná oprávnění.
• Používejte skupiny: Spravujte oprávnění prostřednictvím skupin pro snadnější údržbu.
• Pravidelné kontroly: Pravidelně auditujte oprávnění.

Možnosti správy oprávnění:

• Portál Azure DevOps: Vyberteoprávnění> organizace.
• Rozhraní REST API: Pro programovou správu používejte rozhraní Graph API instančního objektu .

Důležité

Azure DevOps versus oprávnění Microsoft Entra: Azure DevOps nepoužívá oprávnění aplikace Microsoft Entra ID. Veškeré řízení přístupu se spravuje prostřednictvím systému oprávnění Azure DevOps, který umožňuje podrobná oprávnění na úrovni projektu a prostředků.

Krok 4: Získání tokenů ID Microsoft Entra

Získejte přístupové tokeny pro ověřování aplikací pomocí rozhraní API a služeb Azure DevOps.

Pro principály služeb

Tok přihlašovacích údajů klienta:

POST https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id={client-id}
&scope=https://app.vssps.visualstudio.com/.default
&client_secret={client-secret}
&grant_type=client_credentials

Použití ověřování certifikátu (doporučeno):

using Microsoft.Identity.Client;

var app = ConfidentialClientApplicationBuilder
    .Create(clientId)
    .WithCertificate(certificate)
    .WithAuthority(new Uri($"https://login.microsoftonline.com/{tenantId}"))
    .Build();

var result = await app
    .AcquireTokenForClient(new[] { "https://app.vssps.visualstudio.com/.default" })
    .ExecuteAsync();

string accessToken = result.AccessToken;

Pro spravované identity

Z prostředků Azure:

using Azure.Identity;
using Azure.Core;

var credential = new ManagedIdentityCredential();
var tokenRequest = new TokenRequestContext(new[] { "https://app.vssps.visualstudio.com/.default" });
var token = await credential.GetTokenAsync(tokenRequest);

string accessToken = token.Token;

Použití služby Azure Instance Metadata Service:

GET http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://app.vssps.visualstudio.com/
Metadata: true

Azure CLI pro ad hoc operace

Pro jednorázové operace nebo testování použijte Azure CLI:

# For service principal
az login --service-principal --username {client-id} --password {client-secret} --tenant {tenant-id}
az account get-access-token --resource https://app.vssps.visualstudio.com/

# For managed identity (from Azure resource)
az login --identity
az account get-access-token --resource https://app.vssps.visualstudio.com/

Další informace naleznete v tématu Získání tokenů Microsoft Entra.

Krok 5: Použití tokenů s Azure DevOps

Získané tokeny použijte k ověřování volání rozhraní REST API a dalších operací Azure DevOps.

Provádění ověřených volání rozhraní API:

using System.Net.Http;
using System.Net.Http.Headers;

var client = new HttpClient();
client.DefaultRequestHeaders.Authorization = 
    new AuthenticationHeaderValue("Bearer", accessToken);

var response = await client.GetAsync(
    "https://dev.azure.com/{organization}/_apis/projects?api-version=7.1");

Příklady videí

Běžné scénáře integrace

• Informační kanály NuGet: Připojení pomocíNuGet.exe nebo rozhraní příkazového řádku dotnet
• Publikování na Marketplace: Publikování rozšíření prostřednictvím příkazového řádku
• Azure Pipelines: Vytváření připojení služeb zálohovaných spravovanými identitami
• Operace Gitu: Klonování úložišť pomocí Git Credential Manageru

Kompletní příklady kódu najdete v našich ukázkových aplikacích.

Aspekty správy

Instanční objekty a spravované identity mají v porovnání s uživatelskými účty různé charakteristiky správy.

Licencování

• Každá identita vyžaduje licenci v každé organizaci, ke které se připojuje.
• Fakturace ve více organizacích se nevztahuje na instanční objekty.
• Pravidla licencování založená na skupinách se automaticky nevztahují. Licence musíte přiřadit přímo.

Správa identit

• E-mailové adresy se nepoužívají, takže e-mailem nejsou žádné pozvánky.
• Zobrazované názvy nebo avatary se v Azure DevOps nemění.
• Zobrazované názvy se dědí z ID Microsoft Entra.

Členství ve skupinách

• Můžete je přidat do skupin Microsoft Entra a skupin Azure DevOps.
• Má technické omezení, které brání zobrazení v seznamech členů skupiny Microsoft Entra (pouze omezení uživatelského rozhraní).
• Může stále dědit oprávnění ze skupin Microsoft Entra, do kterých patří.

Zhmotnění

• Je nutné explicitně přidat do organizací (bez automatické materializace, jako jsou uživatelé).
• Povinné, protože instanční objekty se nemůžou interaktivně přihlásit.

Hlavní rozdíly mezi uživatelskými účty

Instanční objekty a spravované identity mají v porovnání s běžnými uživateli specifická omezení.

Capabilities

• ✅ Generování tokenů Microsoft Entra pro přístup k rozhraní API
• ✅ Přístup k prostředkům Azure DevOps se správnými oprávněními
• ✅ Připojte se ke skupinám zabezpečení a týmům.
• ❌ Vytvořte pats nebo klíče Secure Shellu.
• ❌ Přihlaste se interaktivně nebo se přihlaste přes webové uživatelské rozhraní.
• ❌ Vytvořte nebo vlastní organizace.
• ❌Podpora toků OAuth v Azure DevOps

Fakturování

• Počítá se jako samostatná licence v každé organizaci. (Není k dispozici žádná sleva pro více organizací.)
• Musí přiřadit úroveň přístupu přímo. (Pravidla skupiny se nevztahují automaticky.)

Nejčastější dotazy

Q. Proč mám místo PAT používat instanční objekt nebo spravovanou identitu?

A. Instanční objekty a spravované identity nabízejí významné výhody zabezpečení oproti patům.

Výhody zabezpečení:

• Kratší životnost: Platnost tokenů Microsoft Entra vyprší každou hodinu ve srovnání s PAT, což může trvat až rok.
• Automatická obměna: Spravované identity obměňují přihlašovací údaje automaticky.
• Žádné sdílené tajné kódy: Riziko uložení nebo náhodného vystavení dlouhodobých tokenů se eliminuje.
• Centralizované řízení: Spravováno prostřednictvím Microsoft Entra ID pomocí podnikových zásad zabezpečení.

Provozní výhody:

• Záznam auditu: Protokoluje zcela ověřovací vzory a vzory přístupu.
• Podmíněný přístup: Použije zásady na základě umístění, zařízení a rizikových faktorů.
• Žádné účty služeb: Eliminuje závislost na jednotlivých uživatelských účtech pro automatizaci.

Příklady migrace najdete v tématu Nahrazení PAT pomocí tokenů Microsoft Entra.

Q. Jaké jsou limity četnosti instančních objektů a spravovaných identit?

A. Instanční objekty a spravované identity mají stejné limity rychlosti jako uživatelé.

Q. Bude použití této funkce stát více?

A. Instanční objekty a spravované identity se účtují jako uživatelé na základě úrovně přístupu. Mezi klíčové rozdíly patří:

• Žádná sleva za fakturaci ve více organizacích: Každá identita se počítá jako samostatná licence v každé organizaci.
• Přiřazení licence: Úrovně přístupu musí být přiřazeny přímo. (Pravidla skupiny se nevztahují automaticky.)
• Platí stejné cenové úrovně: Basic, Basic + Testovací plány a sazby pro předplatitele sady Visual Studio.

Q. Můžu do své organizace přidat spravovanou identitu z jiného tenanta?

A. Identity můžete přidávat přímo z připojeného tenanta vaší organizace. Pro scénáře napříč tenanty použijte toto alternativní řešení.

Nastavení spravované identity mezi tenanty:

1. Vytvořte spravovanou identitu přiřazenou uživatelem v tenantovi prostředku.
2. Přiřaďte ho k prostředku Azure, jako je virtuální počítač nebo aplikace Functions).
3. Vytvořte trezor klíčů a vygenerujte certifikát (formát bez PEM).
4. Udělte spravované identitě přístup k trezoru klíčů pomocí oprávnění získat a vypsat tajný klíč.
5. Stáhněte si certifikát ve formátu CER (jenom veřejný klíč).
6. Zaregistrujte aplikaci v cílovém tenantovi.
7. Nahrajte certifikát do registrace aplikace.
8. Přidejte instanční objekt do organizace Azure DevOps.
9. Nakonfigurujte ověřování pomocí certifikátu z trezoru klíčů.

// Example: Acquire token using managed identity certificate
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);
    return keyVaultSecret.Value.Value;
}

private static async Task<AuthenticationResult> GetAppRegistrationAADAccessToken(
    string applicationClientID, string appTenantId)
{
    byte[] privateKeyBytes = Convert.FromBase64String(await GetSecret(keyVaultName, secretName));
    var certificate = new X509Certificate2(privateKeyBytes, (string)null, X509KeyStorageFlags.MachineKeySet);

    var app = ConfidentialClientApplicationBuilder.Create(applicationClientID)
        .WithCertificate(certificate)
        .WithAuthority(new Uri($"https://login.microsoftonline.com/{appTenantId}"))
        .Build();

    var result = await app.AcquireTokenForClient(
        new[] { "499b84ac-1321-427f-aa17-267ca6975798/.default" })
        .ExecuteAsync();

    return result;
}

Důležité

Pravidelně obměňujte certifikáty kvůli osvědčeným postupům zabezpečení.

Běžné chyby a řešení

Úložiště Git s názvem nebo identifikátorem neexistuje nebo nemáte oprávnění.

Řešení: Ujistěte se, že instanční objekt má alespoň základní licenci. Licence účastníků neposkytují přístup k úložišti.

Nepodařilo se vytvořit služební hlavní objekt s ID objektu.

Řešení: Ověřte, že používáte ID objektu instančního objektu z podokna Podnikové aplikace , nikoli ID objektu registrace aplikace.

Vyhledání správného ID:

1. Přejděte do Centra >Enterprise.
2. Vyhledejte název aplikace.
3. Použijte ID objektu v podokně Podnikové aplikace .

Přístup byl odepřen: Vyžaduje oprávnění k přidání uživatelů.

Možné příčiny a řešení:

• Nedostatečná role: Musí to být správce kolekce projektů (PCA) nebo projekt nebo správce týmu s povolenými oprávněními pozvat.
• Omezení zásad: Zkontrolujte, jestli je povolená zásada Povolit týmu a správcům projektů pozvat nové uživatele .
• Přiřazení licencí: Správci projectu nemůžou při pozvání přiřazovat licence. Obraťte se na PCA a požádejte o změny licencí.

Rozhraní AZURE DevOps Graphs List API vrátí prázdný seznam.

Řešení: Slouží continuationToken k iteraci na všech stránkách. Instanční objekty se můžou objevit na pozdějších stránkách kvůli chování stránkování rozhraní API.

TF401444: Chyba vyžadující přihlášení

Řešení: Ujistěte se, že je instanční objekt správně přidaný do organizace s požadovanými oprávněními. Tato chyba značí, že identita není v organizaci rozpoznána.

Související obsah

• Ukázkové aplikace a příklady kódu
• Referenční informace k rozhraní API oprávnění servisního principalu
• Reference k Graph API pro Service Principal
• Možnosti ověřování Microsoft Entra
• Doprovodné materiály k ověřování pro Azure DevOps