Partager via

Utiliser des principaux de service et des identités managées dans Azure DevOps

Azure DevOps Services

Les principaux de service et les identités managées fournissent une authentification sécurisée et évolutive pour les flux de travail d’automatisation Azure DevOps. Ces types d’identités Microsoft Entra offrent une sécurité renforcée par rapport aux jetons d’accès personnels traditionnels (PAT). Ils utilisent la gestion automatique des informations d’identification, les durées de vie des jetons plus courtes et les contrôles d’accès de niveau entreprise.

Avantages des principaux de service et des identités managées

Sécurité renforcée

  • Jetons de courte durée : les jetons Microsoft Entra expirent toutes les heures, ce qui réduit le risque d’exposition par rapport aux PAT (qui peuvent durer jusqu’à un an).
  • Rotation automatique : les identités managées gèrent automatiquement la rotation des informations d’identification.
  • Aucun secret stocké : la nécessité de stocker des informations d’identification de longue durée dans le code ou la configuration est supprimée.

Excellence opérationnelle

  • Gestion centralisée : contrôler l’accès via les stratégies d’ID Microsoft Entra et les autorisations Azure DevOps.
  • Fonctionnalités d’audit : suivez les modèles d’authentification et d’accès via la journalisation complète.
  • Mettre à l’échelle efficacement : prendre en charge les scénarios d’automatisation d’entreprise sans dépendances utilisateur individuelles.

Authentification moderne

  • Normes basées sur les normes : utilise les protocoles OAuth 2.0 et OpenID Connect.
  • Prise en charge de l’authentification multifacteur : hérite des stratégies de sécurité organisationnelles.
  • Accès conditionnel : applique des stratégies de sécurité avancées en fonction du contexte.

Comprendre les principaux de service et les identités managées

Principaux de service

Les principaux de service sont des objets Microsoft Entra qui représentent des applications au sein d’un locataire. Ils définissent ce qu’une application peut faire, les ressources auxquelles elle peut accéder et qui peut l’utiliser. Les principaux de service sont créés automatiquement lorsque vous inscrivez une application dans Microsoft Entra ID et fournissent un moyen sécurisé pour les applications d’authentifier et d’accéder aux ressources.

Caractéristiques clés

  • Sont créés via l’inscription d’application dans l’ID Microsoft Entra.
  • Prendre en charge les scénarios multilocataires.
  • Exiger une gestion explicite des informations d’identification (certificats ou secrets clients).
  • Sont idéales pour les applications qui doivent s’authentifier dans différents environnements.

Identités managées

Les identités managées sont un type spécial de principal de service qu’Azure gère automatiquement. Ils éliminent la nécessité pour les développeurs de gérer les informations d’identification en fournissant une identité managée automatiquement dans l’ID Microsoft Entra pour les ressources Azure.

Types d’identités managées

Identité managée affectée par le système :

  • Créé et lié automatiquement à une ressource Azure spécifique.
  • Cycle de vie géré par Azure (supprimé lorsque la ressource est supprimée).
  • Relation un-à-un avec la ressource Azure.
  • Idéal pour les applications déployées sur une seule ressource Azure.

Identité managée affectée par l’utilisateur :

  • Créé en tant que ressource Azure autonome.
  • Peut être affecté à plusieurs ressources Azure.
  • Cycle de vie géré indépendamment des ressources associées.
  • Idéal pour les applications qui s’exécutent sur plusieurs ressources ou qui ont besoin d’une identité partagée.

Quand utiliser chaque type :

  • Principaux de service : déploiements interclouds, intégration continue et pipelines de livraison continue (CI/CD), applications en dehors d’Azure.
  • Identités managées affectées par le système : applications de ressources Azure uniques (Azure Functions, Azure App Service).
  • Identités managées affectées par l’utilisateur : applications multi-ressources, scénarios d’identité partagée.

Guide d’implémentation

Suivez ces étapes pour implémenter des principaux de service ou des identités managées pour l’authentification Azure DevOps. Pour obtenir des exemples de code complets, consultez nos exemples d’applications.

Étape 1 : Créer votre identité

Choisissez le type d’identité approprié en fonction de votre scénario de déploiement.

