Se connecter à Azure DocumentDB à l’aide du contrôle d’accès en fonction du rôle et de l’ID Microsoft Entra

Ouvrez un nouveau terminal.

Connectez-vous à Azure CLI.

Permet az group show d’obtenir les métadonnées de votre groupe de ressources actuel.

az group show \
    --name "<name-of-existing-resource-group>"

Observez la sortie de la commande précédente. Enregistrez la valeur de la propriété id pour ce groupe de ressources, car elle est nécessaire pour l'utiliser à l'étape suivante.

{
  "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/msdocs-identity-example",
  "location": "westus",
  "name": "msdocs-identity-example",
  "type": "Microsoft.Resources/resourceGroups"
}

Créez un fichier JSON nommé role-definition.json. Dans le fichier, créez cette définition de ressource en spécifiant les valeurs répertoriées ici. Dans la liste AssignableScopes, ajoutez la propriété id du groupe de ressources notée à l’étape précédente.

{
  "Name": "Azure DocumentDB RBAC Owner",
  "IsCustom": true,
  "Description": "Can perform all Azure role-based access control actions for Azure DocumentDB clusters.",
  "Actions": [
    "Microsoft.DocumentDb/mongoClusters/*"
  ],
  "AssignableScopes": [
    "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/msdocs-identity-example"
  ]
}

Créez une nouvelle définition de rôle à l’aide de az role definition create. Utilisez le fichier role-definition.json comme entrée pour l’argument --role-definition .

az role definition create \
    --role-definition role-definition.json

Passez en revue la sortie de la commande de création de définition. La sortie contient l’identificateur unique de la définition de rôle dans la id propriété. Enregistrez cette valeur, car il est nécessaire d’utiliser dans l’étape d’affectation plus loin dans ce guide.

{
  "assignableScopes": [
    "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/msdocs-identity-example"
  ],
  "description": "Can perform all Azure role-based access control actions for Azure DocumentDB clusters.",
  "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/msdocs-identity-example/providers/Microsoft.Authorization/roleDefinitions/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1",
  "name": "e4e4e4e4-ffff-aaaa-bbbb-c5c5c5c5c5c5",
  "permissions": [
    {
      "actions": [
        "Microsoft.DocumentDb/*"
      ]
    }
  ],
  "roleName": "Azure DocumentDB RBAC Owner",
  "roleType": "CustomRole"
}

Ouvrez un nouveau terminal.

Connectez-vous à Azure CLI.

Créez un fichier Bicep pour définir votre définition de rôle. Nommez le fichier control-plane-role-definition.bicep. Ajoutez-les actions à la définition :

metadata description = 'Create RBAC definition for Azure role-based access control access to Azure DocumentDB.'

@description('Name of the role definition.')
param roleDefinitionName string = 'Azure DocumentDB RBAC Owner'

@description('Description of the role definition.')
param roleDefinitionDescription string = 'Can perform all Azure role-based access control actions for Azure DocumentDB clusters.'

resource definition 'Microsoft.Authorization/roleDefinitions@2022-04-01' = {
  name: guid(subscription().id, resourceGroup().id, roleDefinitionName)
  scope: resourceGroup()
  properties: {
    roleName: roleDefinitionName
    description: roleDefinitionDescription
    type: 'CustomRole'
    permissions: [
      {
        actions: [
          'Microsoft.DocumentDb/mongoClusters/*'
        ]
      }
    ]
    assignableScopes: [
      resourceGroup().id
    ]
  }
}

output definitionId string = definition.id

Déployez le modèle Bicep à l’aide de az deployment group create. Spécifiez le nom du modèle Bicep et du groupe de ressources Azure.

az deployment group create \
    --resource-group "<name-of-existing-resource-group>" \
    --template-file control-plane-role-definition.bicep

