Permettre l’accès à Azure à un principal de service

  • 6 minutes

Un principal de service ne peut rien faire dans votre environnement Azure en soi. De la même manière, un utilisateur ne peut pas utiliser vos ressources Azure s’il ne dispose pas des autorisations correspondantes. Dans cette leçon, vous allez découvrir comment autoriser des principaux de service à déployer et configurer des ressources Azure, tout en évitant d’octroyer des autorisations inutiles.

Notes

Les commandes de cette unité sont présentées pour illustrer les concepts. N’exécutez pas encore les commandes. Vous allez bientôt mettre en pratique ce que vous apprenez ici.

Autorisation du principal de service

Jusqu’à présent, vous vous êtes concentré sur les principaux de service et sur la manière dont ils peuvent être utilisés pour prouver l’identité d’un pipeline à Microsoft Entra ID. Cela concerne l’authentification.

Une fois que Microsoft Entra ID a authentifié un principal de service, la question suivante se pose : quelles tâches ce principal de service peut-il accomplir ? Il s’agit du concept d’autorisation. Sa responsabilité incombe au système de contrôle d’accès en fonction du rôle (RBAC) Azure, parfois appelé gestion des identités et des accès (IAM). À l’aide du système RBAC d’Azure, vous pouvez permettre à un principal de service l’accès à un groupe de ressources, un abonnement ou un groupe d’administration spécifique.

Notes

Il vous suffit d’utiliser le système RBAC d’Azure pour permettre l’accès en vue de créer et gérer des ressources Azure, comme vos comptes de stockage, votre plan App Service et les réseaux virtuels. Microsoft Entra ID a également son propre système de rôles, parfois appelé rôles d’annuaire. Vous utilisez ces rôles pour octroyer des autorisations aux principaux de service afin qu’ils gèrent Microsoft Entra ID. Ce module n’aborde pas ce sujet en détail, mais sachez que le terme rôle peut être utilisé dans les deux cas de figure dans la documentation.

Sélectionner l’attribution de rôle appropriée pour votre pipeline

Une attribution de rôle comporte trois parties principales : la personne à qui le rôle est attribué (destinataire), ce que le rôle permet de faire (rôle), ainsi que la ou les ressource(s) auxquelles l’attribution de rôle s’applique (étendue).

Destinataire

Quand vous travaillez avec un principal de service, vous attribuez des rôles pour ce principal de service. Vous utilisez l’ID d’application du principal de service pour identifier le bon principal de service pour ce destinataire.

Rôle

Cela peut être légèrement plus compliqué de déterminer le rôle à attribuer. Dans Azure, il existe quelques rôles courants :

  • Lecteur, qui permet au destinataire de lire des informations sur les ressources, mais pas de les modifier ni de les supprimer.
  • Contributeur, qui permet au destinataire de créer des ressources, ainsi que de lire et modifier des ressources existantes. Toutefois, les contributeurs ne peuvent pas permettre l’accès aux ressources à d’autres principaux.
  • Propriétaire, qui permet un contrôle total sur les ressources, notamment l’octroi de l’accès à d’autres principaux.

Attention

Vous devez uniquement octroyer aux principaux de service les autorisations minimales dont ils ont besoin pour effectuer leurs tâches. La plupart du temps, le rôle Propriétaire est trop permissif pour un pipeline de déploiement.

Il existe également un grand nombre de rôles spécifiques qui fournissent un accès uniquement à un sous-ensemble de fonctionnalités. Vous pouvez également créer votre propre définition de rôle personnalisée pour spécifier la liste exacte des autorisations que vous souhaitez attribuer.

Remarque

Les définitions de rôles personnalisées peuvent être un moyen puissant d’octroi des autorisations pour vos ressources Azure, mais elles peuvent s’avérer difficiles à utiliser. Il n’est pas toujours facile de déterminer exactement les autorisations que vous devez ajouter à une définition de rôle personnalisée. Vous risquez de rendre accidentellement les définitions de rôle trop restrictives ou trop permissives. En cas de doute, il est préférable d’utiliser à la place l’une des définitions de rôle intégrées. Les définitions de rôle personnalisées ne sont pas traitées dans le cadre de ce module.

Étendue