Option A : Créer un principal de service (enregistrement d’application)

Les principaux de service fonctionnent bien pour les pipelines CI/CD, les scénarios inter-cloud et les applications qui nécessitent des options de déploiement flexibles.

  1. Inscrivez une application dans le Centre d’administration Microsoft Entra.

  2. Accédez à inscriptions d'applications>Nouvelle inscription.

  3. Configurez l’application :

    • Nom : utilisez un nom descriptif pour votre application.
    • Types de compte : sélectionnez la prise en charge appropriée du locataire.
    • URI de redirection : laissez vide pour les scénarios de service à service.

  4. Créez des informations d’identification d’authentification :

    • Recommandé : chargez un certificat pour une sécurité renforcée.
    • Alternative : Créez une clé secrète client (nécessite une rotation régulière).

Importante

Lorsque vous inscrivez une application, Azure crée à la fois un objet d’application et un objet principal de service. Utilisez l’ID d’objet du principal de service (trouvé dans le volet Applications d’entreprise ) lorsque vous l’ajoutez à Azure DevOps, et non à l’ID d’objet de l’application.

Pour plus d’informations, consultez les articles suivants :

Option B : Créer une identité managée

Les identités managées offrent l’expérience d’authentification la plus simple pour les applications hébergées par Azure.

Pour l’identité managée affectée par le système :

  1. Accédez à votre ressource Azure, telle qu’App Service ou une application Azure Functions.
  2. Accédez à Identité>Système attribué.
  3. Basculez l’état sur Activé.
  4. Sélectionnez Enregistrer pour enregistrer la configuration.

Pour l’identité managée affectée par l’utilisateur :

  1. Créez l’identité managée dans le portail Azure.
  2. Accédez à Créer une ressource>Identité Managée.
  3. Configurez les paramètres de base et créez la ressource.
  4. Assignez aux ressources selon les besoins.

Pour plus d’informations, consultez les articles suivants :

Étape 2 : Ajouter l’identité à Azure DevOps

Après avoir créé votre identité dans Microsoft Entra ID, ajoutez-la à votre organisation Azure DevOps pour accorder l’accès aux ressources.

Prerequisites

  • Rôle d’administrateur de collection de projets.
  • Rôle d’administrateur de projet ou d’administrateur d’équipe lorsque la stratégie d’invitation permet aux administrateurs d’équipe d’ajouter des utilisateurs.

Ajouter l’identité

Pour ajouter l’identité via le portail Azure DevOps :

  1. Accédez auxutilisateurs> de l’organisation.

  2. Sélectionnez Ajouter des utilisateurs.

  3. Entrez le nom d’affichage de votre principal de service ou de votre identité gérée.

  4. Sélectionnez le niveau d’accès approprié et l’accès au projet.

  5. Envoyez l’invitation.

    Capture d’écran montrant les principaux de service et les identités managées dans le Hub Utilisateurs.

Ajoutez l’identité par programmation :

Utilisez l’API REST ServicePrincipalEntitlements pour automatiser le processus.

Autres considérations :

  • Recherchez l’ID correct : Utilisez l’ID d’objet du principal de service dans le volet Applications d’entreprise dans le Centre d’administration Microsoft Entra, et non l’ID d’objet de l’inscription de l’application.
  • Restrictions de locataire : Vous ne pouvez ajouter des identités qu’à partir du même locataire auquel votre organisation Azure DevOps est connectée. Pour les scénarios inter-locataires, consultez la solution de contournement dans la FAQ.

Étape 3 : Configurer les autorisations

Configurez des autorisations granulaires pour votre principal de service ou votre identité managée dans Azure DevOps. Contrairement à d’autres services Azure, Azure DevOps utilise son propre modèle d’autorisation plutôt que les autorisations d’application Microsoft Entra.

Options d’autorisation :

  • Affectation directe : attribuez des autorisations directement à l’identité.
  • Appartenance au groupe : Ajouter à Azure DevOps ou aux groupes de sécurité Microsoft Entra.
  • Niveaux d’accès : attribuez le niveau de licence approprié (De base, Basic + Test Plans ou abonné Visual Studio).

