Szolgáltatásnevek és felügyelt identitások használata

  • Cikk

Azure DevOps Services

Adjon hozzá Microsoft Entra-szolgáltatásneveket és felügyelt identitásokat az Azure DevOps-szervezetekhez, hogy hozzáférést biztosítson a szervezeti erőforrásokhoz. Sok csapat számára ez a funkció a személyes hozzáférési jogkivonatok (PAT-k) életképes és előnyben részesített alternatíva lehet, ha a vállalat automatizálási munkafolyamatait használó alkalmazásokat hitelesít.

A szolgáltatásnevek és a felügyelt identitások ismertetése

A szolgáltatásnevek olyan biztonsági objektumok egy Microsoft Entra-alkalmazásban, amelyek meghatározzák, hogy egy alkalmazás mit tehet egy adott bérlőben. Az azure portalon vannak beállítva az alkalmazásregisztrációs folyamat során, és úgy vannak konfigurálva, hogy hozzáférjenek az Azure-erőforrásokhoz, például az Azure DevOpshoz. A szolgáltatásnevek szervezethez való hozzáadásával és a rajtuk lévő engedélyek beállításával megállapíthatjuk, hogy egy szolgáltatásnév jogosult-e a szervezeti erőforrások elérésére, és hogy melyeket.

A felügyelt identitások egy másik Microsoft Entra-funkció, amely az alkalmazás szolgáltatásneveihez hasonlóan működik. Ezek az objektumok identitásokat biztosítanak az Azure-erőforrásokhoz, és lehetővé teszik a Microsoft Entra-hitelesítést támogató szolgáltatások számára a hitelesítő adatok megosztását. Ez egy vonzó lehetőség, mert a Microsoft Entra ID gondoskodik a hitelesítő adatok kezeléséről és rotálásáról. Bár a felügyelt identitás beállítása eltérő lehet az Azure Portalon, az Azure DevOps mindkét biztonsági objektumot ugyanúgy kezeli, mint egy definiált engedélyekkel rendelkező szervezet új identitását. A cikk további részében a felügyelt identitásokra és a szolgáltatásnevekre hivatkozunk, felcserélhetően szolgáltatásnévként, hacsak nincs megadva.

Az alábbi lépésekkel hitelesítheti ezeket az identitásokat az Azure DevOpsban, hogy lehetővé tegye számukra a saját nevében végzett műveleteket.

Felügyelt identitások és szolgáltatásnevek konfigurálása

A megvalósítás eltérő lehet, de magas szinten az alábbi lépések segítenek a szolgáltatásnevek használatának megkezdésében a munkafolyamatban. Fontolja meg az egyik mintaalkalmazás megtekintését, hogy követhesse a saját példáját.

1. Új felügyelt identitás vagy alkalmazásszolgáltatásnév létrehozása

Hozzon létre egy alkalmazásszolgáltatásnevet vagy egy felügyelt identitást az Azure Portalon.

Alkalmazás-szolgáltatásnév létrehozása

Új alkalmazásregisztráció létrehozásakor egy alkalmazásobjektum jön létre a Microsoft Entra-azonosítóban. Az alkalmazás-szolgáltatásnév egy adott bérlő alkalmazásobjektumának ábrázolása. Ha egy alkalmazást több-bérlős alkalmazásként regisztrál, egy egyedi szolgáltatásnév-objektum jelöli az alkalmazásobjektumot minden bérlőhöz, amelybe az alkalmazás hozzáadódik.

További információ:

Felügyelt identitás létrehozása