Passez en revue la sortie du déploiement. La sortie contient l’identificateur unique de la définition de rôle dans la properties.outputs.definitionId.value propriété. Enregistrez cette valeur, car il est nécessaire d’utiliser dans l’étape d’affectation plus loin dans ce guide.

{
  "properties": {
    "outputs": {
      "definitionId": {
        "type": "String",
        "value": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/msdocs-identity-example/providers/Microsoft.Authorization/roleDefinitions/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1"
      }
    }
  }
}

Créez un fichier Bicep pour définir votre attribution de rôle. Nommez le fichier control-plane-role-assignment.bicep.

metadata description = 'Assign RBAC role for Azure role-based access control access to Azure DocumentDB.'

@description('Id of the role definition to assign to the targeted principal in the context of the cluster.')
param roleDefinitionId string

@description('Id of the identity/principal to assign this role in the context of the cluster.')
param identityId string

resource assignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(subscription().id, resourceGroup().id, roleDefinitionId, identityId)
  scope: resourceGroup()
  properties: {
    roleDefinitionId: roleDefinitionId
    principalId: identityId
  }
}

Créez un nouveau fichier de paramètres Bicep nommé control-plane-role-assignment.bicepparam. Dans ce fichier de paramètres ; affectez les identificateurs de définition de rôle précédemment enregistrés au roleDefinitionId paramètre et l’identificateur unique de votre identité au identityId paramètre.

using './control-plane-role-assignment.bicep'

param roleDefinitionId = '<id-of-new-role-definition>'
param identityId = '<id-of-existing-identity>'

Déployez ce modèle Bicep à l’aide de az deployment group create.

az deployment group create \
    --resource-group "<name-of-existing-resource-group>" \
    --parameters control-plane-role-assignment.bicepparam \
    --template-file control-plane-role-assignment.bicep

Connectez-vous au portail Azure (https://portal.azure.com).

Entrez le groupe de ressources dans la barre de recherche globale.

Dans Services, sélectionnez Groupes de ressources.

Dans le volet Groupes de ressources, sélectionnez votre groupe de ressources existant.

Dans le volet du groupe de ressources, sélectionnez Contrôle d’accès (IAM) dans le menu du service.

Dans le volet Contrôle d’accès (IAM), sélectionnez Ajouter. Sélectionnez Ensuite Ajouter un rôle personnalisé.

Dans le volet Informations de base , configurez les options suivantes, puis sélectionnez Suivant :

Dans le volet Autorisations , sélectionnez Ajouter des autorisations. Ensuite, recherchez DocumentDB dans la boîte de dialogue autorisations. Enfin, sélectionnez l’option Microsoft.DocumentDB/mongoClusters .

Dans la boîte de dialogue Autorisations, sélectionnez toutes les actions pour Microsoft.DocumentDB/mongoClusters. Ensuite, sélectionnez Ajouter pour revenir au volet *Autorisations .

De retour dans le volet Autorisations , observez la liste des autorisations. Ensuite, sélectionnez Vérifier + créer.

Dans le volet Vérifier + créer , passez en revue les options spécifiées pour la nouvelle définition de rôle. Enfin, sélectionnez Créer.

Attendez que le portail termine la création de la définition de rôle.

Dans le volet Contrôle d’accès (IAM), sélectionnez Ajouter , puis Ajouter une attribution de rôle.

Dans le volet Rôle , recherchez Azure DocumentDB et sélectionnez le rôle Propriétaire RBAC Azure DocumentDB créé précédemment dans ce guide. Ensuite, sélectionnez Suivant.

Dans le volet Membres , sélectionnez l’option Sélectionner des membres . Dans la boîte de dialogue membres, sélectionnez l’identité que vous souhaitez accorder à ce niveau d’accès pour vos clusters Azure DocumentDB, puis utilisez l’option Sélectionner pour confirmer votre choix.

De retour dans le volet Membres , passez en revue le membre sélectionné[s], puis sélectionnez Vérifier + affecter.

Dans le volet Révision + affectation , passez en revue les options spécifiées pour la nouvelle attribution de rôle. Enfin, sélectionnez Vérifier + affecter.

Attendez que le portail termine la création de l’attribution de rôle.

Ouvrez un nouveau terminal.

Connectez-vous à Azure CLI.

Vérifiez votre abonnement Azure cible.

az account show

Créez un fichier Terraform pour définir votre définition de rôle. Nommez le fichier control-plane-role-definition.tf. Ajoutez-les actions à la définition :

variable "role_definition_name" {
  type        = string
  description = "Name of the role definition."
  default     = "Azure DocumentDB RBAC Owner"
}

variable "role_definition_description" {
  type        = string
  description = "Description of the role definition."
  default     = "Can perform all Azure role-based access control actions for Azure DocumentDB clusters."
}

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}