Vous devez déterminer l’ampleur de l’attribution du rôle. Cette décision affecte le nombre de ressources que le principal de service peut modifier. Les étendues courantes sont les suivantes :

  • Ressource unique : vous pouvez permettre l’accès à une ressource spécifique uniquement. En règle générale, les pipelines de déploiement n’utilisent pas cette étendue, car un pipeline crée des ressources qui n’existent pas encore, ou bien il reconfigure plusieurs ressources.
  • Groupe de ressources : vous pouvez permettre l’accès à toutes les ressources au sein d’un groupe de ressources. Les Contributeurs et les Propriétaires peuvent également créer des ressources au sein du groupe. Il s’agit d’une bonne option pour de nombreux pipelines de déploiement.
  • Abonnement : vous pouvez permettre l’accès à toutes les ressources au sein d’un abonnement. Si vous avez plusieurs applications, charges de travail ou environnements dans un abonnement unique, vous pouvez octroyer des autorisations à l’étendue de l’abonnement. Toutefois, cette configuration est généralement trop permissive pour un pipeline de déploiement. Vous devez plutôt envisager de définir l’étendue de vos attributions de rôles aux groupes de ressources, sauf si votre workflow de déploiement lui-même doit créer des groupes de ressources.

N’oubliez pas que les attributions de rôles sont héritées. Si vous attribuez un rôle à un abonnement, le destinataire a accès à chaque groupe de ressources et à chaque ressource au sein de cet abonnement.

Sélection de l’attribution de rôle appropriée

Maintenant que vous êtes familiarisé avec les composants d’une attribution de rôle, vous pouvez choisir les valeurs appropriées pour vos scénarios. Voici quelques indications à prendre en compte :

  • Utilisez le rôle le moins permissif possible. Si votre pipeline ne déploie que des modèles Bicep de base et ne gère pas les attributions de rôles, n’utilisez pas le rôle Propriétaire.
  • Utilisez l’étendue la plus limitée possible. La plupart des pipelines ont uniquement besoin de déployer des ressources dans un groupe de ressources. Ils ne doivent donc pas recevoir d’attributions de rôles étendues à l’abonnement.
  • Pour de nombreux pipelines, l’option par défaut appropriée pour une attribution de rôle est le rôle Contributeur sur l’étendue du groupe de ressources.
  • Pensez à toutes les fonctions de votre pipeline, ainsi qu’aux éventuelles fonctions futures. Par exemple, vous pouvez envisager de créer une définition de rôle personnalisée pour le pipeline de déploiement de votre site web et d’octroyer uniquement des autorisations pour App Service et Application Insights. Le mois prochain, vous devrez peut-être ajouter un compte Azure Cosmos DB à votre fichier Bicep, mais le rôle personnalisé empêchera la création de ressources Azure Cosmos DB. Il est souvent préférable d’utiliser un rôle intégré à la place, ou bien une combinaison de rôles intégrés, afin d’éviter d’avoir à modifier vos définitions de rôles de manière répétée. Envisagez d’utiliser Azure Policy pour appliquer vos exigences de gouvernance aux services, références SKU et emplacements autorisés.
  • Testez le pipeline pour vérifier que l’attribution de rôle fonctionne.

Combinaison et mise en correspondance des attributions de rôles

Vous pouvez créer plusieurs attributions de rôles qui fournissent des autorisations différentes sur des étendues différentes. Par exemple, vous pouvez attribuer à un principal de service le rôle Lecteur pour l’étendue de l’abonnement entier, puis attribuer séparément au même principal de service le rôle Contributeur pour un groupe de ressources spécifique. Quand le principal de service tente d’utiliser le groupe de ressources, l’attribution la plus permissive est appliquée.

Utilisation de plusieurs environnements

Vous travaillez probablement avec plusieurs environnements, comme les environnements de développement, de test et de production pour vos applications. Les ressources de chaque environnement doivent être déployées sur des groupes de ressources ou des abonnements différents.

Vous devez créer des principaux de service distincts pour chaque environnement et octroyer à chaque principal de service le jeu minimal d’autorisations dont il a besoin pour ses déploiements. Veillez particulièrement à éviter de mélanger les autorisations pour les déploiements de production et les autorisations pour les déploiements dans des environnements hors production.

Créer une attribution de rôle pour un principal de service

Pour créer une attribution de rôle pour un principal de service, utilisez la commande az role assignment create. Vous devez spécifier le destinataire, le rôle et l’étendue :

az role assignment create \
  --assignee 00001111-aaaa-2222-bbbb-3333cccc4444 \
  --role Contributor \
  --scope "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyWebsite" \
  --description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