A felügyelt identitások létrehozása az Azure Portalon jelentősen eltér az alkalmazások szolgáltatásnévvel való beállításától. A létrehozási folyamat megkezdése előtt meg kell fontolnia, hogy milyen típusú felügyelt identitást szeretne létrehozni:

  • Rendszer által hozzárendelt felügyelt identitás: Egyes Azure-szolgáltatások lehetővé teszik a felügyelt identitások közvetlen engedélyezését egy szolgáltatáspéldányon. Ha engedélyezi a rendszer által hozzárendelt felügyelt identitást, egy identitás jön létre a Microsoft Entra-azonosítóban. Az identitás az adott szolgáltatáspéldány életciklusához van kötve. Az erőforrás törlésekor az Azure automatikusan törli az Identitást. A rendszer működése alapján csak az adott Azure-erőforrás használhatja ezt az identitást ahhoz, hogy tokeneket kérjen le a Microsoft Entra ID-ből.
  • Felhasználó által hozzárendelt felügyelt identitás : Létrehozhat egy felügyelt identitást önálló Azure-erőforrásként is, ha létrehoz egy felhasználó által hozzárendelt felügyelt identitást, és hozzárendeli azt egy Vagy több Azure-szolgáltatáspéldányhoz. A felhasználó által hozzárendelt felügyelt identitások esetében az identitás kezelése külön történik az azt használó erőforrásoktól.

További információkért tekintse meg az alábbi cikkeket és videót:

2. Szolgáltatásnevek hozzáadása és kezelése egy Azure DevOps-szervezetben

Miután konfigurálta a Szolgáltatásnevek szolgáltatást a Microsoft Entra Felügyeleti központban, ugyanezt kell tennie az Azure DevOpsban a szolgáltatásnevek szervezethez való hozzáadásával. Felveheti őket a Felhasználók lapon vagy a ServicePrincipalEntitlements API-kkal. Mivel nem tudnak interaktívan bejelentkezni, egy olyan felhasználói fióknak, amely felhasználókat adhat hozzá egy szervezethez, projekthez vagy csapathoz, fel kell vennie őket. Ilyen felhasználók például a Project Collection Rendszergazda istrators (PCA) vagy a Project Rendszergazda istrators és a Team Rendszergazda istrators, ha engedélyezve van a "Csoport- és projektgazdák meghívásának engedélyezése új felhasználók meghívására" szabályzat.

Tipp.

Ha szolgáltatásnevet szeretne hozzáadni a szervezethez, adja meg az alkalmazás vagy a felügyelt identitás megjelenítendő nevét. Ha úgy dönt, hogy programozott módon ad hozzá egy szolgáltatásnevet az ServicePrincipalEntitlements API-val, győződjön meg arról, hogy a szolgáltatásnév objektumazonosítóját adja meg, nem pedig az alkalmazás objektumazonosítóját.

PcA esetén szolgáltatásnév-hozzáférést is biztosíthat adott projektekhez, és hozzárendelhet egy licencet. Ha ön nem PCA, a projekttagságok vagy a licenchozzáférés szintjeinek frissítéséhez forduljon a PCA-hoz.

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

Feljegyzés

Csak ahhoz a bérlőhöz adhat hozzá felügyelt identitást vagy szolgáltatásnevet, amelyhez a szervezet csatlakozik. Ha egy másik bérlőben lévő felügyelt identitást szeretne elérni, tekintse meg a gyakori kérdések kerülő megoldását.

Miután hozzáadta a szolgáltatásnéveket a szervezethez, a szokásos felhasználói fiókokhoz hasonlóan kezelheti őket. Engedélyeket rendelhet közvetlenül egy szolgáltatásnévhez, hozzáadhatja a biztonsági csoportokhoz és a csapatokhoz, bármilyen hozzáférési szintre hozzárendelheti, és eltávolíthatja a szervezetből. A CRUD-műveletek szolgáltatásneveken való végrehajtására is használható Service Principal Graph APIs .

