Utiliser l’accès en fonction du rôle du plan de contrôle avec Azure Cosmos DB for Table (préversion)

Article
10/27/2024

S’APPLIQUE À : Table

Diagramme de l’emplacement actuel (« Contrôle d’accès en fonction du rôle ») dans la séquence du guide de déploiement.

Cet article décrit les étapes d’octroi d’un accès d’identité pour gérer les données dans un compte Azure Cosmos DB for Table. Les étapes décrites dans cet article couvrent uniquement l’accès au plan de données pour effectuer des opérations sur des éléments individuels et exécuter des requêtes.

Prérequis

Compte Azure avec un abonnement actif. Créez un compte gratuitement.
Un compte Azure Cosmos DB for Table existant.
Une ou plusieurs identités existantes dans Microsoft Entra ID.

Utilisez l’environnement Bash dans Azure Cloud Shell. Pour plus d’informations, consultez Démarrage rapide pour Bash dans Azure Cloud Shell.
Si vous préférez exécuter les commandes de référence de l’interface de ligne de commande localement, installez l’interface Azure CLI. Si vous exécutez sur Windows ou macOS, envisagez d’exécuter Azure CLI dans un conteneur Docker. Pour plus d’informations, consultez Guide pratique pour exécuter Azure CLI dans un conteneur Docker.
- Si vous utilisez une installation locale, connectez-vous à Azure CLI à l’aide de la commande az login. Pour finir le processus d’authentification, suivez les étapes affichées dans votre terminal. Pour connaître les autres options de connexion, consultez Se connecter avec Azure CLI.
- Lorsque vous y êtes invité, installez l’extension Azure CLI lors de la première utilisation. Pour plus d’informations sur les extensions, consultez Utiliser des extensions avec Azure CLI.
- Exécutez az version pour rechercher la version et les bibliothèques dépendantes installées. Pour effectuer une mise à niveau vers la dernière version, exécutez az upgrade.

Préparer la définition de rôle

Tout d’abord, vous devez préparer une définition de rôle avec une liste de dataActions pour accorder l’accès à la lecture, à la requête et à la gestion des données dans Azure Cosmos DB for Table.

Définition intégrée
Définition personnalisée

Tout d’abord, obtenez l’identificateur de ressource du compte Azure Cosmos DB pour Table existant à l’aide de az cosmsodb show et stockez-le dans une variable. Ensuite, répertoriez toutes les définitions de rôle associées à votre compte Azure Cosmos DB for Table à l’aide de az rest. Finalement, passez en revue la sortie et recherchez la définition de rôle nommée Contributeur de données intégré Cosmos DB. La sortie contient l’identificateur unique de la définition de rôle dans la propriété id. Enregistrez cette valeur, car vous devrez l’utiliser dans l’étape d’affectation plus loin dans ce guide.

resourceId=$( \
    az cosmosdb show \
        --resource-group "<name-of-existing-resource-group>" \
        --name "<name-of-existing-table-account>" \
        --query "id" \
        --output tsv \
)

az rest \
    --method "GET" \
    --url $resourceId/tableRoleDefinitions?api-version=2023-04-15

[
  ...,
  {
    "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/msdocs-identity-example/providers/Microsoft.DocumentDB/databaseAccounts/msdocs-identity-example-nosql/tableRoleDefinitions/00000000-0000-0000-0000-000000000002",
    "name": "00000000-0000-0000-0000-000000000002",
    "properties": {
      "assignableScopes": [
        "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/msdocs-identity-example/providers/Microsoft.DocumentDB/databaseAccounts/msdocs-identity-example-nosql"
      ],
      "permissions": [
        {
          "dataActions": [
            "Microsoft.DocumentDB/databaseAccounts/readMetadata",
            "Microsoft.DocumentDB/databaseAccounts/tables/*",
            "Microsoft.DocumentDB/databaseAccounts/tables/containers/entities/*"
          ],
          "notDataActions": []
        }
      ],
      "roleName": "Cosmos DB Built-in Data Contributor",
      "type": "BuiltInRole"
    },
    "type": "Microsoft.DocumentDB/databaseAccounts/tableRoleDefinitions"
  }
  ...
]

Remarque

Pour cet exemple, la valeur id serait /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/msdocs-identity-example/providers/Microsoft.DocumentDB/databaseAccounts/msdocs-identity-example-nosql/tableRoleDefinitions/00000000-0000-0000-0000-000000000002. Cet exemple utilise des données fictives et votre identificateur sera distinct de cet exemple. La sortie de cet exemple est tronquée.

