Présentation des étendues de déploiement

  • 6 minutes

Les machines virtuelles, les serveurs logiques et les bases de données Azure SQL, les comptes de stockage, les réseaux virtuels et la plupart des autres ressources Azure doivent être placés dans un groupe de ressources. Cependant, certaines ressources peuvent, voire doivent, être déployées d’une autre manière. Elles sont généralement utilisées pour contrôler le comportement de votre environnement Azure.

Dans cette unité, vous passerez en revue la hiérarchie de l’organisation des ressources Azure, et vous verrez comment certaines ressources peuvent être déployées dans différents étendues.

La hiérarchie des ressources Azure

Azure possède une structure de ressources hiérarchique comportant plusieurs niveaux de gestion. Voici un diagramme montrant comment votre entreprise pourrait organiser son environnement Azure :

Diagram showing an Azure tenant, three management groups, three subscriptions, and four resource groups.

Votre locataire correspond à votre instance Microsoft Entra. Une organisation ne possède généralement qu’une seule instance Microsoft Entra. Cette instance fait office de racine de la hiérarchie des ressources.

Les groupes d’administration permettent d’organiser les abonnements Azure. Chaque locataire dispose d’un seul groupe d’administration racine. Vous pouvez établir votre propre hiérarchie de groupes d’administration sous celui-ci. Il est possible de créer des groupes d’administration distincts pour les différentes parties de l’organisation, ou pour les abonnements qui ont leurs propres exigences en matière de sécurité ou de gouvernance. Vous pouvez appliquer des restrictions de stratégie et de contrôle d’accès à un groupe d’administration, et tous les abonnements situés sous ce groupe dans la hiérarchie héritent de ces restrictions. Les groupes d’administration ne sont pas déployés dans les régions. Ils n’ont aucun impact sur l’emplacement de vos ressources.

Les abonnements jouent le rôle de comptes de facturation, et contiennent les groupes de ressources et les ressources. Comme les groupes d’administration, les abonnements ne possèdent pas d’emplacement. Ils n’imposent aucune restriction quant à l’endroit où les ressources sont déployées.

Les groupes de ressources sont des conteneurs logiques pour vos ressources. Avec les groupes de ressources, vous pouvez gérer et contrôler les ressources liées comme une seule unité. Les ressources de type machines virtuelles, plans Azure App Service, comptes de stockage et réseaux virtuels doivent être placées dans un groupe de ressources. Les groupes de ressources sont créés dans un emplacement permettant à Azure de suivre les métadonnées des ressources qu’ils contiennent. Cependant, les ressources en question peuvent être déployées à d’autres endroits.

L’exemple illustré précédemment constitue un scénario assez basique qui montre comment les groupes d’administration peuvent être utilisés. Votre organisation peut également envisager d’implémenter une zone d’atterrissage : il s’agit de l’ensemble de ressources et de configurations Azure nécessaire pour commencer un environnement Azure de production. La zone d’atterrissage à l’échelle de l’entreprise représente une approche éprouvée de gestion efficace des ressources Azure avec des groupes d’administration et des abonnements :

Diagram of an enterprise-scale landing-zone architecture, with four management groups and four subscriptions.

Quel que soit le modèle que vous suivez vous pouvez, en identifiant les différents niveaux de la hiérarchie, commencer à appliquer des contrôles flexibles sur la façon dont votre environnement Azure est utilisé et géré. Bicep vous permet de gérer ces contrôles avec tous les avantages de l’infrastructure-code.

Notes

Il existe également d’autres ressources qui sont déployées dans des étendues spécifiques. Les ressources d’extension sont déployées dans l’étendue d’une autre ressource Azure. Par exemple, un verrou de ressource constitue une ressource d’extension, qui est déployée dans une autre ressource, telle qu’un compte de stockage.

Vous savez déjà déployer des ressources dans des groupes de ressources. Examinons donc les autres étendues de déploiement.

Ressources étendues à l’abonnement

Vous pouvez déployer des ressources dans un abonnement dans les situations suivantes :

  • Vous devez créer un groupe de ressources. Un groupe de ressources ne constitue en fait qu’une ressource étendue à l’abonnement.
  • Vous devez accorder l’accès à toutes les ressources d’un abonnement. Par exemple, si votre service des ressources humaines dispose d’un abonnement Azure contenant toutes ses ressources Azure, vous pouvez créer des attributions de rôles pour permettre à tous les membres du service de lire le contenu de l’abonnement.
  • Vous utilisez Azure Policy et souhaitez définir ou appliquer une stratégie à toutes les ressources de l’abonnement. Par exemple, le département R&D de votre société jouet vous demande de déployer une stratégie qui restreint la liste des références SKU de machines virtuelles pouvant être créées dans l’abonnement de l’équipe.

Ressources étendues au groupe d’administration

Vous pouvez déployer des ressources dans un groupe d’administration dans les situations suivantes :

  • Vous devez accorder l’accès à toutes les ressources de tous les abonnements qui se trouvent sous le groupe d’administration dans la hiérarchie. Supposons par exemple que votre équipe d’exploitation du cloud ait besoin d’accéder à tous les abonnements de votre entreprise. Vous pouvez créer une attribution de rôle au niveau de votre groupe d’administration racine, qui accorde à l’équipe un accès à toutes les ressources dans Azure.

    Attention

    Faites très attention lorsque vous donnez accès à des ressources avec des groupes d’administration, et en particulier le groupe d’administration racine. N’oubliez pas que toutes les ressources situées sous le groupe d’administration dans la hiérarchie héritent de l’attribution de rôle. Veillez à ce que votre organisation suive les meilleures pratiques en matière de gestion des identités et d’authentification, et qu’elle respecte le principe des privilèges minimum. Autrement dit, n’octroyez aucun droit qui n’est pas nécessaire.

  • Vous devez appliquer des stratégies à l’ensemble de votre organisation. Supposons par exemple que votre organisation possède une stratégie interdisant en toutes circonstances de créer des ressources dans certaines régions géographiques. Vous pouvez appliquer à votre groupe d’administration racine une stratégie qui bloque la création de ressources dans cette région.

