Test de l’approche pour les zones d’atterrissage Azure
Remarque
Cet article s’applique uniquement à Microsoft Azure et non à d’autres offres Microsoft Cloud telles que Microsoft 365 ou Microsoft Dynamics 365.
Certaines organisations veulent tester le déploiement de leur plateforme de zones d’atterrissage Azure relativement aux définitions et aux affectations Azure Policy, aux rôles personnalisés de contrôle d’accès en fonction du rôle (RBAC) et aux attributions, etc. Il est possible d’effectuer les tests via une automatisation en utilisant des modèles Azure Resource Manager (modèles ARM), AzOps, Terraform, Bicep ou manuellement via le portail Azure. Ce guide décrit une approche permettant de tester les modifications et leur impact dans un déploiement de plateforme de zones d’atterrissage d’atterrissage Azure à l’échelle de l’entreprise.
Vous pouvez également utiliser cet article conjointement avec les conseils de la zone de conception critique pour l’automation de plateforme et le DevOps qui traite des équipes et des tâches de fonctions PlatformOps et centrales.
Cette aide est particulièrement adaptée aux organisations qui ont mis en place des processus de gestion des modifications robustes régissant les modifications apportées à la hiérarchie du groupe d’administration de l’environnement de production. La hiérarchie du groupe d’administration canary peut être utilisée de manière indépendante pour créer et tester des déploiements avant de les effectuer dans l’environnement de production.
Remarque
Le terme canary est utilisé pour éviter toute confusion avec les environnements de développement ou de test. Il est utilisé à titre de simple illustration. Vous pouvez définir le nom de votre choix pour votre environnement de zones d’atterrissage d’atterrissage Azure Canary.
De même, le terme environnement de production est utilisé tout au long de cette aide pour faire référence à la hiérarchie du groupe d’administration que votre organisation peut avoir mise en place, qui contient les abonnements et les ressources Azure pour vos charges de travail.
Définition de la plateforme
Important
Cette aide n’a pas trait aux environnements de développement ou de test utilisés par des propriétaires d’application ou de service, appelés zones d’atterrissage, charges de travail, applications ou services. Ces environnements sont placés et gérés au sein de la hiérarchie du groupe d’administration de l’environnement de production et de la gouvernance associée (RBAC et Azure Policy).
Ce guide concerne seulement les tests au niveau de la plateforme et les modifications dans le contexte des zones d’atterrissage d’atterrissage Azure.
L’échelle de l’entreprise vous permet de concevoir et de déployer les composants de plateforme Azure requis pour pouvoir construire et opérationnaliser des zones d’atterrissage à grande échelle.
Les ressources de plateforme visées dans cet article et cette approche de test sont les suivantes :
| Produit ou service | Fournisseur et type de ressource |
|---|---|
| Groupes d’administration | Microsoft.Management/managementGroups |
| Association d’abonnement aux groupes d’administration | Microsoft.Management/managementGroups/subscriptions |
| Définitions de stratégies | Microsoft.Authorization/policyDefinitions |
| Définitions d’initiatives de stratégie ou de jeux de stratégies | Microsoft.Authorization/policySetDefinitions |
| Attributions de stratégies | Microsoft.Authorization/policyAssignments |
| Définitions de rôles RBAC | Microsoft.Authorization/roleDefinitions |
| Attributions de rôles RBAC | Microsoft.Authorization/roleAssignments |
| Abonnements | Microsoft.Subscription/aliases |
Exemples de scénarios et de résultats
Un exemple de ce scénario est celui d’une organisation désireuse de tester l’impact et le résultat d’une nouvelle stratégie Azure pour régir des ressources et des paramètres dans toutes les zones d’atterrissage, conformément au principe de conception de gouvernance pilotée par une stratégie. Elle ne souhaite pas apporter cette modification directement à l’environnement de production, car elle s’inquiète de son impact éventuel.
L’utilisation de l’environnement canary pour tester cette modification de plateforme permet à l’organisation d’implémenter et d’examiner l’impact et le résultat du changement de stratégie Azure. Ce processus permet à l’organisation de s’assurer que la stratégie Azure est conforme à ses exigences avant de l’implémenter dans son environnement de production.
Un scénario similaire pourrait être une modification des attributions de rôle RBAC Azure et des appartenances aux groupes Microsoft Entra. Il pourrait nécessiter une forme de test avant l’implémentation des modifications dans l’environnement de production.
Important
Pour la plupart des clients, il ne s’agit pas d’une approche ou d’un modèle de déploiement courants. Il n’est pas obligatoire pour les déploiements de zones d’atterrissage Azure.
Figure 1 : hiérarchie du groupe d’administration canary.
Comme le montre le diagramme, la totalité de la hiérarchie du groupe d’administration de l’environnement de production des zones d’atterrissage Azure est dupliquée sous Tenant Root Group. Le nom canary est ajouté aux noms d’affichage et ID du groupe d’administration. Les ID doivent être uniques au sein d’un seul locataire Microsoft Entra.
Remarque
Les noms d’affichage de groupe d’administration de l’environnement canary peuvent être identiques aux noms d’affichage de groupe d’administration de l’environnement de production. Cela peut entraîner une confusion pour les utilisateurs. C’est pourquoi nous recommandons d’ajouter le mot « canary » aux noms d’affichage, ainsi qu’à leur ID.
La hiérarchie du groupe d’administration de l’environnement canary est ensuite utilisée pour simplifier le test des types de ressources suivants :
- Groupes d’administration
- Placement de l’abonnement
- RBAC
- Rôles (intégrés et personnalisés)
- Attributions
- Azure Policy
- Définitions (intégrées et personnalisées)
- Initiatives, également appelées définitions
- Attributions
Que se passe-t-il si vous ne souhaitez pas déployer la totalité de la hiérarchie du groupe d’administration de l’environnement canary ?
Si vous ne souhaitez pas déployer la totalité de la hiérarchie du groupe d’administration de l’environnement canary, vous pouvez tester les ressources de la plateforme dans la hiérarchie de l’environnement de production en utilisant des abonnements de bac à sable, comme illustré dans le diagramme.
Figure 2 : hiérarchie du groupes d’administration à l’échelle de l’entreprise mettant en évidence les bacs à sable.
Pour tester la stratégie Azure et le contrôle d’accès en fonction du rôle (RBAC) dans ce scénario, vous avez besoin d’un seul abonnement Azure avec le rôle RBAC Propriétaire attribué à l’identité sous laquelle vous souhaitez conduire le test, par exemple, l’identité du compte d’utilisateur, du principal ou du service géré. Cette configuration vous permet de créer, d’attribuer et de corriger des définitions de stratégie Azure et des affectations au sein de l’étendue de l’abonnement de bac à sable uniquement.
Cette approche du bac à sable permet également de tester le RBAC au sein de l’abonnement, par exemple, si vous développez un nouveau rôle RBAC personnalisé afin d’accorder des autorisations pour un cas d’usage particulier. Vous pouvez effectuer ce test entièrement dans l’abonnement de bac à sable avant de créer et d’attribuer des rôles plus haut dans la hiérarchie.
L’avantage de cette approche est que vous pouvez utiliser les abonnements de bac à sable le temps nécessaire, puis les supprimer de l’environnement.
Toutefois, cette approche ne vous permet pas de tester avec l’héritage du RBAC et des stratégies Azure à partir de la hiérarchie du groupe d’administration.
Utilisation d’un seul locataire Microsoft Entra
Les considérations à prendre en compte lorsque vous utilisez un seul locataire Microsoft Entra sont les suivantes :
- Suit les recommandations de conception à l’échelle de l’entreprise pour les locataires Microsoft Entra.
- Conformément aux meilleures pratiques d’Azure décrites dans le Cloud Adoption Framework en lien avec la standardisation d’un annuaire et d’une identité uniques, dans la plupart des cas, la meilleure pratique consiste à choisir un locataire Microsoft Entra unique.
- Dans un locataire Microsoft Entra unique, vous pouvez utiliser les différents groupes Microsoft Entra tant pour les environnements de production que pour les environnements de zones d’atterrissage Azure de contrôle de validité, avec les mêmes utilisateurs attribués à leur hiérarchie de groupe d’administration pertinente au sein du même locataire Microsoft Entra.
- Augmentation ou duplication des coûts de licence Microsoft Entra ID en raison d’identités multiples dans différents locataires Microsoft Entra.
- Ce point est particulièrement pertinent pour les clients qui utilisent des fonctionnalités Microsoft Entra ID P1 ou P2.
- Les modifications de RBAC seront plus complexes dans des environnements de contrôle de validité et de production, car il est improbable que les utilisateurs et les groupes soient identiques dans les deux locataires Microsoft Entra.
- En outre, les ID d’utilisateurs et de groupes ne seront pas les mêmes dans les locataires Microsoft Entra, car ils sont globalement uniques.
- Réduit la complexité et la surcharge qu’entraîne la gestion de plusieurs locataires Microsoft Entra.
- Les utilisateurs privilégiés qui doivent conserver l’accès et se connecter à des locataires distincts pour effectuer des tests risquent d’apporter accidentellement des modifications à l’environnement de production plutôt qu’à l’environnement canary, et inversement.
- Un locataire Azure AD unique réduit la probabilité d’une dérive de configuration et d’échecs de déploiement.
- Un locataire Azure AD unique ne nécessite pas de créer des processus supplémentaires de sécurité et d’accès d’urgence ou de secours.
- Réduit la friction et le temps nécessaires pour implémenter des modifications du déploiement de zones d’atterrissage Azure.
Conseils d’implémentation
Vous trouverez ci-dessous des conseils sur la façon d’implémenter et d’utiliser la hiérarchie du groupe d’administration Canary pour les zones d’atterrissage Azure, en même temps qu’une hiérarchie de groupe d’administration d’environnement de production.
Avertissement
Si vous utilisez le portail pour déployer et gérer votre environnement de zones d’atterrissage Azure aujourd’hui, il peut être difficile d’adopter et d’utiliser efficacement l’approche Canary en raison d’un risque élevé de désynchronisation fréquente des environnements de production et des environnements Canary, qui ne fournissent donc pas de hiérarchie et d’environnement de production de type réplica.
Envisagez de passer à une approche de déploiement d’infrastructure en tant que code pour les zones d’atterrissage Azure comme indiqué ci-dessus si vous êtes dans ce scénario. Découvrez aussi les risques potentiels de dérive des configurations entre Canary et la production, et procédez donc avec précaution.
- Utilisez des noms de principal du service (SPN) ou des identités de service managées Microsoft Entra distincts, qui sont des autorisations accordées sur la hiérarchie du groupe d’administration de l’environnement de production ou de l’environnement de contrôle de validité.
- Cette aide suit le principe du privilège minimum
- Utilisez des dossiers distincts au sein d’un dépôt Git, des branches ou des dépôts pour contenir l’infrastructure en tant que code pour les déploiements de zones d’atterrissage Azure de l’environnement de production et de l’environnement Canary.
- Utilisation de principaux de service (SPN) ou d’identités de service managées Microsoft Entra appropriés dans le cadre des pipelines de CI/CD, en fonction de la hiérarchie en cours de déploiement.
- Implémentez des stratégies ou une sécurité de branche Git pour l’environnement canary comme celles que vous avez mises en place pour l’environnement de production.
- Envisagez de réduire le nombre d’approbateurs et de vérifications pour l’environnement canary afin de provoquer une interruption immédiate (fail-fast).
- Utilisez les mêmes Azure Pipelines ou GitHub Actions que ceux qu’utilisent les variables d’environnement pour modifier la hiérarchie déployée. Une autre option consiste à cloner les pipelines et à modifier les paramètres codés en dur afin de définir la hiérarchie déployée.
- L’utilisation de modèles DevOps Azure Pipelines ou de modèles de workflow GitHub Actions vous permet d’adhérer au principe Ne vous répétez pas (DRY) .
- Dotez-vous d’un ensemble d’abonnements canary sous un service et un compte EA distincts qui peuvent être déplacés dans la hiérarchie du groupe de gestion canary en fonction des besoins.
- Il peut être utile de disposer d’un ensemble de ressources toujours déployées dans les abonnements de l’environnement canary.
- Il peut être utile d’avoir des modèles d’infrastructure en tant que code, tels que des modèles ARM, Bicep ou Terraform, qui créent un ensemble de ressources permettant la validation des modifications dans l’environnement canary.
- Envoyez tous les journaux d’activité Azure pour tous les abonnements Azure, y compris les abonnements de l’environnement Canary, à l’espace de travail Azure Log Analytics conformément aux recommandations de conception des zones d’atterrissage Azure.
Conseil
Si vous avez déjà des zones d’atterrissage Azure déployées en production et que vous cherchez maintenant à ajouter un environnement Canary. Envisagez de cloner votre déploiement actuel de la hiérarchie de l’environnement de production et de modifier les noms des ressources en les préfixant avec votre schéma de nommage Canary.
Ceci est destiné à garantir que ce que vous déployez pour activer l’environnement Canary est synchronisé avec la production depuis le début. Vous réalisez cela facilement si vous utilisez un outil IaaS (Infrastructure en tant que code) en même temps qu’un dépôt Git.
Étapes suivantes
Découvrez comment implémenter des environnements de bac à sable de la zone d’atterrissage.