Utilisez Get-AzCosmosDBAccount pour obtenir l'identifiant de ressource du compte Azure Cosmos DB for Table existant et de le stocker dans une variable. Ensuite, utilisez Invoke-AzRestMethod pour répertorier toutes les définitions de rôle associées à votre compte Azure Cosmos DB for Table. Passez en revue la sortie et recherchez la définition de rôle nommée Contributeur de données intégré Cosmos DB. La sortie contient l’identificateur unique de la définition de rôle dans la propriété Id. Enregistrez cette valeur, car vous devrez l’utiliser dans l’étape d’affectation plus loin dans ce guide.

$parameters = @{
    ResourceGroupName = "<name-of-existing-resource-group>"
    Name = "<name-of-existing-table-account>"
}
$resourceId = (
    Get-AzCosmosDBAccount @parameters |
        Select-Object -Property Id -First 1
).Id

$parameters = @{
  Path = "$resourceId/tableRoleDefinitions?api-version=2023-04-15"
  Method = "GET"
}
Invoke-AzRestMethod @parameters

StatusCode : 200
Content    : {
               "value": [
                ...,
                {
                  "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/msdocs-identity-example/providers/Microsoft.DocumentDB/databaseAccounts/msdocs-identity-example-nosql/tableRoleDefinitions/00000000-0000-0000-0000-000000000002",
                  "name": "00000000-0000-0000-0000-000000000002",
                  "properties": {
                    "assignableScopes": [
                      "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/msdocs-identity-example/providers/Microsoft.DocumentDB/databaseAccounts/msdocs-identity-example-nosql"
                    ],
                    "permissions": [
                      {
                        "dataActions": [
                          "Microsoft.DocumentDB/databaseAccounts/readMetadata",
                          "Microsoft.DocumentDB/databaseAccounts/tables/*",
                          "Microsoft.DocumentDB/databaseAccounts/tables/containers/entities/*"
                        ],
                        "notDataActions": []
                      }
                    ],
                    "roleName": "Cosmos DB Built-in Data Contributor",
                    "type": "BuiltInRole"
                  },
                  "type": "Microsoft.DocumentDB/databaseAccounts/tableRoleDefinitions"
                }
                ...
               ]
             }
...

Remarque

Pour cet exemple, la valeur Id serait /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/msdocs-identity-example/providers/Microsoft.DocumentDB/databaseAccounts/msdocs-identity-example-nosql/tableRoleDefinitions/00000000-0000-0000-0000-000000000002. Cet exemple utilise des données fictives et votre identificateur sera distinct de cet exemple. La sortie de cet exemple est tronquée.

Créez un fichier JSON nommé role-definition.json. Dans ce fichier, créez une définition de ressource spécifiant les actions de données répertoriées ici :

	Description
`Microsoft.DocumentDB/databaseAccounts/readMetadata`	Peut lire les métadonnées au niveau du compte
*`Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/`**	Peut effectuer n’importe quelle opération de données au niveau du conteneur
*`Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/`**	Peut effectuer n’importe quelle opération sur des éléments avec des conteneurs

{
  "properties": {
    "roleName": "Azure Cosmos DB for Table Data Plane Owner",
    "type": "CustomRole",
    "assignableScopes": [
      "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/sidandrews-rbac/providers/Microsoft.DocumentDB/databaseAccounts/sidandrews-rbac-table/"
    ],
    "permissions": [
      {
        "dataActions": [
          "Microsoft.DocumentDB/databaseAccounts/readMetadata",
          "Microsoft.DocumentDB/databaseAccounts/tables/*",
          "Microsoft.DocumentDB/databaseAccounts/tables/containers/entities/*"
        ]
      }
    ]
  }
}

Créez ou mettez à jour une définition de rôle à l’aide de az cosmosdb show et az rest ensemble pour émettre une requête HTTP PUT. Dans le cadre de cette requête, spécifiez un GUID unique pour votre définition de rôle.
```
resourceId=$( \
    az cosmosdb show \
        --resource-group "<name-of-existing-resource-group>" \
        --name "<name-of-existing-table-account>" \
        --query "id" \
        --output tsv \
)

az rest \
    --method "PUT" \
    --url $resourceId/tableRoleDefinitions/d3d3d3d3-eeee-ffff-aaaa-b4b4b4b4b4b4?api-version=2023-04-15 \
    --body @role-definition.json
```
Remarque