Meilleures pratiques :

  • Appliquez le privilège minimum : accordez uniquement les autorisations minimales nécessaires.
  • Utilisez des groupes : gérez les autorisations via des groupes pour faciliter la maintenance.
  • Révisions régulières : Auditer régulièrement les autorisations.

Options de gestion des autorisations :

Importante

Autorisations Azure DevOps et Microsoft Entra : Azure DevOps n’utilise pas les autorisations d’application Microsoft Entra ID. Tout le contrôle d’accès est géré via le système d’autorisation Azure DevOps, qui permet des autorisations granulaires au niveau du projet et des ressources.

Étape 4 : Obtenir des jetons d’ID Microsoft Entra

Obtenez des jetons d’accès pour authentifier vos applications avec les API et services Azure DevOps.

Pour les principaux de service

Utilisez le flux d’informations d’identification du client :

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

Utilisez l’authentification par certificat (recommandé) :

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;

Pour les identités managées

À partir de ressources 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;

Utilisez le service de métadonnées d’instance Azure :

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 pour les opérations ad hoc

Pour les opérations ponctuelles ou les tests, utilisez 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/

Pour plus d’informations, consultez Acquérir des jetons Microsoft Entra.

Étape 5 : Utiliser des jetons avec Azure DevOps

Utilisez vos jetons acquis pour authentifier les appels d’API REST et d’autres opérations Azure DevOps.

Effectuez des appels d’API authentifiés :

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");

Exemples vidéo

Scénarios d’intégration courants

Pour obtenir des exemples de code complets, consultez nos exemples d’applications.

Considérations relatives à la gestion

Les principaux de service et les identités managées ont des caractéristiques de gestion différentes par rapport aux comptes d’utilisateur.

Licensing

  • Chaque identité nécessite une licence dans chaque organisation qu’elle rejoint.
  • La facturation multi-organisation ne s’applique pas aux principaux de service.
  • Les règles de licence basées sur un groupe ne s’appliquent pas automatiquement. Vous devez attribuer directement des licences.

Gestion des identités

  • Les adresses e-mail ne sont pas utilisées. Il n’y a donc aucune invitation par e-mail.
  • Les noms d’affichage ou les avatars ne sont pas modifiés dans Azure DevOps.
  • Les noms d’affichage sont hérités de l’ID Microsoft Entra.

Appartenance au groupe

  • Peut être ajouté aux groupes Microsoft Entra et aux groupes Azure DevOps.
  • Présente une limitation technique qui empêche l’affichage dans les listes de membres du groupe Microsoft Entra (limitation de l’interface utilisateur uniquement).
  • Peut toujours hériter des autorisations des groupes Microsoft Entra auxquels ils appartiennent.

Matérialisation

  • Doit être explicitement ajouté aux organisations (aucune matérialisation automatique comme les utilisateurs).
  • Obligatoire, car les principaux de service ne peuvent pas se connecter de manière interactive.

Principales différences par rapport aux comptes d’utilisateur

Les principaux de service et les identités managées ont des limitations spécifiques par rapport aux utilisateurs réguliers.

Capacités

  • ✅ Générez des jetons Microsoft Entra pour l’accès aux API.
  • ✅ Accédez aux ressources Azure DevOps avec des autorisations appropriées.
  • ✅ Rejoignez des groupes de sécurité et des équipes.
  • ❌ Créez des pats ou des clés Secure Shell.
  • ❌ Connectez-vous de manière interactive ou accédez via une interface utilisateur web.
  • ❌ Créez ou possédez des organisations.
  • ❌ Prendre en charge les flux OAuth Azure DevOps .

Facturation

  • Compté comme une licence distincte dans chaque organisation. (Il n’y a pas de remise multi-organisation.)
  • Doit affecter directement le niveau d’accès. (Les règles de groupe ne s’appliquent pas automatiquement.)

Questions fréquentes

Q. Pourquoi dois-je utiliser un principal de service ou une identité managée au lieu d’un PAT ?

A. Les principaux de service et les identités managées offrent des avantages importants en matière de sécurité par rapport aux PAT.