provider "azurerm" {
  features {}
}

data "azurerm_client_config" "current" {}

data "azurerm_resource_group" "existing" {
  name = "<name-of-existing-resource-group>"
}

resource "azurerm_role_definition" "control_plane" {
  name               = var.role_definition_name
  scope              = data.azurerm_resource_group.existing.id
  description        = var.role_definition_description

  permissions {
    actions = [
      "Microsoft.DocumentDb/mongoClusters/*"
    ]
  }

  assignable_scopes = [
    data.azurerm_resource_group.existing.id
  ]
}

output "definition_id" {
  value = azurerm_role_definition.control_plane.id
}

Initialisez le déploiement Terraform.

terraform init --upgrade

Créez un plan d’exécution pour la définition de rôle et enregistrez-le dans un fichier nommé role-definition.tfplan.

ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform plan --out "role-definition.tfplan"

Appliquez le plan d’exécution pour déployer la définition de rôle sur Azure.

ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform apply "role-definition.tfplan"

Passez en revue la sortie du déploiement. La sortie contient l’identificateur unique de la définition de rôle dans la definition_id propriété. Enregistrez cette valeur, car il est nécessaire d’utiliser dans l’étape d’affectation plus loin dans ce guide.

Créez un fichier Terraform pour définir votre attribution de rôle. Nommez le fichier control-plane-role-assignment.tf.

variable "role_definition_id" {
  type        = string
  description = "Id of the role definition to assign to the targeted principal in the context of the cluster."
}

variable "identity_id" {
  type        = string
  description = "Id of the identity/principal to assign this role in the context of the cluster."
}

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}

provider "azurerm" {
  features {}
}

data "azurerm_resource_group" "existing" {
  name = "<name-of-existing-resource-group>"
}

resource "azurerm_role_assignment" "control_plane" {
  scope              = data.azurerm_resource_group.existing.id
  role_definition_id = var.role_definition_id
  principal_id       = var.identity_id
}

Créez un fichier de variables Terraform nommé control-plane-role-assignment.tfvars. Dans ce fichier de variables ; affectez les identificateurs de définition de rôle précédemment enregistrés à la role_definition_id variable et l’identificateur unique de votre identité à la identity_id variable.

role_definition_id = "<id-of-new-role-definition>"
identity_id        = "<id-of-existing-identity>"

Initialisez et appliquez cette configuration Terraform.

terraform init --upgrade

ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform plan --var-file="control-plane-role-assignment.tfvars" --out "role-assignment.tfplan"

ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform apply "role-assignment.tfplan"

Obtenez les détails du compte actuellement connecté à l’aide de az ad signed-in-user.

az ad signed-in-user show

La commande génère une réponse JSON contenant différents champs.

{
  "@odata.context": "<https://graph.microsoft.com/v1.0/$metadata#users/$entity>",
  "businessPhones": [],
  "displayName": "Kai Carter",
  "givenName": "Kai",
  "id": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "jobTitle": "Senior Sales Representative",
  "mail": "<kai@adventure-works.com>",
  "mobilePhone": null,
  "officeLocation": "Redmond",
  "preferredLanguage": null,
  "surname": "Carter",
  "userPrincipalName": "<kai@adventure-works.com>"
}