Dans cet exemple, le GUID unique spécifié était d3d3d3d3-eeee-ffff-aaaa-b4b4b4b4b4b4. Vous pouvez spécifier n’importe quel GUID unique pour votre propre définition de rôle.
La sortie doit maintenant indiquer que la requête est mise en file d’attente. À présent, attendez que le déploiement de la définition de rôle en file d’attente se termine. Cette tâche peut prendre quelques minutes.
```
{
  "status": "Enqueued"
}
```

Enfin, vérifiez la liste des définitions de rôle à l’aide de az rest à nouveau.

resourceId=$( \
    az cosmosdb show \
        --resource-group "<name-of-existing-resource-group>" \
        --name "<name-of-existing-table-account>" \
        --query "id" \
        --output tsv \
)

az rest \
    --method "GET" \
    --url $resourceId/tableRoleDefinitions?api-version=2023-04-15

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

	Description
`Microsoft.DocumentDB/databaseAccounts/readMetadata`
*`Microsoft.DocumentDB/databaseAccounts/tables/`**
*`Microsoft.DocumentDB/databaseAccounts/tables/containers/entities/`**

metadata description = 'Create RBAC definition for data plane access to Azure Cosmos DB for Table.'

@description('Name of the Azure Cosmos DB for Table account.')
param accountName string

@description('Name of the role definition.')
param roleDefinitionName string = 'API for Table Data Plane Owner'

resource account 'Microsoft.DocumentDB/databaseAccounts@2023-04-15' existing = {
  name: accountName
}

resource definition 'Microsoft.DocumentDB/databaseAccounts/tableRoleDefinitions@2023-04-15' = {
  name: guid('table-role-definition', account.id)
  parent: account
  properties: {
    roleName: roleDefinitionName
    type: 'CustomRole'
    assignableScopes: [
      account.id
    ]
    permissions: [
      {
        dataActions: [
          'Microsoft.DocumentDB/databaseAccounts/readMetadata'
          'Microsoft.DocumentDB/databaseAccounts/tables/*'
          'Microsoft.DocumentDB/databaseAccounts/tables/containers/entities/*'
        ]
      }
    ]
  }
}

output definitionId string = definition.id

Créez un nouveau fichier de paramètres Bicep nommé data-plane-role-definition.bicepparam. Dans ce fichier de paramètres, attribuez le nom de votre compte Azure Cosmos DB for Table existant au paramètre accountName.
```
using './data-plane-role-definition.bicep'

param accountName = '<name-of-existing-table-account>'
```

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

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

