Condividi tramite

Connettersi ad Azure DocumentDB usando il controllo degli accessi in base al ruolo e Microsoft Entra ID

Azure DocumentDB supporta l'ID Microsoft Entra insieme all'autenticazione nativa di DocumentDB. Ogni cluster viene creato con l'autenticazione nativa abilitata e un utente amministratore predefinito.

Il controllo degli accessi in base al ruolo fornisce un meccanismo centralizzato per assegnare e applicare le autorizzazioni tramite Microsoft Entra ID, assicurando che solo le identità autorizzate possano eseguire operazioni sui cluster. Questo approccio semplifica la governance, supporta i principi con privilegi minimi e semplifica il controllo, consentendo alle organizzazioni di mantenere l'integrità operativa e la conformità man mano che le distribuzioni aumentano. La gestione dell'accesso in Azure DocumentDB prevede due livelli distinti:

  • Accesso basato sui ruoli di Azure per la gestione del cluster come risorsa di Azure (ad esempio la lettura dei metadati, la gestione delle regole del firewall e la configurazione di endpoint privati)
  • Accesso a DocumentDB per la lettura e la scrittura di dati all'interno di database e raccolte nel cluster.

Abilitare Microsoft Entra ID per consentire ai principali di Microsoft Entra (utenti, entità servizio o identità gestite) di autenticarsi al cluster. L'autenticazione con ID Entra di Microsoft viene implementata tramite OpenID Connect (OIDC). I client presentano un token di accesso OIDC rilasciato da Entra al driver MongoDB. Un cluster deve avere l'autenticazione nativa abilitata; le configurazioni supportate sono l'autenticazione nativa o nativa e Microsoft Entra ID. Microsoft Entra ID non può essere l'unico metodo di autenticazione.

Annotazioni

È possibile abilitare o modificare i metodi di autenticazione in un cluster in qualsiasi momento dopo il provisioning. La modifica dei metodi di autenticazione non richiede un riavvio del cluster ed è non dirompente. Quando viene creato un cluster, è necessario abilitare l'autenticazione nativa di DocumentDB. È possibile disabilitare l'autenticazione nativa al termine del provisioning del cluster.

I vantaggi dell'uso di Microsoft Entra ID per l'autenticazione includono:

  • Identità uniforme e accesso tra i servizi di Azure.
  • Gestione centralizzata di credenziali, criteri password e rotazione.
  • Supporto per metodi di autenticazione senza password e a più fattori da Microsoft Entra ID.
  • Autenticazione basata su token per le applicazioni, eliminando le password archiviate.

Quando l'autenticazione di Microsoft Entra ID è abilitata, è possibile registrare una o più entità Microsoft Entra come utenti amministrativi o non amministrativi nel cluster. Le entità registrate diventano risorse di Azure in Microsoft.DocumentDB/mongoClusters/users e vengono replicate nel database. Il mapping di queste entità ai ruoli del database MongoDB concede i privilegi di database corrispondenti. Questa forma di autenticazione supporta più tipi di entità, tra cui; utenti umani, entità servizio (app), identità gestite assegnate dall'utente e assegnate dal sistema.

Annotazioni

È possibile configurare più identità e tipi di identità di Microsoft Entra ID come amministratori per un cluster contemporaneamente. I tipi di identità ID Microsoft Entra includono, ma non sono limitati a:

  • Identità umane
  • Identità gestite assegnate dall'utente
  • Identità gestite assegnate dal sistema
  • Identità dei carichi di lavoro

Tutti i tipi di identità possono essere amministratori contemporaneamente.

Gli utenti amministratori hanno privilegi completi per gestire il cluster e i relativi dati. Gli utenti non amministrativi possono essere aggiunti per le attività di produzione in corso che non richiedono privilegi amministrativi. Gli utenti non amministratori in genere dispongono di ruoli con restrizioni, ad esempio accesso in sola lettura o in lettura/scrittura a database specifici, ma non hanno la possibilità di eseguire azioni amministrative a livello di cluster.

Prima di usare questa funzionalità, esaminare le considerazioni seguenti:

  • I metodi di autenticazione nel cluster primario e nel cluster di replica vengono gestiti in modo indipendente.
  • Le entità di sicurezza Microsoft Entra sono persistenti nei metadati del cluster. Se un'entità di sicurezza viene eliminata da Microsoft Entra ID, l'utente del cluster corrispondente rimane ma non può più ottenere nuovi token. I token esistenti rimangono validi fino alla scadenza (in genere fino a 90 minuti dal rilascio del token).
  • Per revocare immediatamente l'accesso, rimuovere l'entità dal cluster (eliminare la users/<principal-id> risorsa) ed eliminare i ruoli del database associati. Gli amministratori del database devono gestire il trasferimento della proprietà o la pulizia per le entità eliminate.

Prerequisiti

  • Una sottoscrizione di Azure

  • Un cluster Di Azure DocumentDB esistente

  • Una o più identità esistenti in Microsoft Entra ID.

Gestire il controllo degli accessi in base al ruolo di Azure