Notes

Avant d’utiliser les groupes d’administration pour la première fois, configurez-les pour votre environnement Azure.

Ressources étendues aux locataires

Vous pouvez déployer des ressources dans votre locataire dans les situations suivantes :

  • Vous devez créer des abonnements Azure. Lorsque vous utilisez des groupes d’administration, les abonnements se trouvent sous les groupes d’administration dans la hiérarchie des ressources, mais sont déployés comme des ressources étendues au locataire.

    Notes

    Tous les clients Azure ne peuvent pas créer des abonnements avec l’infrastructure-code. Cela dépend de leur relation de facturation avec Microsoft. Pour plus d’informations, consultez Création programmatique d’abonnements Azure.

  • Vous êtes en train de créer ou de configurer des groupes d’administration. Azure crée un groupe d’administration racine unique lorsque vous activez les groupes d’administration pour votre locataire. Vous pouvez créer plusieurs niveaux de groupes d’administration sous ce groupe. Vous avez la possibilité d’utiliser Bicep pour définir toute la hiérarchie de vos groupes d’administration. Vous pouvez également attribuer des abonnements à des groupes d’administration.

    Avec Bicep, vous pouvez soumettre des déploiements dans l’étendue du locataire. Les déploiements étendus au locataire nécessitent une autorisation spéciale. Dans la pratique cependant, vous n’avez pas besoin de les soumettre. Il est plus simple de déployer des ressources étendues au locataire avec un modèle d’une autre étendue. Nous verrons comment faire plus loin dans ce module.

    Conseil

    Il n’est pas possible de créer des stratégies ni des attributions de rôles dans l’étendue du locataire. Toutefois, si vous devez accorder des accès ou appliquer des stratégies à l’ensemble de votre organisation, vous pouvez déployer ces ressources dans le groupe d’administration racine.

ID de ressource

Vous connaissez maintenant l’ID des ressources qui se trouvent dans les abonnements. Par exemple, voici un ID de ressource représentant un groupe de ressources, c’est-à-dire une ressource étendue à l’abonnement :

/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyDevelopment

Voici une représentation visuelle des mêmes informations :

Screenshot of a Resource ID for a resource group.

Les abonnements ont leur propre ID :

/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c

Notes

Bien que les abonnements soient considérés comme des enfants de groupes d’administration, leur ID de ressource n’inclut pas d’ID de groupe d’administration. Azure assure le suivi de la relation entre les abonnements et les groupes d’administration d’une manière différente des autres relations de ressources. Vous pouvez ainsi déplacer les abonnements entre les groupes d’administration sans avoir à changer tous les ID de ressources.

Lorsque vous travaillez avec des ressources étendues à un groupe d’administration ou à un locataire, leur ID peut s’écarter légèrement de la norme. Ils suivent pour la plupart le modèle standard qui mêle le type de ressource avec les informations relatives à vos ressources. Toutefois, le format spécifique dépend de la ressource en question.

Voici un exemple d’ID de ressource pour un groupe d’administration :

/providers/Microsoft.Management/managementGroups/ProductionMG

Voici une représentation visuelle du même ID :

Screenshot of a Resource ID for a management group.

Remarque

Les groupes d’administration possèdent à la fois un identificateur et un nom d’affichage. Le nom d’affichage consiste en une description lisible par l’utilisateur du groupe d’administration. Vous pouvez le modifier sans affecter l’ID du groupe d’administration.

Lorsqu’une ressource est déployée dans l’étendue d’un groupe d’administration, son ID inclut celui du groupe d’administration. Voici un exemple d’ID de ressource pour une définition de rôle créée dans l’étendue d’un groupe d’administration :

/providers/Microsoft.Management/managementGroups/ProductionMG/providers/Microsoft.Authorization/roleDefinitions/d79b8492-6f38-49f9-99e6-b2e667d4f3ca

Voici une représentation visuelle du même ID :

Screenshot of a Resource ID for a role definition that's deployed at a management group scope.

Une autre définition de rôle peut être définie dans l’étendue d’un abonnement. Son ID de ressource est ainsi légèrement différent :

/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/providers/Microsoft.Authorization/roleDefinitions/d79b8492-6f38-49f9-99e6-b2e667d4f3ca

Voici une représentation visuelle du même ID :

Screenshot of a Resource ID for a role definition that's deployed at a subscription scope.

Maintenant que vous connaissez la hiérarchie des ressources Azure et les types de ressources que vous pouvez déployer dans chaque étendue, vous pouvez prendre des décisions sur les étendues de déploiement de vos ressources. Par exemple, vous pouvez choisir en connaissance de cause entre créer une définition de stratégie dans l’étendue d’un groupe de ressources, d’un abonnement ou d’un groupe d’administration. Dans l’unité suivante, vous apprendrez à créer des fichiers Bicep qui ciblent chacune de ces étendues.