Examinez la sortie du déploiement. La sortie contient l’identificateur unique de la définition de rôle dans la propriété properties.outputs.definitionId.value. Enregistrez cette valeur, car vous devrez l’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.DocumentDB/databaseAccounts/msdocs-identity-example-table-account/tableRoleDefinitions/dddddddd-9999-0000-1111-eeeeeeeeeeee"
      }
    }
  }
}
```
Remarque

Pour cet exemple, la valeur id serait /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/msdocs-identity-example/providers/Microsoft.DocumentDB/databaseAccounts/msdocs-identity-example-table-account/tableRoleDefinitions/dddddddd-9999-0000-1111-eeeeeeeeeeee. Cet exemple utilise des données fictives et votre identificateur serait distinct de cet exemple. Il s’agit d’un sous-ensemble de la sortie JSON classique du déploiement, pour plus de clarté.

Créez ou mettez à jour une définition de votre rôle à l’aide de Get-AzCosmosDBAccount et Invoke-AzRestMethod ensemble pour émettre une requête HTTP PUT. Également, dans le cadre de cette requête, spécifiez un GUID unique pour votre définition de rôle. Enfin, créez une charge utile de définition de ressource spécifiant les actions de données répertoriées ici :

	Description
`Microsoft.DocumentDB/databaseAccounts/readMetadata`	Peut lire les métadonnées au niveau du compte
*`Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/`**	Peut effectuer n’importe quelle opération de données au niveau du conteneur
*`Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/`**	Peut effectuer n’importe quelle opération sur des éléments avec des conteneurs

$parameters = @{
    ResourceGroupName = "<name-of-existing-resource-group>"
    Name = "<name-of-existing-table-account>"
}
$resourceId = (
    Get-AzCosmosDBAccount @parameters |
        Select-Object -Property Id -First 1
).Id

$payload = @{
  properties = @{
    roleName = "Azure Cosmos DB for Table Data Plane Owner"
    type = "CustomRole"
    assignableScopes = @(
      "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/sidandrews-rbac/providers/Microsoft.DocumentDB/databaseAccounts/sidandrews-rbac-table/"
    )
    permissions = @(
      @{
        dataActions = @(
          "Microsoft.DocumentDB/databaseAccounts/readMetadata",
          "Microsoft.DocumentDB/databaseAccounts/tables/*",
          "Microsoft.DocumentDB/databaseAccounts/tables/containers/entities/*"
        )
      }
    )
  }
}

$parameters = @{
  Path = "$resourceId/tableRoleDefinitions/d3d3d3d3-eeee-ffff-aaaa-b4b4b4b4b4b4?api-version=2023-04-15"
  Method = "PUT"
  Payload = $payload | ConvertTo-Json -Depth 4
}
Invoke-AzRestMethod @parameters

Remarque

Dans cet exemple, le GUID unique spécifié était d3d3d3d3-eeee-ffff-aaaa-b4b4b4b4b4b4. Vous pouvez spécifier n’importe quel GUID unique pour votre propre définition de rôle.

La sortie doit renvoyer un code de statut de 200. À présent, attendez que le déploiement de la définition de rôle en file d’attente se termine. Cette tâche peut prendre quelques minutes.
```
StatusCode : 200
...
```

Enfin, vérifiez la liste des définitions de rôle à l’aide de Invoke-AzRestMethod à nouveau.

$parameters = @{
    ResourceGroupName = "<name-of-existing-resource-group>"
    Name = "<name-of-existing-table-account>"
}
$resourceId = (
    Get-AzCosmosDBAccount @parameters |
        Select-Object -Property Id -First 1
).Id

$parameters = @{
  Path = "$resourceId/tableRoleDefinitions?api-version=2023-04-15"
  Method = "GET"
}
Invoke-AzRestMethod @parameters

Attribuer un rôle à l’identité

À présent, affectez le rôle nouvellement défini à une identité afin que vos applications puissent accéder aux données dans Azure Cosmos DB for Table.

Important

Cette tâche d’attribution nécessite que vous disposiez de l’identificateur unique de l’identité à laquelle vous souhaitez accorder des autorisations de contrôle d’accès en fonction du rôle. Si vous n’avez pas d’identificateur unique pour une identité, suivez les instructions de la créer une identité managée ou obtenir des guides d’identité de connexion.

Utilisez az cosmosdb show pour obtenir l’identificateur unique de votre compte actuel.

az cosmosdb show \
    --resource-group "<name-of-existing-resource-group>" \
    --name "<name-of-existing-resource-group>" \
    --query "{id:id}"

Observez la sortie de la commande précédente. Enregistrez la valeur de la propriété id pour ce compte, car il est nécessaire d’utiliser à l’étape suivante.
```
{
  "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/msdocs-identity-example/providers/Microsoft.DocumentDB/databaseAccounts/msdocs-identity-example-nosql"
}
```
Remarque

Pour cet exemple, la valeur id serait /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/msdocs-identity-example/providers/Microsoft.DocumentDB/databaseAccounts/msdocs-identity-example-nosql. Cet exemple utilise des données fictives et votre identificateur sera distinct de cet exemple.
Créez un fichier JSON nommé role-assignment.json. Dans le fichier JSON, ajoutez l’identificateur unique de votre identité et identificateur unique pour la ressource de compte.
```
{
  "properties": {
    "roleDefinitionId": "<account-resource-id>/tableRoleDefinitions/d3d3d3d3-eeee-ffff-aaaa-b4b4b4b4b4b4",
    "scope": "<account-resource-id>",
    "principalId": "<id-of-existing-identity>"
  }
}
```
Remarque

Dans cet exemple, le GUID unique spécifié était d3d3d3d3-eeee-ffff-aaaa-b4b4b4b4b4b4. Vous pouvez utiliser le GUID unique que vous avez utilisé précédemment pour votre propre définition de rôle.
Créez ou mettez à jour une attribution de rôle à l’aide de az cosmosdb show et az rest ensemble pour émettre une requête HTTP PUT. Dans le cadre de cette requête, spécifiez un GUID unique pour votre attribution de rôle.
```
resourceId=$( \
    az cosmosdb show \
        --resource-group "<name-of-existing-resource-group>" \
        --name "<name-of-existing-table-account>" \
        --query "id" \
        --output tsv \
)