Activez l’authentification ID Microsoft Entra sur le cluster en mettant à jour la ressource du cluster pour inclure MicrosoftEntraID dans le tableau authConfig.allowedModes :

az resource patch \
    --resource-group "<resource-group>" \
    --name "<cluster-name>" \
    --resource-type "Microsoft.DocumentDB/mongoClusters" \
    --properties '{"authConfig":{"allowedModes":["MicrosoftEntraID","NativeAuth"]}}' \
    --latest-include-preview

Vérifiez que la modification a bien été appliquée en lisant la propriété authConfig sur le cluster à l’aide de az resource show.

az resource show \
    --resource-group "<resource-group>" \
    --name "<cluster-name>" \
    --resource-type "Microsoft.DocumentDB/mongoClusters" \
    --query "properties.authConfig" \
    --latest-include-preview

(Facultatif) Obtenez l’identificateur unique du principal Microsoft Entra que vous envisagez d’inscrire sur le cluster. Vous pouvez l’obtenir avec Azure CLI à l’aide de l’une des commandes suivantes :

• Identité de connexion actuelle

  az ad signed-in-user show      
  

• Une autre identité humaine à l’aide d’un nom convivial

  az ad user show \
    --id "<user-alias-and-domain>"
  

• Principal de service à l’aide de l’identificateur d’application

  az ad sp show \
    --id "<application-id>"
  

• Identité managée à l’aide du groupe de ressources et du nom

  az identity show \
    --resource-group "<resource-group>" \
    --name "<managed-identity-name>"      
  

Créez un petit modèle Bicep qui met à jour le cluster authConfig pour inclure l’ID Microsoft Entra (enregistrer sous enable-entra-id.bicep) :

param clusterName string
param location string = resourceGroup().location

resource cluster 'Microsoft.DocumentDB/mongoClusters@2025-09-01' = {
  name: clusterName
  location: location
  properties: {
    authConfig: {
      allowedModes: [
        'MicrosoftEntraID'
        'NativeAuth'
      ]
    }
  }
}

Déployez le modèle pour mettre à jour le cluster :

az deployment group create \
    --resource-group "<resource-group>" \
    --template-file enable-entra-id.bicep \
    --parameters clusterName="<cluster-name>"

Vérifiez la propriété authConfig sur le cluster à l’aide de az resource show.

az resource show \
    --resource-group "<resource-group>" \
    --name "<cluster-name>" \
    --resource-type "Microsoft.DocumentDB/mongoClusters" \
    --query "properties.authConfig" \
    --latest-include-preview

Dans le volet Accueil du portail Azure, recherchez et sélectionnez l’option Microsoft Entra ID .

Dans le volet Vue d’ensemble du locataire Microsoft Entra ID, sélectionnez Utilisateurs dans la section Gérer du menu de service.

Dans la liste des utilisateurs, sélectionnez l’identité (utilisateur) à laquelle vous souhaitez obtenir plus de détails.

Dans le volet d’informations de l’utilisateur spécifique, observez la valeur de la propriété ID d’objet .

Accédez à la ressource de cluster Azure DocumentDB existante.

Dans le menu du cluster, sous Paramètres, sélectionnez Authentification.

Dans la section Méthodes d’authentification , sélectionnez Native DocumentDB et Microsoft Entra ID pour activer l’authentification Microsoft Entra ID avec l’authentification native.

Sélectionnez Enregistrer pour conserver la modification.

La section Méthodes d’authentification doit maintenant répertorier nativeAuth et MicrosoftEntraID comme méthodes activées.

(Facultatif) Obtenez l’identificateur unique du principal Microsoft Entra que vous envisagez d’inscrire sur le cluster. Vous pouvez l’obtenir avec Azure CLI à l’aide de l’une des commandes suivantes :