A szolgáltatásnevek kezelése a következő fő módokon különbözik a felhasználói fiókoktól:

  • A szolgáltatásnevek nem rendelkeznek e-mailekkel, ezért nem hívhatók meg a szervezetbe e-mailben.
  • A licencelési csoportszabályok jelenleg nem vonatkoznak a szolgáltatásnevekre. Ha hozzáférési szintet szeretne hozzárendelni egy szolgáltatásnévhez, ezt érdemes közvetlenül megtennie.
  • Bár a szolgáltatásnevek hozzáadhatók a Microsoft Entra-csoportokhoz (az Azure Portalon), a jelenlegi technikai korlátozás megakadályozza, hogy megjelenítsük őket a Microsoft Entra-csoporttagok listájában. Ez a korlátozás nem igaz az Azure DevOps-csoportokra. Ennek ellenére a szolgáltatásnév továbbra is örökli a Microsoft Entra-csoportra beállított csoportengedélyeket.
  • A Microsoft Entra-csoportok nem minden felhasználója tartozik azonnal egy Azure DevOps-szervezethez, csak azért, mert egy rendszergazda létrehoz egy csoportot, és hozzáad hozzá egy Microsoft Entra-csoportot. Van egy "materialization" nevű folyamatunk, amely akkor következik be, ha egy Microsoft Entra-csoportból származó felhasználó először jelentkezik be a szervezetbe. A szervezetbe bejelentkező felhasználók segítségével meghatározhatjuk, hogy mely felhasználók kapjanak licencet. Mivel a szolgáltatásnevek esetében a bejelentkezés nem lehetséges, a rendszergazdának explicit módon hozzá kell adnia azt egy szervezethez a korábban leírtak szerint.
  • A szolgáltatásnév megjelenítendő nevét vagy avatarját nem módosíthatja az Azure DevOpsban.
  • A szolgáltatásnév licencnek számít minden olyan szervezethez, amelyhez hozzá lesz adva, még akkor is, ha több szervezet számlázása van kiválasztva.

3. Azure DevOps-erőforrások elérése Microsoft Entra ID-jogkivonattal

Microsoft Entra-azonosító jogkivonat lekérése

A felügyelt identitás hozzáférési jogkivonatának beszerzéséhez kövesse a Microsoft Entra ID dokumentációját. További információkért tekintse meg a szolgáltatásnevekre és a felügyelt identitásokra vonatkozó példákat.

A visszaadott hozzáférési jogkivonat egy meghatározott szerepkörökkel rendelkező JWT, amely a jogkivonat tulajdonosként való használatával a szervezeti erőforrások eléréséhez használható.

A Microsoft Entra ID-jogkivonat használata az Azure DevOps-erőforrásokon való hitelesítéshez

A következő videós példában a PAT használatával végzett hitelesítésről áttérünk egy szolgáltatásnév jogkivonatának használatára. Először egy ügyfélkulcsot használunk a hitelesítéshez, majd az ügyféltanúsítvány használatára váltunk.

  • Bár a szolgáltatásnevek hozzáadhatók a Microsoft Entra-azonosító csoportokhoz (az Azure Portalon), a jelenlegi technikai korlátozás megakadályozza, hogy megjelenítsük őket a Microsoft Entra ID-csoporttagok listájában. Ez a korlátozás nem igaz az Azure DevOps-csoportokra. Ennek ellenére a szolgáltatásnév továbbra is örökli azokat a csoportengedélyeket, amelyek egy Microsoft Entra-azonosító csoportra vannak beállítva, amelyhez tartoznak.
  • A Microsoft Entra-azonosítók csoportjának nem minden felhasználója tartozik azonnal egy Azure DevOps-szervezethez, csak azért, mert egy rendszergazda létrehoz egy csoportot, és hozzáad hozzá egy Microsoft Entra-azonosítócsoportot. Van egy "materialization" nevű folyamatunk, amely akkor fordul elő, ha egy Microsoft Entra-azonosító csoportból származó felhasználó először jelentkezik be a szervezetbe. A szervezetbe bejelentkező felhasználók segítségével meghatározhatjuk, hogy mely felhasználók kapjanak licencet. Mivel a szolgáltatásnevek esetében a bejelentkezés nem lehetséges, a rendszergazdának explicit módon hozzá kell adnia azt egy szervezethez a korábban leírtak szerint.
  • A szolgáltatásnév megjelenítendő nevét vagy avatarját nem módosíthatja az Azure DevOpsban.
  • A szolgáltatásnév licencnek számít minden olyan szervezethez, amelyhez hozzá lesz adva, még akkor is, ha több szervezet számlázása van kiválasztva.