az rest \
    --method "PUT" \
    --url $resourceId/tableRoleAssignments/e4e4e4e4-ffff-aaaa-bbbb-c5c5c5c5c5c5?api-version=2023-04-15 \
    --body @role-assignment.json
```
Remarque

Dans cet exemple, le GUID unique spécifié était e4e4e4e4-ffff-aaaa-bbbb-c5c5c5c5c5c5. Vous pouvez spécifier n’importe quel GUID unique pour votre propre attribution de rôle.

Créez un autre fichier Bicep pour attribuer un rôle à une identité. Nommez ce fichier data-plane-role-assignment.bicep.

metadata description = 'Assign RBAC role for data plane access to Azure Cosmos DB for Table.'

@description('Name of the Azure Cosmos DB for Table account.')
param accountName string

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

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

resource account 'Microsoft.DocumentDB/databaseAccounts@2023-04-15' existing = {
  name: accountName
}

resource assignment 'Microsoft.DocumentDB/databaseAccounts/tableRoleAssignments@2023-04-15' = {
  name: guid(roleDefinitionId, identityId, account.id)
  parent: account
  properties: {
    principalId: identityId
    roleDefinitionId: roleDefinitionId
    scope: account.id
  }
}

output id string = assignment.id

Créez un nouveau fichier de paramètres Bicep nommé data-plane-role-assignment.bicepparam. Dans ce fichier de paramètres, affectez le nom de votre compte Azure Cosmos DB for Table existant au paramètre accountName , les identificateurs de définition de rôle précédemment enregistrés au paramètre roleDefinitionId et l’identificateur unique de votre identité au paramètre identityId.
```
using './data-plane-role-assignment.bicep'

param accountName = '<name-of-existing-table-account>'
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 data-plane-role-assignment.bicepparam \
    --template-file data-plane-role-assignment.bicep

Répétez ces étapes pour accorder l’accès au compte à partir d’autres identités que vous souhaitez utiliser.

Conseil

Vous pouvez répéter ces étapes pour autant d’identités que vous le souhaitez. En règle générale, ces étapes sont au moins répétées pour permettre aux développeurs d’accéder à un compte à l’aide de leur identité humaine et pour accorder aux applications l’accès à l’aide d’une identité managée.