• Identité de connexion actuelle

  az ad signed-in-user show      
  

• Une autre identité humaine à l’aide d’un nom convivial

  az ad user show \
    --id "<user-alias-and-domain>"
  

• Principal de service à l’aide de l’identificateur d’application

  az ad sp show \
    --id "<application-id>"
  

• Identité managée à l’aide du groupe de ressources et du nom

  az identity show \
    --resource-group "<resource-group>" \
    --name "<managed-identity-name>"      
  

Créez un fichier de configuration Terraform pour activer l’authentification Microsoft Entra ID sur votre cluster existant. Enregistrez le fichier sous le nom enable-entra-id.tf :

variable "cluster_name" {
  type        = string
  description = "Name of the existing cluster"
}

variable "resource_group_name" {
  type        = string
  description = "Name of the existing resource group"
}

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}

provider "azurerm" {
  features {}
}

data "azurerm_resource_group" "existing" {
  name = var.resource_group_name
}

data "azurerm_mongo_cluster" "existing" {
  name                = var.cluster_name
  resource_group_name = data.azurerm_resource_group.existing.name
}

resource "azurerm_mongo_cluster" "enable_entra" {
  name                   = data.azurerm_mongo_cluster.existing.name
  resource_group_name    = data.azurerm_resource_group.existing.name
  location               = data.azurerm_mongo_cluster.existing.location
  administrator_username = data.azurerm_mongo_cluster.existing.administrator_username
  administrator_password = data.azurerm_mongo_cluster.existing.administrator_password
  shard_count            = data.azurerm_mongo_cluster.existing.shard_count
  compute_tier           = data.azurerm_mongo_cluster.existing.compute_tier
  high_availability_mode = data.azurerm_mongo_cluster.existing.high_availability_mode
  storage_size_in_gb     = data.azurerm_mongo_cluster.existing.storage_size_in_gb
  version                = data.azurerm_mongo_cluster.existing.version

  # Enable both Microsoft Entra ID and Native authentication
  authentication_enabled = true
}

Créez un fichier de variables nommé enable-entra-id.tfvars avec les détails de votre cluster :

cluster_name        = "<cluster-name>"
resource_group_name = "<resource-group>"

Initialisez et appliquez la configuration Terraform pour activer l’authentification Microsoft Entra ID :

terraform init --upgrade

ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform plan --var-file="enable-entra-id.tfvars" --out "enable-entra.tfplan"

ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform apply "enable-entra.tfplan"

Vérifiez la propriété authConfig sur le cluster à l’aide de az resource show.

az resource show \
    --resource-group "<resource-group>" \
    --name "<cluster-name>" \
    --resource-type "Microsoft.DocumentDB/mongoClusters" \
    --query "properties.authConfig" \
    --latest-include-preview

Obtenez l’identificateur unique (ID d’objet) du principal Microsoft Entra auquel vous souhaitez accorder l’accès à l’aide de l’une des commandes suivantes :

• Identité de connexion actuelle

  az ad signed-in-user show      
  

• Une autre identité humaine à l’aide d’un nom convivial

  az ad user show \
    --id "<user-alias-and-domain>"
  

• Principal de service à l’aide de l’identificateur d’application

  az ad sp show \
    --id "<application-id>"
  

• Identité managée à l’aide du groupe de ressources et du nom

  az identity show \
    --resource-group "<resource-group>" \
    --name "<managed-identity-name>"      
  

Inscrivez le principal sur le cluster et mappez-le aux rôles de base de données MongoDB. L’exemple suivant inscrit un principal en tant qu’utilisateur readWrite sur la sales base de données :

az resource create \
    --resource-group "<resource-group>" \
    --name "<cluster-name>/users/<principal-id>" \
    --resource-type "Microsoft.DocumentDB/mongoClusters/users" \
    --location "<cluster-region>" \
    --properties '{"identityProvider":{"type":"MicrosoftEntraID","properties":{"principalType":"User"}},"roles":[{"db":"sales","role":"readWrite"}]}' \
    --latest-include-preview