Avantages de sécurité :

  • Durée de vie plus courte : les jetons Microsoft Entra expirent toutes les heures par rapport aux PAT, qui peuvent durer jusqu’à un an.
  • Rotation automatique : les identités managées pivotent automatiquement les informations d’identification.
  • Aucun secret partagé : le risque de stockage ou d’exposition accidentelle de jetons de longue durée est éliminé.
  • Contrôle centralisé : géré via l’ID Microsoft Entra avec des stratégies de sécurité d’entreprise.

Avantages opérationnels :

  • Piste d’audit : journalise complètement l’authentification et les modèles d’accès.
  • Accès conditionnel : applique des stratégies en fonction de l’emplacement, de l’appareil et des facteurs de risque.
  • Aucun compte de service : élimine la dépendance vis-à-vis des comptes d’utilisateur individuels pour l’automatisation.

Pour obtenir des exemples de migration, consultez Remplacer les paTs par des jetons Microsoft Entra.

Q. Quelles sont les limites de débit sur les principaux de service et les identités managées ?

A. Les principaux de service et les identités managées ont les mêmes limites de débit que les utilisateurs.

Q. L’utilisation de cette fonctionnalité coûte-t-elle plus cher ?

A. Les principaux de service et les identités managées sont facturés comme les utilisateurs en fonction du niveau d’accès. Les principales différences sont les suivantes :

  • Aucune remise de facturation multi-organisation : chaque identité compte comme une licence distincte dans chaque organisation.
  • Attribution de licence : les niveaux d’accès doivent être attribués directement. (Les règles de groupe ne s’appliquent pas automatiquement.)
  • Mêmes niveaux tarifaires : Les tarifs des abonnements De base, Basic + Test et Visual Studio s’appliquent.

Q. Puis-je ajouter une identité managée à partir d’un autre locataire à mon organisation ?

A. Vous pouvez ajouter des identités directement à partir du locataire connecté de votre organisation uniquement. Pour les scénarios interlocataires, utilisez cette solution de contournement.

Pour configurer une identité managée entre locataires :

  1. Créez une identité managée affectée par l’utilisateur dans le locataire de ressource.
  2. Affectez-la à une ressource Azure, telle qu’une machine virtuelle ou une application Functions).
  3. Créez un coffre de clés et générez un certificat (format non PEM).
  4. Accordez à l’identité managée l’accès au coffre de clés avec les autorisations Obtenir et Répertorier les secrets.
  5. Téléchargez le certificat au format CER (clé publique uniquement).
  6. Inscrivez l’application dans le locataire cible.
  7. Chargez le certificat dans l’inscription de l’application.
  8. Ajoutez le principal de service à l’organisation Azure DevOps.
  9. Configurez l’authentification à l’aide du certificat à partir du coffre de clés.
// 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;
}

Importante

Faire pivoter régulièrement des certificats pour les meilleures pratiques de sécurité.

Erreurs courantes et solutions

Le référentiel Git portant le nom ou l’identificateur n’existe pas ou vous n’avez pas d’autorisations

Solution: Vérifiez que le principal de service dispose au moins d’une licence de base. Les licences des parties prenantes ne fournissent pas d’accès au référentiel.

Échec de la création d'un service principal avec l'ID d'objet

Solution: Vérifiez que vous utilisez l’ID d’objet du principal de service à partir du volet Applications d’entreprise , et non l’ID d’objet de l’inscription de l’application.

Pour trouver l’ID correct :

  1. Accédez auxapplications d’entreprise du > d’administration Microsoft Entra.
  2. Recherchez le nom de votre application.
  3. Utilisez l’ID d’objet dans le volet Applications d’entreprise .

Accès refusé : a besoin d’autorisations pour ajouter des utilisateurs

Causes et solutions possibles :

L’API Liste Graphs Azure DevOps retourne une liste vide

Solution: Permet continuationToken d’effectuer une itération dans toutes les pages. Les principaux de service peuvent apparaître sur des pages ultérieures en raison du comportement de pagination de l’API.

TF401444 : erreur « Connexion requise »

Solution: Vérifiez que le principal de service est ajouté correctement à l’organisation avec les autorisations requises. Cette erreur indique que l’identité n’est pas reconnue dans l’organisation.

Contenu connexe

  • Last updated on