Utilisez `Get-AzCosmosDBAccount pour obtenir l’identificateur unique de votre compte actuel.

$parameters = @{
    ResourceGroupName = "<name-of-existing-resource-group>"
    Name = "<name-of-existing-nosql-account>"
}
Get-AzCosmosDBAccount @parameters | Select -Property Id

Observez la sortie de la commande précédente. Enregistrez la valeur de la propriété Id pour ce compte, car il est nécessaire d’utiliser à l’étape suivante.
```
Id
--    
/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/msdocs-identity-example/providers/Microsoft.DocumentDB/databaseAccounts/msdocs-identity-example-nosql
```
Remarque

Pour cet exemple, la valeur Id serait /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/msdocs-identity-example/providers/Microsoft.DocumentDB/databaseAccounts/msdocs-identity-example-nosql. Cet exemple utilise des données fictives et votre identificateur sera distinct de cet exemple.

Créez ou mettez à jour une attribution de rôle à l’aide de Get-AzCosmosDBAccount et Invoke-AzRestMethod ensemble pour émettre une requête HTTP PUT. Dans le cadre de cette requête, spécifiez un GUID unique pour votre attribution de rôle. Enfin, créez une charge utile d’affectation de ressource en spécifiant l’identificateur unique de votre identité.

$parameters = @{
    ResourceGroupName = "<name-of-existing-resource-group>"
    Name = "<name-of-existing-table-account>"
}
$resourceId = (
    Get-AzCosmosDBAccount @parameters |
        Select-Object -Property Id -First 1
).Id    

$payload = @{
  properties = @{
    roleDefinitionId = "$resourceId/tableRoleDefinitions/00000000-0000-0000-0000-000000000002"
    scope = "$resourceId"
    principalId = "<id-of-existing-identity>"
  }
}

$parameters = @{
  Path = "$resourceId/tableRoleAssignments/e4e4e4e4-ffff-aaaa-bbbb-c5c5c5c5c5c5?api-version=2023-04-15"
  Method = "PUT"
  Payload = $payload | ConvertTo-Json -Depth 2
}
Invoke-AzRestMethod @parameters

Remarque

Dans cet exemple, le GUID unique spécifié était e4e4e4e4-ffff-aaaa-bbbb-c5c5c5c5c5c5. Vous pouvez spécifier n’importe quel GUID unique pour votre propre attribution de rôle.

Valider l’accès au plan de données dans le code

Enfin, vérifiez que vous avez correctement accordé l’accès à l’aide du code d’application et du Kit de développement logiciel (SDK) Azure dans votre langage de programmation préféré.

using Azure.Identity;
using Azure.Data.Tables;

string endpoint = "<account-endpoint>";

DefaultAzureCredential credential = new();

TableServiceClient client = new(
    endpoint: new Uri(endpoint),
    tokenCredential: credential
);

TableClient table = client.GetTableClient(
    tableName: "<name-of-table>"
);

Important

Cet exemple de code utilise les bibliothèques Azure.Data.Tables et Azure.Identity de NuGet.

const { TableServiceClient, TableClient } = require('@azure/data-tables');
const { DefaultAzureCredential } = require('@azure/identity');

const endpoint = '<account-endpoint>';

let credential = new DefaultAzureCredential();

let client = new TableServiceClient(endpoint, credential);

let table = new TableClient(endpoint, "<table-name>", credential);

Important

Cet exemple de code utilise les packages @azure/data-tables et @azure/identity à partir de npm.

import { TableServiceClient, TableClient } from '@azure/data-tables';
import { TokenCredential, DefaultAzureCredential } from '@azure/identity';

const endpoint: string = '<account-endpoint>';

let credential: TokenCredential = new DefaultAzureCredential();

let client: TableServiceClient = new TableServiceClient(endpoint, credential);

let table: TableClient = new TableClient(endpoint, "<table-name>", credential);

Important

Cet exemple de code utilise les packages @azure/data-tables et @azure/identity à partir de npm.

from azure.data.tables import TableServiceClient, TableClient
from azure.identity import DefaultAzureCredential

endpoint = "<account-endpoint>"

credential = DefaultAzureCredential()

client = TableServiceClient(endpoint, credential=credential)

table = client.get_table_client("<table-name>")

Important

Cet exemple de code utilise les packages azure-data-tables et azure-identity à partir de PyPI.

package main

import (
    "github.com/Azure/azure-sdk-for-go/sdk/azidentity"
    "github.com/Azure/azure-sdk-for-go/sdk/data/aztables"
)

const endpoint = "<account-endpoint>"

func main() {
    credential, _ := azidentity.NewDefaultAzureCredential(nil)
    client, _ := aztables.NewServiceClient(endpoint, credential, nil)
    table, _ := client.NewClient("<table-name>")
}

Important

Cet exemple de code utilise les packages azure/azure-sdk-for-go/sdk/data/aztables et azure/azure-sdk-for-go/sdk/azidentity à partir de Go.

import com.azure.data.tables.TableClient;
import com.azure.data.tables.TableServiceClient;
import com.azure.data.tables.TableServiceClientBuilder;
import com.azure.identity.DefaultAzureCredential;
import com.azure.identity.DefaultAzureCredentialBuilder;

public class Table{
    public static void main(String[] args){
        DefaultAzureCredential credential = new DefaultAzureCredentialBuilder()
            .build();
        
        TableServiceClient client = new TableServiceClientBuilder()
            .endpoint("<nosql-endpoint>")
            .credential(credential)
            .buildClient();

        TableClient table = client
            .getTableClient("<table-name>");
    }
}

Important

Cet exemple de code utilise les packages com.azure/azure-data-tables et com.azure/azure-identity de Maven.

Avertissement

Si vous utilisez une identité managée affectée par l’utilisateur(-trice), vous devez spécifier l’identificateur unique de l’identité managée dans le cadre de la création de l’objet d’informations d’identification.

Partager via

Utiliser l’accès en fonction du rôle du plan de contrôle avec Azure Cosmos DB for Table (préversion)

Prérequis

Préparer la définition de rôle

Attribuer un rôle à l’identité

Valider l’accès au plan de données dans le code

Commentaires

Ressources supplémentaires