Examinons chaque approche :

  • --assignee spécifie le principal de service. Pour éviter toute ambiguïté, il est recommandé d’utiliser l’ID de l’application.
  • --role spécifie le rôle. Si vous utilisez un rôle intégré, vous pouvez le spécifier par son nom. Si vous utilisez une définition de rôle personnalisé, spécifiez l’ID de définition de rôle complet.
  • --scope spécifie la portée. Il s’agit généralement d’un ID de ressource pour une seule ressource, un groupe de ressources ou un abonnement.
  • --description est une description explicite de l’attribution de rôle.

Pour créer une attribution de rôle pour un principal de service, utilisez la cmdlet New-AzRoleAssignment. Vous devez spécifier le destinataire, le rôle et l’étendue :

New-AzRoleAssignment `
  -ApplicationId 00001111-aaaa-2222-bbbb-3333cccc4444 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyWebsite' `
  -Description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

Examinons chaque approche :

  • -ApplicationId spécifie l’ID d’inscription d’application du principal de service.
  • -RoleDefinitionName spécifie le nom d’un rôle intégré. Si vous utilisez une définition de rôle personnalisée, spécifiez l’ID de définition de rôle complet à l’aide de l’argument -RoleDefinitionId place.
  • -Scope spécifie la portée. Il s’agit généralement d’un ID de ressource pour une seule ressource, un groupe de ressources ou un abonnement.
  • -Description est une description explicite de l’attribution de rôle.

Conseil

Il est conseillé de fournir une justification pour vos attributions de rôles en spécifiant une description. Une description aide ultérieurement toute personne qui passe en revue les attributions de rôles à comprendre leur finalité. Cela leur permet également de comprendre vos choix concernant le destinataire, le rôle et l’étendue.

Notes

Les attributions de rôles peuvent avoir besoin de quelques minutes avant de devenir actives.

Créer un principal de service et une attribution de rôle en une seule opération

Vous pouvez également créer une attribution de rôle en même temps que vous créez un principal de service. Le code est similaire à la commande que vous avez utilisée pour créer un principal de service dans les leçons précédentes, mais avec des arguments supplémentaires :

az ad sp create-for-rbac \
  --name MyPipeline \
  --role Contributor \
  --scopes "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite"

$servicePrincipal = New-AzADServicePrincipal `
  -DisplayName MyPipeline `
  -Role Contributor `
  -Scope '/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite'

Permettre l’accès à l’aide de Bicep

Les attributions de rôles correspondent à des ressources Azure. Cela signifie que vous pouvez créer une attribution de rôle à l’aide de Bicep. Vous pouvez effectuer cette opération si vous initialisez vos groupes de ressources à l’aide de Bicep, puis déployez les ressources dans le groupe de ressources à l’aide d’un principal de service. Voici un exemple de définition de Bicep pour l’attribution de rôle ci-dessus :

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2023-04-01-preview' = {
  name: guid(principalId, roleDefinitionId, resourceGroup().id)
  properties: {
    principalType: 'ServicePrincipal'
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId)
    principalId: principalId
    description: 'The deployment pipeline for the company\'s website needs to be able to create resources within the resource group.'
  }
}

Examinons chaque approche :

  • name est l’identificateur unique pour l’attribution de rôle. Il doit se présenter sous la forme d’un identificateur global unique (GUID). Il est recommandé d’utiliser la fonction guid() dans Bicep pour créer un GUID et d’utiliser l’ID de principal, l’ID de définition de rôle et l’étendue comme arguments de départ pour la fonction, afin de garantir que vous créez un nom unique pour chaque attribution de rôle.
  • principalType doit être définie sur ServicePrincipal.
  • roleDefinitionId est l’ID de ressource complet de la définition de rôle que vous attribuez. Vous allez en grande partie travailler avec des rôles intégrés et trouver l’ID de définition de rôle dans la documentation des rôles intégrés Azure. Par exemple, le rôle Contributeur a l’ID de définition de rôle b24988ac-6180-42a0-ab88-20f7382dd24c. Quand vous le spécifiez dans votre fichier Bicep, vous l’exprimez à l’aide d’un ID de ressource complet, comme /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c.
  • principalId est l’ID d’objet du principal de service. Veillez à ne pas utiliser l’ID d’application ni l’ID d’objet de l’inscription d’application.
  • description est une description explicite de l’attribution de rôle.