• Remplacez principalType par servicePrincipal pour les objets principaux d'application/service ou ManagedIdentity pour les identités gérées.
• Pour accorder des privilèges d’administration, utilisez-le {"db":"admin","role":"root"} dans le roles tableau.

Répertorier tous les principaux enregistrés et leurs rôles associés (niveau cluster) :

az rest \
    --method "GET" \
    --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.DocumentDB/mongoClusters/<cluster-name>/users?api-version=2025-09-01"

• La réponse contient un tableau des ressources utilisateur, chacune avec des métadonnées identityProvider et un tableau roles montrant les rôles de base de données mappés.

Obtenir les détails d’un principal inscrit spécifique (remplacement <principal-id>) :

az resource show \
    --resource-group "<resource-group>" \
    --name "<cluster-name>/users/<principal-id>" \
    --resource-type "Microsoft.DocumentDB/mongoClusters/users" \
    --latest-include-preview

Supprimer un principal inscrit (révoquer l’accès au plan de données) :

az resource delete \
    --resource-group "<resource-group>" \
    --name "<cluster-name>/users/<principal-id>" \
    --resource-type "Microsoft.DocumentDB/mongoClusters/users" \
    --latest-include-preview

Créez un fichier Bicep (par exemple register-principal.bicep) pour inscrire le principal et mapper les rôles de la base de données :

param clusterName string
param principalId string
param location string = resourceGroup().location
param principalType string = 'User'
param roles array = [
  {
    db: 'sales'
    role: 'readWrite'
  }
]

resource user 'Microsoft.DocumentDB/mongoClusters/users@2025-09-01' = {
  name: '${clusterName}/users/${principalId}'
  location: location
  properties: {
    identityProvider: {
      type: 'Microsoft.EntraID'
      properties: {
        principalType: principalType
      }
    }
    roles: roles
  }
}

Déployez le modèle Bicep pour inscrire le principal :

az deployment group create \
    --resource-group "<resource-group>" \
    --template-file register-principal.bicep \
    --parameters clusterName="<cluster-name>" principalId="<principal-id>"

Listez tous les principaux inscrits sur le cluster à l’aide de l’API REST (utile après un déploiement Bicep) :

az rest \
    --method GET \
    --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.DocumentDB/mongoClusters/<cluster-name>/users?api-version=2025-09-01"

Obtenez les détails d’un principal inscrit particulier créé par Bicep (remplacer <principal-id>) :

az resource show \
    --resource-group "<resource-group>" \
    --name "<cluster-name>/users/<principal-id>" \
    --resource-type "Microsoft.DocumentDB/mongoClusters/users" \
    --latest-include-preview

Supprimez le principal en supprimant la ressource (ou déployez un modèle sans la ressource utilisateur) :

az resource delete \
    --resource-group "<resource-group>" \
    --name "<cluster-name>/users/<principal-id>" \
    --resource-type "Microsoft.DocumentDB/mongoClusters/users" \
    --latest-include-preview

Ouvrez le cluster Azure DocumentDB cible dans le portail Azure.

Sous Paramètres, sélectionnez Authentication.

Dans la section Authentification Microsoft Entra ID, le portail liste les principaux Microsoft Entra inscrits par ID d’objet. Utilisez cette vue pour :

• Analysez la liste des identificateurs d’objet attendus.
• Inspectez les détails d’un seul principal en sélectionnant une entrée répertoriée (ou utilisez la fonctionnalité de recherche du portail).
• Utilisez l’action Supprimer en regard d’une entrée pour révoquer immédiatement l’accès au plan de données du principal.

Pour obtenir des noms conviviaux pour les identificateurs d’objet affichés dans la liste du portail, utilisez la page Utilisateurs de la section Microsoft Entra ID . Ensuite, recherchez par ID d’objet ou nom convivial.

