CODE OU CONSOLE
Ce qui change quand votre tenant vit dans Git.
TerraProvider maintient Intune et Entra ID sous forme de code Terraform dans votre dépôt, de sorte que chaque modification devient un plan que votre équipe peut examiner avant qu'il n'atteigne le tenant. Voici comment cela se compare au clic dans les centres d'administration Microsoft Intune et Microsoft Entra, et dans quels cas une console de gestion convient mieux à votre équipe.
- terraprovider/microsoft365wp
- Terraform and OpenTofu
- Business Source License 1.1
# microsoft365wp_conditional_access_policy.require_mfa_admins will be updated in-place ~ resource "microsoft365wp_conditional_access_policy" "require_mfa_admins" { ~ conditions = { ~ users = { ~ exclude_users = [ - "7c1e4a90-3f2b-4d8e-9a61-0b5c2e8f1d47", ] # (8 unchanged attributes hidden) } # (6 unchanged attributes hidden) } id = "2b7f9c3e-8d41-4f6a-b0e2-5c9a1d7e3f80" # (3 unchanged attributes hidden) }Plan: 0 to add, 1 to change, 0 to destroy.
Données d'exemple.
CÔTE À CÔTE
La même modification dans les centres d'administration et en code
Une stratégie d'accès conditionnel, une règle de conformité, un second tenant : ce qui se passe dans chaque cas quand on clique, et ce qui se passe quand c'est un fichier dans votre dépôt.
| Situation | Dans les centres d'administration | Avec TerraProvider |
|---|---|---|
| Avant qu'une modification soit mise en production | Une modification d'accès conditionnel est active dès que quelqu'un clique sur Enregistrer. | La modification est une pull request. Le plan indique quel attribut passe de quelle valeur à quelle valeur avant que quoi que ce soit ne touche le tenant. |
| Qui a approuvé, et pourquoi | Le journal d'audit identifie le compte qui a enregistré la stratégie. Le ticket et la raison se trouvent ailleurs, s'ils existent. | Le message de commit, la pull request et l'approbation se trouvent à côté de la modification. Revenir en arrière, c'est un revert. |
| Test et production | Chaque tenant est configuré manuellement, et les deux divergent au fil des mois. | Un seul module, appliqué aux deux tenants. Là où ils diffèrent, une variable l'indique. |
| Une modification hors processus | La documentation continue de décrire le tenant tel qu'il était avant. | Le plan suivant la liste, y compris les paramètres que vos fichiers ne mentionnent jamais. Vous l'adoptez ou vous le remettez en place. |
| Un nouveau tenant | Chaque stratégie est reconfigurée manuellement, avec l'ancien tenant ouvert dans l'onglet suivant. | Importez le tenant existant (l'export du quickstart est un point de départ), puis appliquez le même code au nouveau. |
| Modifications depuis un pipeline | Quelqu'un se connecte à un navigateur et effectue la modification manuellement. | GitHub Actions et Azure DevOps se connectent via OpenID Connect, sans secret stocké. |
| Où réside la configuration | Dans le tenant lui-même. | Dans votre propre dépôt Git, sous forme de HCL que Terraform et OpenTofu exécutent tous les deux. Le code source du provider est public sous la Business Source License 1.1. |
CE QUI CONVIENT
Le code convient aux équipes qui examinent déjà les modifications dans des pull requests
Le choix dépend moins du tenant que de l'équipe : qui effectue une modification, et où elle est examinée.
TerraProvider convient quand
- Votre équipe écrit déjà du Terraform pour Azure et l'examine dans des pull requests.
- Une modification d'accès conditionnel doit être revue par une seconde personne avant d'être mise en production.
- Test et production doivent rester cohérents, et leurs différences doivent être lisibles.
- Les modifications doivent s'exécuter depuis GitHub Actions ou Azure DevOps, pas depuis le navigateur de quelqu'un.
Une console de gestion convient mieux quand
- Personne dans l'équipe n'écrit du HCL, et personne ne prévoit de le faire.
- Les modifications sont effectuées par des personnes dans un navigateur, et l'équipe souhaite conserver cette approche.
ÉQUIPES TENANT ET MSPS
Un seul provider pour votre propre tenant et pour les tenants de vos clients
Une équipe qui gère son propre tenant place test et production sous un seul module. Un fournisseur de services managés attribue à chaque tenant client son propre bloc provider et appelle le même module de base pour tous ; les exceptions sont des variables qu'un relecteur peut lire.
- Votre propre tenant : la Community Edition est gratuite pour les organisations comptant jusqu'à 99 utilisateurs, et Enterprise ajoute le support à partir de 100 utilisateurs.
- Tenants clients : la Community Edition ne les couvre pas, ils ont donc besoin de leur propre plan. Contacter l'équipe commerciale
provider "microsoft365wp" { alias = "contoso" tenant_id = "8a1f3c2e-5b7d-4e90-a6c4-2d9e7f1b0c35"}provider "microsoft365wp" { alias = "fabrikam" tenant_id = "e4c27b91-0d3a-4f86-b5e2-7a1c9d0f6b48"}module "baseline_contoso" { source = "./baseline" providers = { microsoft365wp = microsoft365wp.contoso }}module "baseline_fabrikam" { source = "./baseline" providers = { microsoft365wp = microsoft365wp.fabrikam } allow_byod = true}
Données d'exemple.
Visualisez votre propre tenant sous forme de plan.
Demandez un essai d'Enterprise, ou commencez avec la Community Edition, gratuite pour les organisations comptant jusqu'à 99 utilisateurs.