Egy másik példa bemutatja, hogyan csatlakozhat az Azure DevOpshoz egy felhasználó által hozzárendelt felügyelt identitás használatával egy Azure-függvényen belül.

Kövesse ezeket a példákat a mintaalkalmazások gyűjteményében található alkalmazáskód megkeresésével.

A szolgáltatásnevek az Azure DevOps REST API-k meghívására és a legtöbb művelet végrehajtására használhatók, de ez a következő műveletekre korlátozódik:

  • A szolgáltatásnevek nem lehetnek szervezettulajdonosok, és nem hozhatnak létre szervezeteket.
  • A szolgáltatásnevek nem hozhatnak létre jogkivonatokat, például személyes hozzáférési jogkivonatokat (PAT-okat) vagy SSH-kulcsokat. Létrehozhatnak saját Microsoft Entra ID-jogkivonatokat, és ezek a jogkivonatok az Azure DevOps REST API-k meghívására használhatók.
  • Szolgáltatásnevek esetében nem támogatjuk az Azure DevOps OAuth szolgáltatást.

Feljegyzés

A jogkivonatok létrehozásához csak az alkalmazásazonosítót használhatja, az Azure DevOpshoz társított erőforrás-URI-kat nem.

Gyakori kérdések

Általános

K: Miért érdemes szolgáltatásnevet vagy felügyelt identitást használni pat helyett?

V: Számos ügyfelünk egy meglévő PAT (személyes hozzáférési jogkivonat) helyére keres szolgáltatásnevet vagy felügyelt identitást. Az ilyen PAT-k gyakran egy szolgáltatásfiókhoz (megosztott csoportfiókhoz) tartoznak, amely az azure DevOps-erőforrások használatával hitelesíti az alkalmazásokat. A PAT-eket oly gyakran (legalább 180 nap) szorongatóan kell elforgatni. Mivel a PAT-k egyszerűen tulajdonosi jogkivonatok, vagyis olyan jogkivonat-sztringek, amelyek a felhasználó felhasználónevét és jelszavát jelölik, rendkívül kockázatosak, mivel könnyen rossz személy kezébe kerülhetnek. A Microsoft Entra-jogkivonatok óránként lejárnak, és frissítési jogkivonattal kell újragenerálva új hozzáférési jogkivonatot beszerezni, ami korlátozza a kiszivárogtatások általános kockázati tényezőit.

A szolgáltatásnévvel nem hozhat létre személyes hozzáférési jogkivonatot.

K: Milyen díjkorlátok vonatkoznak a szolgáltatásnevekre és a felügyelt identitásokra?

Válasz: Jelenleg a szolgáltatásnevek és a felügyelt identitások díjkorlátjai megegyeznek a felhasználókra vonatkozó korlátokkal.

K: A funkció használata több költséggel jár?

Válasz: A szolgáltatásnevek és a felügyelt identitások ára a felhasználókhoz hasonlóan van megosztva a hozzáférési szint alapján. Az egyik jelentős változás az, hogy hogyan kezeljük a "több szervezet számlázását" a szolgáltatásnevek esetében. A felhasználók csak egy licencnek számítanak, függetlenül attól, hogy hány szervezeten belül vannak. A szolgáltatásnevek egy licencnek számítanak minden olyan szervezetnél, amelyben a felhasználó található. Ez a forgatókönyv hasonló a szokásos "felhasználó-hozzárendelés-alapú számlázáshoz".

K: Használhatok szolgáltatásnevet vagy felügyelt identitást az Azure CLI-vel?

Válasz: Igen! Bárhol, ahol az Azure CLI-ben paT-okat kér, elfogadhatja a Microsoft Entra ID hozzáférési jogkivonatait is. Az alábbi példákból megtudhatja, hogyan adhat át Microsoft Entra-jogkivonatot a parancssori felülettel való hitelesítéshez.

