Accorder l’accès à Azure à une identité de charge de travail

  • 6 minutes

En soi, une identité de charge de travail ne peut rien faire dans votre environnement Azure, tout comme un utilisateur ne peut utiliser vos ressources Azure que s’il est autorisé à le faire. Dans cette unité, vous allez découvrir comment autoriser des identités de charge de travail à déployer et configurer des ressources Azure tout en évitant d’octroyer des autorisations inutiles.

Autorisation d’identité de charge de travail

Jusqu’à présent, vous vous êtes concentré sur les identités de charge de travail et sur la manière dont elles peuvent être utilisées pour prouver l’identité d’un workflow de déploiement à Microsoft Entra ID. Cela concerne l’authentification.

Une fois que Microsoft Entra ID a authentifié une identité de charge de travail, la question suivante se pose : quelles tâches cette identité de charge de travail peut-elle effectuer ? 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 autoriser à une identité de charge de travail l’accès à un groupe de ressources, un abonnement ou un groupe d’administration spécifique.

Remarque

Il vous suffit d’utiliser le système RBAC d’Azure pour accorder l’accès afin de créer et gérer des ressources Azure, comme vos comptes de stockage, votre plan Azure 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 identités de charge de travail afin qu’elles gèrent Microsoft Entra ID. Ce module n’aborde pas ce sujet en détail, mais sachez que le terme rôle est utilisé dans les deux cas de figure dans certaines documentations.

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

Une attribution de rôle comporte trois parties principales : la personne à qui le rôle est attribué (destinataire), ce qu’elle peut faire (rôle) et la ou les ressources auxquelles l’attribution de rôle s’applique (étendue).

Destinataire

Quand vous utilisez une identité de charge de travail, vous attribuez des rôles pour celle-ci. Pour attribuer un rôle, vous devez d’abord créer un principal de service, ce qui vous permet d’accorder vos rôles d’application dans Azure. Une fois le principal de service créé, vous pouvez continuer à utiliser l’ID d’application de l’inscription de l’application.

Pour créer un principal de service, utilisez la commande az ad sp create et spécifiez l’ID d’application de l’inscription d’application :

az ad sp create --id A123b4567c-1234-1a2b-2b1a-1234abc12345

Pour créer un principal de service, utilisez la cmdlet New-AzADServicePrincipal et spécifiez l’ID d’application de l’inscription d’application :

New-AzADServicePrincipal -AppId A123b4567c-1234-1a2b-2b1a-1234abc12345

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

Attention

Vous devez octroyer aux identités de charge de travail seulement les autorisations minimales dont elles ont besoin pour effectuer leurs travaux. La plupart du temps, le rôle Propriétaire est trop permissif pour un workflow de déploiement.

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

Notes

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 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 l’identité de charge de travail peut modifier. Les étendues courantes sont les suivantes :

  • Ressource unique : vous pouvez permettre l’accès à une ressource spécifique. En règle générale, les workflows de déploiement n’utilisent pas cette étendue, car un workflow 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 workflows 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 workflow 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 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 workflow ne déploie que des fichiers 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 workflows 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 workflows, 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 workflow ainsi qu’aux éventuelles fonctions futures. Par exemple, vous pouvez envisager de créer une définition de rôle personnalisée pour le workflow de déploiement de votre site web et d’octroyer des autorisations seulement 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 workflow 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 affecter à une identité de charge de travail le rôle Lecteur avec comme étendue l’abonnement en entier. Vous pouvez affecter séparément à la même identité de charge de travail le rôle Contributeur pour un groupe de ressources spécifique. Quand l’identité de charge de travail tente d’utiliser le groupe de ressources, l’attribution la plus permissive est appliquée.

Utilisation de plusieurs environnements

Vous utilisez probablement 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 connexions de service distinctes pour chaque environnement. Accordez à chaque identité de charge de travail l’ensemble minimal d’autorisations dont elle a besoin pour ses déploiements. Veillez tout spécialement à é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 une identité de charge de travail

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

az role assignment create \
  --assignee A123b4567c-1234-1a2b-2b1a-1234abc12345 \
  --role Contributor \
  --scope "/subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/resourceGroups/ToyWebsite" \
  --description "The deployment workflow for the company's website needs to be able to create resources within the resource group."

Examinons chaque approche :

  • --assignee spécifie l’identité de charge de travail. Vous pouvez spécifier cela de plusieurs façons, mais l’utilisation de l’ID d’application est une bonne pratique, car elle évite toute ambiguïté.
  • --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 une identité de charge de travail, utilisez la cmdlet New-AzRoleAssignment. Spécifiez le destinataire, le rôle et l’étendue :

New-AzRoleAssignment `
  -ApplicationId A123b4567c-1234-1a2b-2b1a-1234abc12345 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/resourceGroups/ToyWebsite' `
  -Description "The deployment workflow 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 de l’identité de charge de travail.
  • -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.

Octroyer l’accès en utilisant 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 procéder de la sorte si vous initialisez vos groupes de ressources en utilisant Bicep, puis déployez les ressources dans le groupe de ressources en utilisant une identité de charge de travail. Voici un exemple de définition Bicep pour l’attribution de rôle précédente :

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

Examinons chaque approche :

  • name est un identificateur global unique (GUID) pour l’attribution de rôle. C’est une bonne pratique que d’utiliser la fonction guid() dans Bicep pour créer un GUID. Pour être sûr que vous créez un nom unique pour chaque attribution de rôle, utilisez l’ID principal, l’ID de définition de rôle et l’étendue comme arguments pour la fonction.

  • 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 travaillez principalement avec des rôles intégrés : vous trouvez donc 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 utilisez un ID de ressource complet, comme /subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/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.