Il controllo degli accessi in base al ruolo di Azure si riferisce alla possibilità di gestire le risorse per un servizio di Azure senza gestire i dati. Ad esempio, l'accesso basato sui ruoli per i cluster Azure DocumentDB può includere la possibilità di:

  • Leggere tutti i metadati di account e risorse
  • Leggere e rigenerare le stringhe di connessione
  • Gestire database e raccolte
  • Modificare le proprietà dell'account

Azure DocumentDB supporta il controllo degli accessi in base al ruolo di Azure per mongoCluster il tipo di risorsa. Le azioni seguenti per mongoCluster il tipo di risorsa sono disponibili nel controllo degli accessi in base al ruolo di Azure per le singole assegnazioni e la creazione di ruoli personalizzati per il controllo degli accessi in base al ruolo:

Description
Microsoft.DocumentDB/mongoClusters/read Legge una mongoCluster risorsa o elenca tutte le mongoCluster risorse.
Microsoft.DocumentDB/mongoClusters/write Creare o aggiornare le proprietà o i tag della risorsa specificata mongoCluster .
Microsoft.DocumentDB/mongoClusters/delete Elimina la risorsa specificata mongoCluster .
Microsoft.DocumentDB/mongoClusters/PrivateEndpointConnectionsApproval/action Gestire una connessione endpoint privato della risorsa mongoCluster
Microsoft.DocumentDB/mongoClusters/listConnectionStrings/action Elencare le stringhe di connessione per una determinata mongoCluster risorsa
Microsoft.DocumentDB/mongoClusters/firewallRules/read Legge una regola del firewall o elenca tutte le regole del firewall per la risorsa specificata mongoCluster .
Microsoft.DocumentDB/mongoClusters/firewallRules/write Creare o aggiornare una regola del firewall in una risorsa specificata mongoCluster .
Microsoft.DocumentDB/mongoClusters/firewallRules/delete Elimina una regola del firewall esistente per la risorsa specificata mongoCluster .
Microsoft.DocumentDB/mongoClusters/privateEndpointConnectionProxies/read Legge un proxy di connessione dell'endpoint privato per la risorsa specificata mongoCluster.
Microsoft.DocumentDB/mongoClusters/privateEndpointConnectionProxies/write Creare o aggiornare una connessione proxy per endpoint privato su una risorsa specificata mongoCluster.
Microsoft.DocumentDB/mongoClusters/privateEndpointConnectionProxies/delete Elimina un proxy di connessione dell'endpoint privato esistente per la risorsa specificata mongoCluster.
Microsoft.DocumentDB/mongoClusters/privateEndpointConnectionProxies/validate/action Convalida il proxy di connessione dell'endpoint privato per la risorsa specificata mongoCluster.
Microsoft.DocumentDB/mongoClusters/privateEndpointConnections/read Viene letta una connessione di endpoint privato o vengono elencate tutte le connessioni di endpoint privati per la risorsa specificata mongoCluster.
Microsoft.DocumentDB/mongoClusters/privateEndpointConnections/write Creare o aggiornare una connessione endpoint privata in una risorsa mongoCluster specificata.
Microsoft.DocumentDB/mongoClusters/privateEndpointConnections/delete Elimina un endpoint privato esistente per la risorsa specificata mongoCluster.
Microsoft.DocumentDB/mongoClusters/privateLinkResources/read Legge una risorsa collegamento privato o elenca tutte le risorse di collegamento privato per la risorsa specificata mongoCluster .
Microsoft.DocumentDB/mongoClusters/users/read Legge un utente o elenca tutti gli utenti per la risorsa specificata mongoCluster .
Microsoft.DocumentDB/mongoClusters/users/write Creare o aggiornare un utente in una risorsa specificata mongoCluster .
Microsoft.DocumentDB/mongoClusters/users/delete Elimina un utente esistente per la risorsa specificata mongoCluster .

  1. Aprire un nuovo terminale.

  2. Accedere all'interfaccia della riga di comando di Azure.

  3. Usare az group show per ottenere i metadati per il gruppo di risorse corrente.

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

  4. Osservate l'output del comando precedente. Registrare il valore della id proprietà per questo gruppo di risorse perché è necessario usare nel passaggio successivo.

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

    Annotazioni

    In questo esempio il id valore sarà /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/msdocs-identity-example. In questo esempio vengono usati dati fittizi e l'identificatore è diverso da questo esempio. Questa stringa è un esempio troncato dell'output.

  5. Creare un nuovo file JSON denominato role-definition.json. Nel file creare questa definizione di risorsa specificando i valori elencati qui. Per l'elenco AssignableScopes , aggiungere la id proprietà del gruppo di risorse registrato nel passaggio precedente.

    {
  "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"
  ]
}

    Annotazioni

    In questo esempio viene usato il /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/msdocs-identity-example valore registrato nel passaggio precedente. L'identificatore effettivo della risorsa potrebbe essere diverso.

  6. Creare una nuova definizione di ruolo usando az role definition create. Usare il file role-definition.json come input per l'argomento --role-definition .

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

  7. Esaminare l'output del comando di creazione della definizione. L'output contiene l'identificatore univoco della definizione del ruolo nella id proprietà . Registrare questo valore perché è necessario usare nel passaggio di assegnazione più avanti in questa guida.

    {
  "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"
}

    Annotazioni

    In questo esempio il id valore sarà /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/msdocs-identity-example/providers/Microsoft.Authorization/roleDefinitions/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1. In questo esempio vengono usati dati fittizi e l'identificatore è diverso da questo esempio. Questo esempio è un subset del tipico codice JSON restituito dalla distribuzione per maggiore chiarezza.

  1. Aprire un nuovo terminale.

  2. Accedere all'interfaccia della riga di comando di Azure.

  3. Creare un nuovo file Bicep per definire la definizione del ruolo. Assegnare al file il nome control-plane-role-definition.bicep. Aggiungere questi actions elementi alla definizione:

    Description
    Microsoft.DocumentDb/mongoClusters/* Abilita tutte le azioni possibili. 
    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

  4. Distribuire il modello Bicep usando az deployment group create. Specificare il nome del modello Bicep e del gruppo di risorse di Azure.

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

  5. Esaminare l'output della distribuzione. L'output contiene l'identificatore univoco della definizione del ruolo nella properties.outputs.definitionId.value proprietà . Registrare questo valore perché è necessario usare nel passaggio di assegnazione più avanti in questa guida.

    {
  "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"
      }
    }
  }
}

    Annotazioni

    In questo esempio il id valore sarà /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/msdocs-identity-example/providers/Microsoft.Authorization/roleDefinitions/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1. In questo esempio vengono usati dati fittizi e l'identificatore è diverso da questo esempio. Questo esempio è un subset del tipico codice JSON restituito dalla distribuzione per maggiore chiarezza.

  6. Creare un nuovo file Bicep per definire l'assegnazione di ruolo. Assegnare al file il nome 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
  }
}

  7. Creare un nuovo file di parametri Bicep denominato control-plane-role-assignment.bicepparam. In questo file di parametri, assegnare gli identificatori di definizione del ruolo registrati in precedenza al parametro roleDefinitionId e l'identificatore univoco della propria identità al parametro identityId.

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

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

  8. Implementare questo modello Bicep usando 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

  1. Accedere al portale di Azure (https://portal.azure.com).

  2. Immettere Gruppo di risorse nella barra di ricerca globale.

  3. In Servizi selezionare Gruppi di risorse.

  4. Nel riquadro Gruppi di risorse selezionare il gruppo di risorse esistente.

  5. Nel riquadro del gruppo di risorse selezionare Controllo di accesso (IAM) nel menu del servizio.

  6. Nel riquadro Controllo di accesso (IAM) selezionare Aggiungi. Selezionare quindi Aggiungi ruolo personalizzato.

  7. Nel riquadro Informazioni di base configurare le opzioni seguenti e quindi selezionare Avanti:

    Value
    Nome del ruolo personalizzato Azure DocumentDB RBAC Owner
    Descrizione Can perform all Azure role-based access control actions for Azure DocumentDB clusters.
    Autorizzazioni di base Iniziare da zero

  8. Nel riquadro Autorizzazioni selezionare Aggiungi autorizzazioni. Quindi, cerca DocumentDB nella finestra di dialogo delle autorizzazioni. Infine, selezionare l'opzione Microsoft.DocumentDB/mongoClusters .

  9. Nella finestra di dialogo autorizzazioni selezionare tutte le azioni per Microsoft.DocumentDB/mongoClusters. Selezionare quindi Aggiungi per tornare al riquadro *Autorizzazioni .

  10. Nel riquadro Autorizzazioni osservare l'elenco delle autorizzazioni. Selezionare quindi Rivedi + crea.

  11. Nel riquadro Rivedi e crea esaminare le opzioni specificate per la nuova definizione del ruolo. Infine, selezionare Crea.

  12. Attendere che il portale finisca di creare la definizione del ruolo.

  13. Nel riquadro Controllo di accesso (IAM) selezionare Aggiungi e quindi Aggiungi assegnazione di ruolo.

  14. Nel riquadro Ruolo, cercare Azure DocumentDB e quindi selezionare il ruolo Proprietario RBAC di Azure DocumentDB creato in precedenza in questa guida. Quindi seleziona Avanti.

    Suggerimento

    Facoltativamente, è possibile filtrare l'elenco dei ruoli in modo da includere solo ruoli personalizzati.

  15. Nel riquadro Membri selezionare l'opzione Seleziona membri . Nella finestra di dialogo membri selezionare l'identità che si vuole concedere a questo livello di accesso per i cluster Azure DocumentDB e quindi usare l'opzione Seleziona per confermare la scelta.

  16. Tornare al riquadro Membri , esaminare il membro selezionato[s] e quindi selezionare Rivedi e assegna.

  17. Nel riquadro Rivedi e assegna esaminare le opzioni specificate per la nuova assegnazione di ruolo. Infine, selezionare Rivedi e assegna.

  18. Attendere che il portale finisca di creare l'assegnazione di ruolo.

  1. Aprire un nuovo terminale.

  2. Accedere all'interfaccia della riga di comando di Azure.

  3. Verifica l'abbonamento Azure di destinazione.

    az account show

  4. Creare un nuovo file Terraform per definire la definizione del ruolo. Denominare il file control-plane-role-definition.tf. Aggiungere questi actions elementi alla definizione:

    Description
    Microsoft.DocumentDb/mongoClusters/* Abilita tutte le azioni possibili. 
    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
}

  5. Avviare la distribuzione di Terraform.

    terraform init --upgrade

  6. Creare un piano di esecuzione per la definizione del ruolo e salvarlo in un file denominato role-definition.tfplan.

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

  7. Applicare il piano di esecuzione per distribuire la definizione del ruolo in Azure.

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

  8. Esaminare l'output della distribuzione. L'output contiene l'identificatore univoco della definizione del ruolo nella definition_id proprietà . Registrare questo valore perché è necessario usare nel passaggio di assegnazione più avanti in questa guida.

  9. Creare un nuovo file Terraform per definire l'assegnazione di ruolo. Assegnare al file il nome 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
}

  10. Creare un nuovo file di variabili Terraform denominato control-plane-role-assignment.tfvars. In questo file di variabili; assegnare gli identificatori di definizione del ruolo registrati in precedenza alla role_definition_id variabile e l'identificatore univoco per l'identità alla identity_id variabile.

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

  11. Inizializza e applica questa configurazione 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"

Abilitare l'autenticazione di Microsoft Entra ID

Quando si crea un cluster Di Azure DocumentDB, il cluster è configurato per l'uso esclusivo dell'autenticazione nativa per impostazione predefinita. Per abilitare l'autenticazione con Microsoft Entra ID, attivare il metodo di autenticazione Microsoft Entra ID e aggiungere identità ID Microsoft Entra al cluster.

  1. Ottenere i dettagli per l'account attualmente connesso usando az ad signed-in-user.

    az ad signed-in-user show

  2. Il comando restituisce una risposta JSON contenente vari campi.

    {
  "@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>"
}

    Suggerimento

    Registrare il valore del id campo. In questo esempio, tale valore sarà aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb. Questo valore può quindi essere usato in vari script per concedere le autorizzazioni di controllo degli accessi in base al ruolo dell'account corrente alle risorse di Azure. Se invece si utilizza un'identità gestita, è possibile ottenere il id associato a tale identità gestita utilizzando il comando az identity show.

  3. Abilitare l'autenticazione di Microsoft Entra ID nel cluster aggiornando la risorsa cluster in modo da includere MicrosoftEntraID nella authConfig.allowedModes matrice:

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

    Annotazioni

    Sostituire <resource-group> e <cluster-name> con i propri valori.

  4. Verificare che la modifica sia stata applicata leggendo la authConfig proprietà nel cluster usando az resource show.

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

    Annotazioni

    L'output deve includere l'elenco allowedModes. Se l'ID Microsoft Entra è stato abilitato correttamente, la matrice contiene sia NativeAuth che MicrosoftEntraID.

  1. (Facoltativo) Ottenere l'identificatore univoco per l'entità di sicurezza Microsoft Entra che si intende registrare nel cluster. È possibile ottenerlo con l'interfaccia della riga di comando di Azure usando uno dei comandi seguenti:

    • Identità di accesso corrente

      az ad signed-in-user show

    • Un'altra identità umana usando il nome amichevole

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

    • Entità servizio tramite l'identificatore dell'app

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

    • Gestione dell'identità utilizzando il gruppo di risorse e il nome

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

  2. Creare un piccolo modello Bicep che aggiorna il cluster authConfig in modo da includere l'ID Microsoft Entra (salva con nome 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'
      ]
    }
  }
}

  3. Distribuire il modello per aggiornare il cluster:

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

  4. Verificare la authConfig proprietà nel cluster usando az resource show.

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

    Annotazioni

    L'output deve includere l'elenco allowedModes . Se l'ID Microsoft Entra è stato abilitato correttamente, la matrice contiene sia NativeAuth che MicrosoftEntraID.

  1. Nel riquadro Home del portale di Azure individuare e selezionare l'opzione Microsoft Entra ID .

    Screenshot dell'opzione Microsoft Entra ID nella pagina

    Suggerimento

    Se questa opzione non è elencata, selezionare Altri servizi e quindi cercare Microsoft Entra ID usando il termine di ricerca "Entra".

  2. Nel riquadro Panoramica per il tenant microsoft Entra ID selezionare Utenti all'interno della sezione Gestisci del menu del servizio.

    Screenshot dell'opzione

  3. Nell'elenco degli utenti selezionare l'identità (utente) su cui ottenere altri dettagli.

    Screenshot dell'elenco di utenti per un tenant di Microsoft Entra ID con un utente di esempio evidenziato.

    Annotazioni

    Questo screenshot mostra un utente di esempio denominato "Kai Carter" con un'entità di sicurezza kai@adventure-works.com.

  4. Nel riquadro dei dettagli per l'utente specifico osservare il valore della proprietà ID oggetto .

    Screenshot del riquadro dei dettagli di un utente con l'opzione

    Suggerimento

    Registrare il valore della proprietà ID oggetto . In questo esempio, tale valore sarà aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb. Questo valore può quindi essere usato in vari script per concedere le autorizzazioni di controllo degli accessi in base al ruolo dell'account corrente alle risorse di Azure. I passaggi sono simili se si usa un'identità gestita.

  5. Passare alla risorsa cluster di Azure DocumentDB esistente.

  6. Nel menu del cluster, in Impostazioni, selezionare Autenticazione.

  7. Nella sezione Metodi di autenticazione selezionare Native DocumentDB e Microsoft Entra ID per abilitare l'autenticazione di Microsoft Entra ID insieme all'autenticazione nativa.

  8. Selezionare Salva per salvare in modo permanente la modifica.

  9. La sezione Metodi di autenticazione dovrebbe ora elencare nativeAuth e MicrosoftEntraID come metodi abilitati.

  1. (Facoltativo) Ottenere l'identificatore univoco per l'entità di sicurezza Microsoft Entra che si intende registrare nel cluster. È possibile ottenerlo con l'interfaccia della riga di comando di Azure usando uno dei comandi seguenti:

    • Identità di accesso corrente

      az ad signed-in-user show

    • Un'altra identità umana usando il nome amichevole

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

    • Entità servizio tramite l'identificatore dell'app

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

    • Gestione dell'identità utilizzando il gruppo di risorse e il nome

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

  2. Creare un file di configurazione terraform per abilitare l'autenticazione dell'ID Entra di Microsoft nel cluster esistente. Salvare il file come 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
}

    Suggerimento

    Per altre informazioni sulle opzioni che usano la risorsa azurerm_mongo_cluster, vedere la azurermdocumentazione del provider in Registro Terraform.

  3. Creare un file di variabili denominato enable-entra-id.tfvars con i dettagli del cluster:

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

  4. Inizializzare e applicare la configurazione di Terraform per abilitare l'autenticazione di 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"

  5. Verificare la authConfig proprietà nel cluster usando az resource show.

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

    Annotazioni

    L'output deve includere l'elenco allowedModes . Se l'ID Microsoft Entra è stato abilitato correttamente, la matrice contiene sia NativeAuth che MicrosoftEntraID.

Gestire le identità di Microsoft Entra ID per l'amministrazione di DocumentDB e gli utenti nativi.

Quando l'autenticazione di Microsoft Entra ID è abilitata in un cluster DocumentDB di Azure, è possibile aggiungere una o più principali ID di Microsoft Entra come utenti amministratori in tale cluster. L'amministratore di Microsoft Entra ID può essere un utente di Microsoft Entra ID, un principale del servizio o un'identità gestita. È possibile configurare più amministratori di Microsoft Entra ID in qualsiasi momento.

Gli utenti dell'ID Entra amministrativo vengono creati come entità di Azure in Microsoft.DocumentDB/mongoClusters/users e vengono replicati nel database.

Inoltre, uno o più utenti Microsoft Entra ID non amministrativi possono essere aggiunti a un cluster in qualsiasi momento dopo l'abilitazione dell'autenticazione di Microsoft Entra ID. Gli utenti non amministrativi vengono spesso usati per le attività di produzione in corso che non richiedono privilegi amministrativi.

Per Azure DocumentDB, questo accesso viene concesso registrando le entità di sicurezza di Microsoft Entra nel cluster e eseguendo il mapping ai ruoli del database MongoDB (ad esempio, readWrite in un database o root nel database admin). Le entità registrate vengono create come risorse di Azure di tipo Microsoft.DocumentDB/mongoClusters/users i cui nomi hanno il formato <cluster-name>/users/<principal-id>.

Gli utenti amministratori hanno privilegi completi per gestire il cluster e i relativi dati, incluse le funzionalità complete di gestione degli utenti. Agli utenti non amministratori possono essere concesse autorizzazioni di lettura/scrittura o di sola lettura nel cluster tramite ruoli specifici del database MongoDB. I ruoli readWriteAnyDatabase e clusterAdmin concedono insieme autorizzazioni di lettura/scrittura complete nel cluster, inclusi i privilegi per le operazioni di gestione e database. Il ruolo readAnyDatabase viene usato per concedere autorizzazioni di sola lettura nel cluster. Non è possibile assegnare separatamente i ruoli readWriteAnyDatabase e clusterAdmin , che devono essere concessi insieme per l'accesso in lettura/scrittura completo.

Agli utenti e alle entità di sicurezza non amministrativi (secondari) vengono concesse autorizzazioni limitate di gestione degli utenti nel cluster, come descritto nella tabella seguente:

Provider di sicurezza Ruolo CreaUtente DeleteUser UpdateUser ListaUtente
Microsoft Entra ID Autorizzazioni di lettura e scrittura (readWriteAnyDatabase, clusterAdmin) ❌ ❌ ❌ ✔️
Microsoft Entra ID Sola lettura (readAnyDatabase) ❌ ❌ ❌ ✔️
DocumentDB nativo Autorizzazioni di lettura e scrittura (readWriteAnyDatabase, clusterAdmin) ❌ ❌ Solo per modificare la propria password ✔️
DocumentDB nativo Sola lettura (readAnyDatabase) ❌ ❌ Solo per modificare la propria password ✔️

  1. Ottenere l'identificatore univoco (ID oggetto) dell'entità Microsoft Entra a cui si vuole concedere l'accesso usando uno dei comandi seguenti:

    • Identità di accesso corrente

      az ad signed-in-user show

    • Un'altra identità umana usando il nome amichevole

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

    • Entità servizio tramite l'identificatore dell'app

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

    • Gestione dell'identità utilizzando il gruppo di risorse e il nome

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

  2. Registrare l'entità nel cluster ed eseguirne il mapping ai ruoli del database MongoDB. Nell'esempio seguente viene registrata un'entità di sicurezza come utente readWrite nel database sales:

    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
    • Sostituire principalType con servicePrincipal per le entità app/servizio o con ManagedIdentity per le identità gestite.
    • Per concedere privilegi amministrativi, usare {"db":"admin","role":"root"} nella roles matrice.

  3. Elencare tutte le entità registrate e i relativi ruoli mappati (visualizzazione a livello di 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 risposta contiene una matrice di risorse utente, ognuna con identityProvider metadati e una roles matrice che mostra i ruoli del database mappati.

  4. Ottenere i dettagli per un'entità registrata specifica (sostituire <principal-id>):

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

  5. Rimuovere un'entità di sicurezza registrata (revocare l'accesso al piano dati):

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

  1. Creare un file Bicep (ad esempio register-principal.bicep) per registrare i ruoli del database principale e mappare:

    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
  }
}

  2. Distribuire il modello Bicep per registrare l'entità di sicurezza:

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

  3. Elencare tutte le entità registrate per il cluster usando l'API REST (utile dopo la distribuzione 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"

  4. Ottenere i dettagli per un'entità registrata specifica creata da Bicep (sostituire <principal-id>):

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

  5. Rimuovere l'entità principale eliminando la risorsa (o utilizzando un modello senza la risorsa utente):

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

  1. Aprire il cluster Azure DocumentDB di destinazione nel portale di Azure.

  2. In Impostazioni selezionare Autenticazione.

  3. Nella sezione Autenticazione Microsoft Entra ID nel portale sono elencate le entità di sicurezza Microsoft Entra registrate in base all'ID oggetto. Usare questa visualizzazione per:

    • Analizzare l'elenco per individuare gli identificatori di oggetto previsti.
    • Esaminare i dettagli per una singola entità selezionando una voce elencata (o usare la funzionalità di ricerca del portale).
    • Usare l'azione Rimuovi accanto a un elemento per revocare immediatamente l'accesso al piano dati dell'entità di sicurezza.

  4. Per ottenere nomi descrittivi per gli identificatori di oggetto visualizzati nell'elenco del portale, usare la pagina Utenti all'interno della sezione Microsoft Entra ID . Cerca quindi in base all'ID oggetto o al nome descrittivo.

  1. Ottenere l'identificatore univoco (ID oggetto) dell'entità Microsoft Entra a cui si vuole concedere l'accesso usando uno dei comandi seguenti:

    • Identità di accesso corrente

      az ad signed-in-user show

    • Un'altra identità umana usando il nome amichevole

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

    • Entità servizio tramite l'identificatore dell'app

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

    • Gestione dell'identità utilizzando il gruppo di risorse e il nome

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

  2. Creare un file Terraform (ad esempio register-principal.tf) per registrare i ruoli del database principale e mappare usando il provider 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
    }
  }
}

    Suggerimento

    Per altre informazioni sul provider AzAPI, vedere la documentazione del provider AzAPI di Azure.

    • Sostituire principalType con servicePrincipal per le entità app/servizio o con ManagedIdentity per le identità gestite.
    • Per concedere privilegi amministrativi, usare {"db":"admin","role":"root"} nella roles matrice.

  3. Creare un file di variabili denominato register-principal.tfvars:

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

  4. Inizializza e applica la configurazione di Terraform per registrare l'entità di sicurezza:

    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"

  5. Elencare tutte le entità registrate per il cluster usando l'API REST (utile dopo la distribuzione di 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"

  6. Ottenere i dettagli per un'entità registrata specifica creata da Terraform (sostituisci <principal-id>):

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

  7. Rimuovere l'entità di sicurezza eliminando la risorsa Terraform:

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

Annotazioni

Viene creato un cluster di Azure DocumentDB con un utente documentDB nativo predefinito. È possibile aggiungere altri utenti amministrativi nativi di DocumentDB dopo il completamento del provisioning del cluster. Gli utenti amministratori di Microsoft Entra ID aggiunti al cluster saranno oltre agli utenti di DocumentDB amministrativi nativi definiti nello stesso cluster. Tutte le identità amministrative di Microsoft Entra ID vengono replicate nel database.

Le identità ID Microsoft Entra non amministrative vengono create nel database. Quando si elencano utenti non amministrativi nel database, l'elenco contiene tutte le identità dell'ID Di Microsoft Entra amministrative e non amministrative e tutti gli utenti nativi di DocumentDB secondari (non amministrativi).

Ottenere le credenziali del cluster

È possibile connettersi al cluster usando un URI di connessione o un oggetto impostazioni personalizzato dal driver per la lingua preferita. In entrambe le opzioni, lo schema deve essere impostato su mongodb+srv per connettersi al cluster. L'host si trova nel *.global.mongocluster.cosmos.azure.com dominio o *.mongocluster.cosmos.azure.com a seconda che si usi il cluster corrente o l'endpoint di lettura/scrittura globale. Lo schema +srv e l'host *.global.* assicurano che il client sia connesso dinamicamente al cluster scrivibile appropriato in una configurazione multi-cluster anche se si verifica un'operazione di scambio di aree. In una configurazione a cluster singolo è possibile usare indifferentemente una delle due stringhe di connessione.

L'impostazione tls deve essere abilitata anche. Le impostazioni consigliate rimanenti sono le impostazioni di configurazione consigliate.

Opzione Value
scheme mongodb+srv
host <cluster-name>.global.mongocluster.cosmos.azure.com o <cluster-name>.mongocluster.cosmos.azure.com
tls true
authMechanism MONGODB-OIDC
retrywrites false
maxIdleTimeMS 120000

Importante

Usare il portale di Azure per ottenere la stringa di connessione.

  1. Passare al cluster Azure DocumentDB.

  2. Selezionare l'opzione del menu di spostamento Stringhe di connessione.

  3. Copiare o registrare il valore del campo Stringa di connessione.

    Suggerimento

    Le stringhe di connessione microsoft Entra ID si trovano nella sezione Microsoft Entra ID .

Connettersi con Microsoft Entra ID in MongoDB Shell

Usare un dispositivo client con la shell MongoDB installata per connettersi al cluster di Azure DocumentDB usando un'identità ID Microsoft Entra.

  1. Aprire un terminale in un client con la shell MongoDB installata.

  2. Ottenere il nome del cluster Azure DocumentDB e l'ID client per l'identità di destinazione.

  3. Connettersi usando la stringa di connessione seguente:

    mongosh "mongodb+srv://<client-id>@<cluster-name>.global.mongocluster.cosmos.azure.com/?tls=true&authMechanism=MONGODB-OIDC&retrywrites=false&maxIdleTimeMS=120000"

Connettersi tramite Microsoft Entra ID in Visual Studio Code

Usare Visual Studio Code con l'estensione DocumentDB per connettersi al cluster di Azure DocumentDB usando un'identità ID Microsoft Entra.

Importante

Quando si esegue l'autenticazione in un cluster di Azure DocumentDB usando Microsoft Entra ID in Visual Studio Code con l'estensione DocumentDB, shell la funzionalità non è supportata. Se è necessario usare la shell MongoDB con l'autenticazione microsoft Entra ID, usare MongoDB Shell direttamente in un computer client.

  1. Apri Visual Studio Code.

  2. Navigare l'estensione DocumentDB nella barra laterale.

  3. Nella sezione Connessioni selezionare + Nuova connessione....

  4. Nella finestra di dialogo tipo di connessione selezionare Stringa di connessione.

  5. Usare la stringa di connessione seguente:

    mongodb+srv://<client-id>@<cluster-name>.global.mongocluster.cosmos.azure.com/?tls=true&authMechanism=MONGODB-OIDC&retrywrites=false&maxIdleTimeMS=120000

  6. Attendere che il prompt automatico usi l'autenticazione di Microsoft Entra ID. Immettere le credenziali appropriate per il tipo di identità.

    Annotazioni

    Ad esempio, se si esegue l'accesso usando la propria identità (un'identità umana), usare l'esperienza di autenticazione senza password.

  7. Attendere il completamento della connessione. Viene quindi aggiunta una nuova voce di DocumentDB alla sezione Connessioni per il cluster.

Connettersi con Microsoft Entra ID in MongoDB Compass

Connettersi al cluster Azure DocumentDB utilizzando un'identità Microsoft Entra ID direttamente con l'applicazione MongoDB Compass.

  1. Avviare l'applicazione MongoDB Compass.

  2. Selezionare + nel menu Connessioni per aggiungere una nuova connessione.

  3. Attivare o disattivare l'impostazione Modifica stringa di connessione da abilitare nella finestra di dialogo Nuova connessione .

  4. Immettere la stringa di connessione seguente nella casella di input URI .

    mongodb+srv://<client-id>@<cluster-name>.global.mongocluster.cosmos.azure.com/?tls=true&authMechanism=MONGODB-OIDC&retrywrites=false&maxIdleTimeMS=120000

  5. Aprire ora la finestra di dialogo Opzioni di connessione avanzate .

  6. Nella sezione Generale selezionare mongodb+srv per Schema stringa di connessione.

  7. Passare quindi alla sezione Autenticazione .

  8. Assicurarsi che l'opzione OIDC sia selezionata.

  9. Passare ora alla sezione Opzioni OIDC .

  10. Assicurarsi che sia selezionata anche l'opzione Considera attendibile l'endpoint di destinazione.

  11. Selezionare Salva e connetti.

Gestire le identità ID Microsoft Entra secondarie (non amministrative) di DocumentDB

Accedi al cluster con un'identità amministrativa di Microsoft Entra ID per gestire le operazioni relative a identità di Microsoft Entra ID non amministrative.

Annotazioni

Tutti i comandi di gestione per gli utenti non amministrativi sono supportati per SecurityPrincipal e user tipi principali.

  1. Accedete al cluster utilizzando un'identità ID Microsoft Entra amministrativa e uno strumento come MongoDB Shell.

  2. Aggiungere un'identità Microsoft Entra ID non amministratore con autorizzazioni di lettura/scrittura nel cluster usando il comando createUser:

    db.runCommand(
  {
    createUser: "<entra-id-unique-identifier>",
    roles: [
      { role: "clusterAdmin", db: "admin" },
      { role: "readWriteAnyDatabase", db: "admin" }
    ],
    customData: { "IdentityProvider": { "type": "MicrosoftEntraID", "properties": { "principalType": "user" } } }
  }
)

  3. Aggiungere un'identità Microsoft Entra ID non amministrativa con autorizzazioni di sola lettura per il cluster con createUser e con un diverso set di ruoli.

    db.runCommand(
  {
    createUser: "<entra-id-unique-identifier>",
    roles: [
      { role: "readAnyDatabase", db: "admin" }
    ],
    customData: { "IdentityProvider": { "type": "MicrosoftEntraID", "properties": { "principalType": "user" } } }
  }
)

  4. Rimuovere un'identità non amministrativa di Microsoft Entra ID dal cluster usando il comando dropUser.

    db.runCommand(
  {
    dropUser: "<entra-id-unique-identifier>"
  }
)

  5. Elencare tutti gli utenti di Microsoft Entra ID e DocumentDB nativi nel cluster usando userInfo.

    db.runCommand(
  {
    usersInfo: 1
  }
)

    Annotazioni

    Tutti gli utenti amministratori di Microsoft Entra ID e DocumentDB nativi vengono replicati nel database. A causa di questa replica, l'elenco degli utenti include tutti gli utenti amministrativi e non amministrativi di Microsoft Entra ID e gli utenti nativi di DocumentDB nel cluster.

Connettersi con Microsoft Entra ID nel codice

Verificare di aver concesso correttamente l'accesso usando il codice dell'applicazione e la libreria client appropriata per la lingua preferita.

class AzureIdentityTokenCallback(OIDCCallback):
    def __init__(self, credential):
        self.credential = credential

    def fetch(self, context: OIDCCallbackContext) -> OIDCCallbackResult:
        token = self.credential.get_token(
            "https://ossrdbms-aad.database.windows.net/.default").token
        return OIDCCallbackResult(access_token=token)

clusterName = "<cluster-name>"

credential = DefaultAzureCredential()
authProperties = {"OIDC_CALLBACK": AzureIdentityTokenCallback(credential)}

client = MongoClient(
  f"mongodb+srv://{clusterName}.global.mongocluster.cosmos.azure.com/",
  connectTimeoutMS=120000,
  tls=True,
  retryWrites=True,
  authMechanism="MONGODB-OIDC",
  authMechanismProperties=authProperties
)

const AzureIdentityTokenCallback = async (params: OIDCCallbackParams, credential: TokenCredential): Promise<OIDCResponse> => {
  const tokenResponse: AccessToken | null = await credential.getToken(['https://ossrdbms-aad.database.windows.net/.default']);
  return {
      accessToken: tokenResponse?.token || '',
      expiresInSeconds: (tokenResponse?.expiresOnTimestamp || 0) - Math.floor(Date.now() / 1000)
  };
};

const clusterName: string = '<cluster-name>';

const credential: TokenCredential = new DefaultAzureCredential();

const client = new MongoClient(
    `mongodb+srv://${clusterName}.global.mongocluster.cosmos.azure.com/`, {
    connectTimeoutMS: 120000,
    tls: true,
    retryWrites: true,
    authMechanism: 'MONGODB-OIDC',
    authMechanismProperties: {
        OIDC_CALLBACK: (params: OIDCCallbackParams) => AzureIdentityTokenCallback(params, credential),
        ALLOWED_HOSTS: ['*.azure.com']
    }
  }
);

string tenantId = "<microsoft-entra-tenant-id>";
string clusterName = "<cluster-name>";

DefaultAzureCredential credential = new();
AzureIdentityTokenHandler tokenHandler = new(credential, tenantId);

MongoUrl url = MongoUrl.Create($"mongodb+srv://{clusterName}.global.mongocluster.cosmos.azure.com/");
MongoClientSettings settings = MongoClientSettings.FromUrl(url);
settings.UseTls = true;
settings.RetryWrites = false;
settings.MaxConnectionIdleTime = TimeSpan.FromMinutes(2);
settings.Credential = MongoCredential.CreateOidcCredential(tokenHandler);
settings.Freeze();

MongoClient client = new(settings);

internal sealed class AzureIdentityTokenHandler(
    TokenCredential credential,
    string tenantId
) : IOidcCallback
{
    private readonly string[] scopes = ["https://ossrdbms-aad.database.windows.net/.default"];

    public OidcAccessToken GetOidcAccessToken(OidcCallbackParameters parameters, CancellationToken cancellationToken)
    {
        AccessToken token = credential.GetToken(
            new TokenRequestContext(scopes, tenantId: tenantId),
            cancellationToken
        );

        return new OidcAccessToken(token.Token, token.ExpiresOn - DateTimeOffset.UtcNow);
    }

    public async Task<OidcAccessToken> GetOidcAccessTokenAsync(OidcCallbackParameters parameters, CancellationToken cancellationToken)
    {
        AccessToken token = await credential.GetTokenAsync(
            new TokenRequestContext(scopes, parentRequestId: null, tenantId: tenantId),
            cancellationToken
        );

        return new OidcAccessToken(token.Token, token.ExpiresOn - DateTimeOffset.UtcNow);
    }
}

Contenuti correlati

  • Last updated on