# 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

Most szerezzünk be egy Microsoft Entra-jogkivonatot (az Azure DevOps-erőforrás UUID azonosítója 499b84ac-1321-427f-aa17-267ca6975798) és próbáljuk meg meghívni az Azure DevOps API-t úgy, hogy jogkivonatként Bearer átadjuk a fejlécekben:

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

Most már használhatja az cli a szokásos parancsokat.

K: Hozzáadhatok egy felügyelt identitást egy másik bérlőtől a szervezetemhez?

Válasz: Csak abból a bérlőből adhat hozzá felügyelt identitást, amelyhez a szervezet csatlakozik. Van azonban egy áthidaló megoldásunk, amely lehetővé teszi egy felügyelt identitás beállítását az "erőforrás-bérlőben", ahol az összes erőforrás található. Ezután engedélyezheti, hogy egy szolgáltatásnév használja a "célbérlelőben", ahol a szervezet csatlakozik. Kerülő megoldásként hajtsa végre az alábbi lépéseket:

  1. Hozzon létre egy felhasználó által hozzárendelt felügyelt identitást az Azure Portalon az erőforrás-bérlő számára.
  2. Csatlakozás egy virtuális gépre, és rendelje hozzá ezt a felügyelt identitást.
  3. Hozzon létre egy kulcstartót, és hozzon létre egy tanúsítványt (nem lehet "PEM" típusú). A tanúsítvány létrehozásakor egy azonos nevű titkos kód is létrejön, amelyet később használunk.
  4. Adjon hozzáférést a felügyelt identitáshoz, hogy beolvassa a titkos kulcsot a kulcstartóból. Hozzon létre egy hozzáférési szabályzatot a kulcstartóban a "Get/List" engedélyekkel (a "Titkos engedélyek" területen, és keressen rá a felügyelt identitásra az "Egyszerű kiválasztása" területen.
  5. Töltse le a létrehozott tanúsítványt "CER" formátumban, amely biztosítja, hogy ne tartalmazza a tanúsítvány privát részét.
  6. Hozzon létre egy új alkalmazásregisztrációt a célbérlében.
  7. Töltse fel a letöltött tanúsítványt az új alkalmazásba a "Tanúsítványok és titkos kódok" lapon.
  8. Adja hozzá az alkalmazás szolgáltatásnevét ahhoz az Azure DevOps-szervezethez, amelyhez hozzá szeretnénk férni, és ne felejtse el beállítani a szolgáltatásnevet a szükséges engedélyekkel.
  9. Ha a felügyelt identitástanúsítványt használó szolgáltatásnévből microsoft Entra hozzáférési jogkivonatot szeretne lekérni, tekintse meg a következő kódmintát:

Feljegyzés

A tanúsítványokat rendszeresen el kell forgatnia, mint mindig.

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

Összetevők

K: Használhatok egyszerű szolgáltatásnevet a hírcsatornákhoz való csatlakozáshoz?

Válasz: Igen, bármely Azure Artifacts-hírcsatornához csatlakozhat egy szolgáltatásnévvel. Az alábbi példákban bemutatjuk, hogyan csatlakozhat a Microsoft Entra ID-jogkivonathoz a NuGet, az npm és a Maven esetében, de más hírcsatornáknak is működniük kell.

NuGet-projekt beállítása Microsoft Entra-jogkivonattal

  1. Adjon hozzá egy nuget.config fájlt a projekthez a .csproj vagy .sln fájllal megegyező mappában.

    <?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. Microsoft Entra ID-jogkivonat beszerzése a szolgáltatásnévhez.

  3. Futtassa a következő parancsot a hitelesítő adatokkal való hitelesítéshez, majd adja hozzá a jogkivonatot a setapikey paranccsal. Ez a parancs hozzáadja a hírcsatorna forrását a nuget.config fájlhoz:

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

nuget setapikey <YOUR_ACCESS_TOKEN> -source <SOURCE_URL>

npm-projekt beállítása Microsoft Entra-jogkivonatokkal

Feljegyzés

A vsts-npm-auth eszköz nem támogatja a Microsoft Entra hozzáférési jogkivonatait.

  1. Vegyen fel egy fájlt .npmrc a projektbe, ugyanabban a könyvtárban, mint a saját package.json.

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

  2. Szerezze be a szolgáltatásnévhez vagy a felügyelt identitáshoz tartozó hozzáférési jogkivonatot.

  3. Adja hozzá ezt a kódot az Önhöz, ${user.home}/.npmrc és cserélje le a helyőrzőt [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] az előző lépés hozzáférési jogkivonatára.

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

Maven-projekt beállítása Microsoft Entra-jogkivonatokkal

  1. Adja hozzá az adattárat a saját <repositories> és <distributionManagement> a pom.xmlszakaszaihoz is.

    <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. Szerezze be a szolgáltatásnévhez vagy a felügyelt identitáshoz tartozó hozzáférési jogkivonatot.

  3. Adja hozzá vagy szerkessze a fájlt, settings.xml${user.home}/.m2 és cserélje le a helyőrzőt [AAD_SERVICE_PRINCIPAL_ACCESS_TOKEN] az előző lépés hozzáférési jogkivonatára.

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

Piactér

K: Használhatok egyszerű szolgáltatásnevet a bővítmények Visual Studio Marketplace-en való közzétételéhez?

V: Igen. Tegye a következőket.

  1. Szolgáltatásnév hozzáadása tagként egy közzétevői fiókhoz. A profilból lekérheti a szolgáltatásnév azonosítóját a Profilok – Get használatával. Ezután hozzáadhatja a szolgáltatásnevet tagként a közzétevőhöz az előző lépésben megadott azonosító használatával.

  2. Bővítmény közzététele TFX CLI-n keresztül sp használatával. Futtassa a következő TFX CLI-parancsot egy SP hozzáférési jogkivonat használatához:

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

Pipelines

K: Használhatok felügyelt identitást egy szolgáltatáskapcsolaton belül? Hogyan lehet egyszerűbben elforgatni a szolgáltatásnév titkos kulcsát a szolgáltatáskapcsolatban? Elkerülhetem a titkos kulcsok tárolását egy szolgáltatáskapcsolatban?

Azure-támogatás a számítási feladatok identitásának összevonását az OpenID Csatlakozás protokoll használatával, amely lehetővé teszi, hogy titkos kulcs nélküli szolgáltatáskapcsolatokat hozzunk létre az Azure Pipelines szolgáltatásnevek vagy felügyelt identitások által támogatott, összevont hitelesítő adatokkal rendelkező Azure Pipelinesban a Microsoft Entra-azonosítóban. A folyamat a végrehajtás részeként saját belső jogkivonatot cserélhet egy Microsoft Entra-jogkivonattal, ezáltal hozzáférést kap az Azure-erőforrásokhoz. A implementálás után ezt a mechanizmust ajánlott a termékben más, ma létező Azure-szolgáltatáskapcsolatokon keresztül alkalmazni. Ezzel a mechanizmussal titkos kulcs nélküli üzembe helyezéseket is beállíthat bármely más OIDC-kompatibilis szolgáltatónál. Ez a mechanizmus előzetes verzióban érhető el.

Repos

K: Használhatok egyszerű szolgáltatásnevet gitműveletek elvégzésére, például adattár klónozására?

Válasz: Tekintse meg az alábbi példát arra, hogyan adtunk át egy szolgáltatásnév Microsoft Entra-azonosító jogkivonatát PAT helyett, hogy klónozza az adattárat egy PowerShell-szkriptben.

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

Tipp.

A jogkivonat biztonságosabbá tételéhez használjon hitelesítőadat-kezelőket, hogy ne kelljen minden alkalommal megadnia a hitelesítő adatait. A Git Credential Managert javasoljuk, amely paT-ok helyett elfogadhat Microsoft Entra-jogkivonatokat (azaz Microsoft Identity OAuth-jogkivonatokat) a környezeti változók módosítása esetén.

Hasznos tipp arról, hogyan szerezheti be a hozzáférési jogkivonatot az Azure CLI-ből a git fetch meghívásához:

  1. Nyissa meg az adattár Git-konfigurációját:
git config -e
  1. Adja hozzá a következő sorokat, ahol az Azure DevOps-erőforrás UUID azonosítója a következő 499b84ac-1321-427f-aa17-267ca6975798:
[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. Tesztelje, hogy működik-e a következő használatával:
GIT_TRACE=1 GCM_TRACE=1 GIT_CURL_VERBOSE=1 git fetch

Lehetséges hibák

Nem sikerült létrehozni a(z) {provided objectId} objektumazonosítójú szolgáltatásnevet

A szervezethez csatlakoztatott bérlőben nincs szolgáltatásnév provided objectId . Az egyik gyakori ok, hogy az alkalmazásregisztráció objektumazonosítóját adja át a szolgáltatásnév objektumazonosítója helyett. Ne feledje, hogy a szolgáltatásnév egy objektum, amely egy adott bérlő alkalmazását jelöli, nem maga az alkalmazás. Ez service principal object ID a bérlő "Vállalati alkalmazások" lapján található. Keresse meg az alkalmazás nevét, és válassza ki a visszaadott "Vállalati alkalmazás" eredményt. Ez az eredmény a szolgáltatásnév/vállalati alkalmazás lapja, és az ezen a lapon található objektumazonosítóval létrehozhat egy szolgáltatásnevet az Azure DevOpsban.

Hozzáférés megtagadva: {ID of the caller identity} a következő engedélyre van szüksége az erőforrás felhasználói számára a művelet végrehajtásához: Felhasználók hozzáadása

A hiba oka az alábbi okok egyike lehet:

  • Nem Ön a szervezet, a projektgyűjtemény rendszergazdája vagy a projekt- vagy csapatadminisztrátor.
  • Ön projekt- vagy csoportadminisztrátor, de a "Csoport- és projektgazdák meghívásának engedélyezése új felhasználók meghívására" szabályzat le van tiltva.
  • Ön projekt- vagy csoportadminisztrátor, aki meghívhat új felhasználókat, de új felhasználó meghívásakor licenceket próbál hozzárendelni. A projekt- vagy csapatgazdák nem rendelhetnek licencet az új felhasználókhoz. Minden új meghívott felhasználó az új felhasználók alapértelmezett hozzáférési szintjén lesz hozzáadva. Lépjen kapcsolatba egy PCA-vel a licenchozzáférés szintjének módosításához.

Az Azure DevOps Graph List API üres listát ad vissza, annak ellenére, hogy tudjuk, hogy vannak szolgáltatásnevek a szervezetben

Előfordulhat, hogy az Azure DevOps Graph List API üres listát ad vissza, még akkor is, ha még több oldalnyi felhasználót kell visszatérnie. continuationToken A listával végigvezetheti a listákat, és végül megtalálhatja azt a lapot, ahol a szolgáltatásnevek vissza lesznek adva. Ha visszaad egy continuationToken értéket, az azt jelenti, hogy az API-val több találat érhető el. Bár terveink vannak a logika továbbfejlesztésére, jelenleg lehetséges, hogy az első X-eredmények üresen térnek vissza.

TF401444: Jelentkezzen be legalább egyszer {tenantId'tenantId\servicePrincipalObjectId'} néven egy webböngészőben a szolgáltatáshoz való hozzáférés engedélyezéséhez.

Ha a szolgáltatásnév nem lett meghívva a szervezetbe, az alábbi hibaüzenet jelenhet meg. Győződjön meg arról, hogy a szolgáltatásnév hozzá van adva a megfelelő szervezethez, és rendelkezik a szükséges erőforrások eléréséhez szükséges engedélyekkel.