Obtenez l’identificateur unique (ID d’objet) du principal Microsoft Entra auquel vous souhaitez accorder l’accès à l’aide de l’une des commandes suivantes :

• Identité de connexion actuelle

  az ad signed-in-user show      
  

• Une autre identité humaine à l’aide d’un nom convivial

  az ad user show \
    --id "<user-alias-and-domain>"
  

• Principal de service à l’aide de l’identificateur d’application

  az ad sp show \
    --id "<application-id>"
  

• Identité managée à l’aide du groupe de ressources et du nom

  az identity show \
    --resource-group "<resource-group>" \
    --name "<managed-identity-name>"      
  

Créez un fichier Terraform (par exemple register-principal.tf) pour inscrire le principal et mapper les rôles de base de données à l’aide du fournisseur AzAPI :

variable "cluster_name" {
  type        = string
  description = "Name of the existing cluster"
}

variable "resource_group_name" {
  type        = string
  description = "Name of the existing resource group"
}

variable "principal_id" {
  type        = string
  description = "Object ID of the Microsoft Entra principal"
}

variable "principal_type" {
  type        = string
  description = "Type of principal: User, ServicePrincipal, or ManagedIdentity"
  default     = "User"
}

variable "roles" {
  type = list(object({
    db   = string
    role = string
  }))
  description = "Database roles to assign"
  default = [
    {
      db   = "sales"
      role = "readWrite"
    }
  ]
}

terraform {
  required_providers {
    azapi = {
      source  = "azure/azapi"
      version = "~> 2.0"
    }
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}

provider "azurerm" {
  features {}
}

provider "azapi" {}

data "azurerm_resource_group" "existing" {
  name = var.resource_group_name
}

data "azurerm_mongo_cluster" "existing" {
  name                = var.cluster_name
  resource_group_name = var.resource_group_name
}

resource "azapi_resource" "mongo_cluster_user" {
  type      = "Microsoft.DocumentDB/mongoClusters/users@2025-09-01"
  name      = var.principal_id
  parent_id = data.azurerm_mongo_cluster.existing.id
  location  = data.azurerm_resource_group.existing.location

  body = {
    properties = {
      identityProvider = {
        type = "MicrosoftEntraID"
        properties = {
          principalType = var.principal_type
        }
      }
      roles = var.roles
    }
  }
}

Créez un fichier de variables nommé register-principal.tfvars:

cluster_name        = "<cluster-name>"
resource_group_name = "<resource-group>"
principal_id        = "<principal-id>"
principal_type      = "User"
roles = [
  {
    db   = "sales"
    role = "readWrite"
  }
]

Initialisez et appliquez la configuration Terraform pour inscrire le principal :

terraform init --upgrade

ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform plan --var-file="register-principal.tfvars" --out "register-principal.tfplan"

ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform apply "register-principal.tfplan"

Répertoriez toutes les entités enregistrées pour le cluster à l’aide de l’API REST (utile après le déploiement Terraform) :

az rest \
    --method GET \
    --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.DocumentDB/mongoClusters/<cluster-name>/users?api-version=2025-09-01"

Obtenez les détails d’un principal inscrit spécifique créé par Terraform (remplacement <principal-id>) :

az resource show \
    --resource-group "<resource-group>" \
    --name "<cluster-name>/users/<principal-id>" \
    --resource-type "Microsoft.DocumentDB/mongoClusters/users" \
    --latest-include-preview

Supprimez le principal en détruisant la ressource Terraform :

ARM_SUBSCRIPTION_ID=$(az account show --query id --output tsv) terraform destroy --var-file="register-principal.tfvars"

Accédez au cluster Azure DocumentDB.

Sélectionnez l’option de menu de navigation chaînes de connexion.

Copiez ou enregistrez la valeur à partir du champ chaîne de connexion .