Autoriser l’accès au principal de service à Azure Databricks avec OAuth

Autoriser l'accès d'un principal de service aux ressources Azure Databricks avec OAuth. Utilisez l’authentification machine-à-machine (M2M) pour les processus non surveillés, tels que les commandes automatisées de CLI ou les appels API REST depuis des scripts ou des applications. Ces processus peuvent utiliser une authentification unifiée ou demander manuellement des jetons d’accès. Utilisez OAuth on-behalf-of (OBO) pour agir en tant que principal de service de manière interactive, sans secret OAuth.

Azure Databricks utilise OAuth 2.0 comme protocole préféré pour l’autorisation et l’authentification du principal de service en dehors de l’interface utilisateur. L’authentification client unifiée automatise la génération et l’actualisation des jetons. Lorsqu’un principal de service se connecte et reçoit son consentement, OAuth émet un jeton d’accès pour l’interface CLI, le SDK ou un autre outil à utiliser pour son compte. Chaque jeton d’accès est valide pendant une heure, après quoi un nouveau jeton est automatiquement demandé.

Sur cette page, l’autorisation fait référence à l’utilisation d’OAuth pour accorder à un principal de service l’accès aux ressources Azure Databricks, tandis que l’authentification fait référence à la validation des identifiants via des jetons d’accès.

Pour plus d’informations générales, consultez Autoriser l’accès aux ressources Azure Databricks.

Méthodes d’autorisation d’un principal de service

Azure Databricks prend en charge les méthodes suivantes pour autoriser un principal de service :

• OAuth machine-à-machine (M2M) avec un secret client : Utilisez-le pour des charges de travail non surveillées. Voir Autoriser avec OAuth M2M en utilisant un identifiant client et un secret. Vous pouvez vous authentifier de l’une des manières suivantes :

  • Automatique (recommandé) : Utilisez l’authentification unifiée avec les outils et kits SDK pris en charge, tels que le Kit de développement logiciel (SDK) Terraform Azure Databricks. Cette approche gère automatiquement la génération et l’actualisation des jetons, et est idéale pour l’automatisation ou d’autres charges de travail sans assistance.
  • Manuel : Échangez l'ID client et le secret du principal de service contre un jeton d'accès en utilisant le flux d’octroi des informations d’identification du client OAuth. Utilisez cette méthode si votre outil ou API ne prend pas en charge l’authentification unifiée. Vous devrez peut-être créer votre propre mécanisme d’actualisation de jeton pour votre application. Pour plus d’informations, consultez Générer manuellement des jetons d’accès OAuth M2M.

• OAuth on-behalf-of (OBO) : Agir comme un principal de service que vous gérez via le flux OAuth standard utilisateur-machine (U2M), sans secret OAuth. Utilisez cela pour un accès interactif lorsqu’une personne pilote la session. Voir comment s’authentifier en tant que principal de service avec OAuth OBO.

Prerequisites

Avant de configurer OAuth, procédez comme suit :

1. Créer un principal de service Azure Databricks. Voir Ajouter des entités de service à votre compte.
2. Accédez à l’onglet Configuration du principal de service et sélectionnez les droits dont il doit disposer pour cet espace de travail.
3. Accédez à l’onglet Autorisations et accordez l’accès à tous les utilisateurs, principaux de service et groupes Azure Databricks que vous souhaitez gérer et utiliser ce principal de service. Voir Qui peut gérer et utiliser des entités de service ?.

S’authentifier en tant que principal du service à l’aide d’OAuth OBO

OAuth on-behalf-of (OBO) permet à un client OAuth, tel que la CLI Databricks, d’agir avec une identité déléguée. Avec OBO, lorsque vous autorisez un client via le flux OAuth standard utilisateur-à-machine (U2M), vous pouvez déléguer un principal de service que vous gérez à la place de votre propre identité utilisateur.

Requirements

• Vous avez le rôle Service Principal Manager sur le principal de service avec lequel vous souhaitez vous authentifier. Si vous avez créé le principal de service, vous disposez automatiquement de ce rôle. Consultez Rôles pour la gestion des principaux de service.
• Un administrateur d’espace de travail a activé U2M pour le Service Principal depuis la page Previews. Consultez Gérer les préversions d’Azure Databricks.

Authentification comme principal de service

1. Lancez le flux U2M standard. L’exemple suivant utilise l’interface CLI Databricks :

   databricks auth login --host <workspace-url>
   

2. Une fenêtre de navigateur s’ouvre pour l’autorisation. Dans la liste déroulante, sélectionnez le principal de service avec lequel s’authentifier, puis autorisez l’application.

3. Le jeton OAuth est émis avec l’identité du principal de service. La sub revendication dans le jeton correspond au principal de service sélectionné. Pour afficher le jeton, exécutez :

   databricks auth token --host <workspace-url>
   

Ce flux fonctionne avec n’importe quelle application prenant en charge l’authentification U2M standard. Pour connaître les étapes complètes, consultez l’autorisation automatique avec l’authentification unifiée ou générer manuellement des jetons d’accès U2M OAuth.

Autoriser avec OAuth M2M en utilisant un identifiant client et un secret

Pour les charges de travail unattended telles que l’automatisation, les scripts et le CI/CD, créez un secret OAuth pour le principal de service et échangez-le contre des jetons d’accès de courte durée en utilisant le flux d’informations d’identification client (M2M).

Étape 1 : Créer un secret OAuth

Pour autoriser l’accès à vos ressources Azure Databricks avec OAuth, vous devez créer un secret OAuth. Le secret est utilisé pour générer des jetons d’accès OAuth pour l’authentification. Un principal de service peut avoir jusqu’à cinq secrets OAuth, et chaque secret peut être valide pendant jusqu’à deux ans. Azure Databricks supprime automatiquement un secret OAuth après 90 jours sans utilisation.

Les administrateurs de compte et les administrateurs d’espace de travail peuvent créer un secret OAuth pour un principal de service.

1. Cliquez sur votre nom d’utilisateur dans la barre supérieure, puis sélectionnez Paramètres.
2. Cliquez sur l’onglet Identité et accès .
3. À côté de Principaux de service, cliquez sur Gérer.
4. Sélectionnez le principal de service.
5. Cliquez sur l’onglet Secrets.
6. Cliquez sur Générer un secret.
7. Définissez la durée de vie du secret en jours (730 jours maximum).
8. Dans Scopes, sélectionnez les scopes API que le secret peut utiliser. Pour restreindre le secret, recherchez et sélectionnez une ou plusieurs étendues, par exemple sql ou jobs. Pour permettre au secret d’accéder à toutes les API auxquelles le principal de service est autorisé à accéder, sélectionnez toutes les API (déconseillé). Voir les secrets OAuth à portée limitée.
9. Cliquez sur Générer.
10. Copiez le secret affiché et l’ID client, puis cliquez sur Terminé. Le secret n’est affiché qu’une seule fois. L’ID client est identique à l’ID d’application du principal de service.

Les administrateurs de compte peuvent également créer un secret OAuth à partir de la console de compte. Sous l’onglet Gestion des utilisateurs , sélectionnez le principal de service, puis accédez à l’onglet Informations d’identification et secrets .

Secrets OAuth étendus

Par défaut, un secret OAuth peut accéder à toutes les API pour lesquelles le principal de service est autorisé (all-apis). Un secret à portée restreint l’accès à un ensemble spécifique de champs d’API, tels que sql, jobs, ou unity-catalog. Un jeton d’accès OAuth généré à partir d’un secret avec des portées définies ne peut pas dépasser les portées du secret, ce qui limite l’impact si le secret est divulgué ou utilisé à mauvais escient. Databricks recommande d’associer chaque secret uniquement aux portées nécessaires à son intégration.

Un secret créé sans périmètre, qui inclut tous les secrets existants, conserve l’accès all-apis et se comporte comme avant.

Les autorisations sont définies lorsque vous générez le secret et ne peuvent pas être modifiées par la suite. Pour utiliser différents télescopes, générez un nouveau secret. Dans la table Secrets , cliquez sur Cloner sur un secret existant pour en créer un nouveau avec les mêmes amplitudes et durée de vie.

Pour la liste complète des périmètres et des opérations API que chacun couvre, voir les champs d’application des API.

Étape 2 : Utiliser l’autorisation OAuth

Pour utiliser l’autorisation OAuth avec l’outil d’authentification unifiée, vous devez définir les variables d’environnement associées, .databrickscfg fields, champs Terraform ou Config fields suivants :

• L’hôte Azure Databricks, spécifié comme https://accounts.azuredatabricks.net pour les opérations de compte ou l’URL par espace de travail cible, par exemple https://adb-1234567890123456.7.azuredatabricks.net, pour les opérations d’espace de travail.
• L'ID de compte Azure Databricks, pour les opérations de compte Azure Databricks.
• ID de client du principal du service.
• Secret du principal du service.

Pour effectuer l’authentification du principal du service OAuth, intégrez les éléments suivants dans votre code, en fonction de l’outil ou du SDK participant :

Environnement

Pour utiliser des variables d’environnement pour un type d’authentification Azure Databricks spécifique avec un outil ou un SDK, consultez Autoriser l’accès aux ressources Azure Databricks ou à la documentation de l’outil ou du SDK. Consultez également les variables et champs d’environnement pour l’authentification unifiée et la priorité de la méthode d’authentification.

Pour les opérations au niveau du compte, définissez les variables d’environnement suivantes :

• DATABRICKS_HOST, défini sur la valeur de votre URL de console de compte Azure Databricks. https://accounts.azuredatabricks.net
• DATABRICKS_ACCOUNT_ID
• DATABRICKS_CLIENT_ID
• DATABRICKS_CLIENT_SECRET

Pour les opérations au niveau de l’espace de travail, définissez les variables d’environnement suivantes :

• DATABRICKS_HOST, défini sur la valeur de votre URL Azure Databricks par espace de travail, par exemple https://adb-1234567890123456.7.azuredatabricks.net.
• DATABRICKS_CLIENT_ID
• DATABRICKS_CLIENT_SECRET

Profil

Créez ou identifiez un profil de configuration Azure Databricks avec les champs suivants dans votre fichier .databrickscfg. Si vous créez le profil, remplacez les espaces réservés par les valeurs appropriées. Pour utiliser le profil avec un outil ou un Kit de développement logiciel (SDK), consultez Autoriser l’accès aux ressources Azure Databricks ou à la documentation de l’outil ou du SDK. Consultez également les variables et champs d’environnement pour l’authentification unifiée et la priorité de la méthode d’authentification.

Pour les opérations au niveau du compte, définissez les valeurs suivantes dans votre fichier .databrickscfg. Dans ce cas, l’URL de la console de compte Azure Databricks est https://accounts.azuredatabricks.net :

[<some-unique-configuration-profile-name>]
host          = <account-console-url>
account_id    = <account-id>
client_id     = <service-principal-client-id>
client_secret = <service-principal-secret>

Pour les opérations au niveau de l’espace de travail, définissez les valeurs suivantes dans votre fichier .databrickscfg. Dans ce cas, l'hôte est l'URL Azure Databricks par espace de travail, par exemple https://adb-1234567890123456.7.azuredatabricks.net :

[<some-unique-configuration-profile-name>]
host          = <workspace-url>
client_id     = <service-principal-client-id>
client_secret = <service-principal-secret>

Interface de ligne de commande

Pour l’interface CLI Databricks, effectuez l’une des opérations suivantes :

• Définissez les variables d’environnement comme spécifié sous l’onglet Environnement .
• Définissez les valeurs de votre .databrickscfg fichier comme spécifié sous l’onglet Profil .

Les variables d’environnement sont toujours prioritaires sur les valeurs de votre fichier .databrickscfg.

Consultez également Authentification machine à machine (M2M) OAuth.

Se connecter

Pour Databricks Connect, vous pouvez :

• Utilisez un profil de configuration : Définissez les valeurs au niveau de l’espace de travail dans votre .databrickscfg fichier, comme décrit sous l’onglet Profil . Définissez également l’URL cluster_id de votre instance d’espace de travail.
• Utilisez des variables d’environnement : Définissez les mêmes valeurs que celles affichées sous l’onglet Environnement . Définissez également l’URL DATABRICKS_CLUSTER_ID de votre instance d’espace de travail.

Les valeurs dans .databrickscfg prennent le pas sur les variables d’environnement.

Pour initialiser Databricks Connect avec ces paramètres, consultez Configuration de calcul pour Databricks Connect.

VS Code

Pour l’extension IDE Databricks, faites ce qui suit :

1. Configurez les valeurs dans votre fichier pour les opérations au niveau de l'espace de travail Azure Databricks , comme spécifié dans l'onglet Profil.
2. Dans le volet de configuration de l’extension IDE Databricks, cliquez sur Configurer Databricks.
3. Dans la palette de commandes, pour Hôte Databricks, entrez votre URL par espace de travail, par exemple https://adb-1234567890123456.7.azuredatabricks.net, puis appuyez sur Enter.
4. Dans la palette de commandes, sélectionnez le nom de votre profil cible dans la liste de votre URL.

Pour plus de détails, voir Configurer l’autorisation pour l’extension IDE Databricks.

Terraformation

Opérations au niveau du compte

Pour l’authentification par défaut :

provider "databricks" {
  alias = "accounts"
}

Pour une configuration directe :

provider "databricks" {
  alias         = "accounts"
  host          = <retrieve-account-console-url>
  account_id    = <retrieve-account-id>
  client_id     = <retrieve-client-id>
  client_secret = <retrieve-client-secret>
}

Remplacez les retrieve espaces réservés par votre propre implémentation pour récupérer des valeurs à partir de la console ou d’un autre magasin de configuration, tel que HashiCorp Vault. Consultez également le gestionnaire de coffres-forts. Dans ce cas, l’URL de la console de compte Azure Databricks est https://accounts.azuredatabricks.net.

Opérations au niveau de l’espace de travail

Pour la configuration par défaut :

provider "databricks" {
  alias = "workspace"
}

Pour une configuration directe :

provider "databricks" {
  alias         = "workspace"
  host          = <retrieve-workspace-url>
  client_id     = <retrieve-client-id>
  client_secret = <retrieve-client-secret>
}

Remplacez les retrieve espaces réservés par votre propre implémentation pour récupérer des valeurs à partir de la console ou d’un autre magasin de configuration, tel que HashiCorp Vault. Consultez également le gestionnaire de coffres-forts. Dans ce cas, l’hôte est l’URL d’Azure Databricks par espace de travail, par exemple https://adb-1234567890123456.7.azuredatabricks.net.

Pour plus d’informations sur l’authentification avec le fournisseur Databricks Terraform, consultez Authentification.

Python

Opérations au niveau du compte

Pour la configuration par défaut :

from databricks.sdk import AccountClient

a = AccountClient()
# ...

Pour une configuration directe :

from databricks.sdk import AccountClient

a = AccountClient(
  host          = retrieve_account_console_url(),
  account_id    = retrieve_account_id(),
  client_id     = retrieve_client_id(),
  client_secret = retrieve_client_secret()
)
# ...

Remplacez les retrieve espaces réservés par votre propre implémentation pour récupérer des valeurs à partir de la console ou d’un autre magasin de configuration, tel que Azure KeyVault. Dans ce cas, l’URL de la console de compte Azure Databricks est https://accounts.azuredatabricks.net.

Opérations au niveau de l’espace de travail

Pour la configuration par défaut :

from databricks.sdk import WorkspaceClient

w = WorkspaceClient()
# ...

Pour une configuration directe :

from databricks.sdk import WorkspaceClient

w = WorkspaceClient(
  host          = retrieve_workspace_url(),
  client_id     = retrieve_client_id(),
  client_secret = retrieve_client_secret()
)
# ...

Remplacez les retrieve espaces réservés par votre propre implémentation pour récupérer des valeurs à partir de la console, ou d’un autre magasin de configuration, tel que Azure KeyVault. Dans ce cas, l’hôte est l’URL d’Azure Databricks par espace de travail, par exemple https://adb-1234567890123456.7.azuredatabricks.net.

Pour plus d’informations sur l’authentification avec les outils et kits sdk Databricks qui utilisent Python et implémentent l’authentification unifiée, consultez :

• Configurer le client Databricks Connect pour Python
• Authentification du kit SDK Databricks pour Python avec un compte ou un espace de travail Azure Databricks

Java

Opérations au niveau de l’espace de travail

Pour la configuration par défaut :

import com.databricks.sdk.WorkspaceClient;
// ...
WorkspaceClient w = new WorkspaceClient();
// ...

Pour une configuration directe :

import com.databricks.sdk.WorkspaceClient;
import com.databricks.sdk.core.DatabricksConfig;
// ...
DatabricksConfig cfg = new DatabricksConfig()
  .setHost(retrieveWorkspaceUrl())
  .setClientId(retrieveClientId())
  .setClientSecret(retrieveClientSecret());
WorkspaceClient w = new WorkspaceClient(cfg);
// ...

Remplacez les retrieve espaces réservés par votre propre implémentation pour récupérer des valeurs à partir de la console, ou d’un autre magasin de configuration, tel que Azure KeyVault. Dans ce cas, l’hôte est l’URL d’Azure Databricks par espace de travail, par exemple https://adb-1234567890123456.7.azuredatabricks.net.

Pour plus d’informations sur l’authentification avec les outils et kits sdk Databricks qui utilisent Java et implémentent l’authentification unifiée, consultez :

• Configurer le client Databricks Connect pour Scala (le client Databricks Connect pour Scala utilise le kit de développement logiciel (SDK) Databricks inclus pour Java pour l’authentification)
• Authentifier le kit de développement logiciel (SDK) Databricks pour Java avec votre compte ou espace de travail Azure Databricks

Allez

Opérations au niveau du compte

Configuration par défaut :

import "github.com/databricks/databricks-sdk-go"

// Uses environment configuration automatically
a := databricks.Must(databricks.NewAccountClient())

Pour une configuration directe :

import (
  "github.com/databricks/databricks-sdk-go"
)
// ...
a := databricks.Must(databricks.NewAccountClient(&databricks.Config{
  Host:         retrieveWorkspaceUrl(),
  ClientId:     retrieveClientId(),
  ClientSecret: retrieveClientSecret(),
}))
// ...

Remplacez les retrieve espaces réservés par votre propre implémentation pour récupérer des valeurs à partir de la console, ou d’un autre magasin de configuration, tel que Azure KeyVault. Dans ce cas, l’URL de la console de compte Azure Databricks est https://accounts.azuredatabricks.net.

Opérations au niveau de l’espace de travail

Pour la configuration par défaut :

import "github.com/databricks/databricks-sdk-go"

// Uses environment configuration automatically
w := databricks.Must(databricks.NewWorkspaceClient())

Pour une configuration directe :

import "github.com/databricks/databricks-sdk-go"
// ...
w := databricks.Must(databricks.NewWorkspaceClient(&databricks.Config{
    Host:         retrieveAccountConsoleUrl(),
    ClientId:     retrieveClientId(),
    ClientSecret: retrieveClientSecret(),
}))
// ...

Remplacez les retrieve espaces réservés par votre propre implémentation pour récupérer des valeurs à partir de la console, ou d’un autre magasin de configuration, tel que Azure KeyVault. Dans ce cas, l’hôte est l’URL d’Azure Databricks par espace de travail, par exemple https://adb-1234567890123456.7.azuredatabricks.net.

Pour plus d’informations sur l’authentification avec les outils et les kits de développement logiciel (SDK) Databricks qui utilisent Go et qui implémentent l’Authentification unifiée du client Databricks, consultez Authentifier le kit de développement logiciel (SDK) Databricks pour Go avec votre compte ou votre espace de travail Azure Databricks.

Générer manuellement des jetons d’accès OAuth M2M

Cette section concerne les outils ou services qui ne prennent pas en charge l’authentification unifiée Databricks. Si vous devez générer, actualiser ou utiliser manuellement des jetons OAuth Azure Databricks pour l’authentification M2M, procédez comme suit.

Pour générer un jeton d’accès OAuth M2M, utilisez l’ID client et le secret OAuth du principal de service. Chaque jeton d’accès est valide pendant une heure. Une fois l’expiration terminée, demandez un nouveau jeton. Vous pouvez générer des jetons au niveau du compte ou de l’espace de travail :

• Niveau du compte : Permet d’appeler les API REST au niveau du compte et au niveau de l’espace de travail dans les comptes et les espaces de travail auxquels le principal de service peut accéder. Consultez Générer un jeton d’accès au niveau du compte.
• Niveau de l’espace de travail : Permet d’appeler des API REST au sein d’un seul espace de travail. Consultez Générer un jeton d’accès au niveau de l’espace de travail.

Générer un jeton d’accès au niveau du compte

Utilisez un jeton au niveau du compte pour appeler des API REST pour le compte et tous les espaces de travail auquel le principal de service peut accéder.

1. Recherchez votre ID de compte.

2. Construisez l’URL du point de terminaison de jeton en remplaçant <account-id> dans l’URL suivante par votre identifiant de compte.

   https://accounts.azuredatabricks.net/oidc/accounts/<my-account-id>/v1/token
   

3. Utilisez curl pour demander un jeton d'accès OAuth. Replace:

   • <token-endpoint-URL> en utilisant l’URL ci-dessus.
   • <client-id> avec l’ID client du principal de service (ID d’application).
   • <client-secret> avec le secret OAuth du principal de service.

   export CLIENT_ID=<client-id>
   export CLIENT_SECRET=<client-secret>
   
     curl --request POST \
     --url <token-endpoint-URL> \
     --user "$CLIENT_ID:$CLIENT_SECRET" \
     --data 'grant_type=client_credentials&scope=all-apis'
   

   Une réponse similaire à celle ci est générée :

   {
     "access_token": "eyJraWQiOiJkYTA4ZTVjZ…",
     "token_type": "Bearer",
     "expires_in": 3600
   }
   

   L’étendue all-apis demande un jeton d'accès OAuth qui permet à l'entité de service d'appeler n'importe quelle API REST Databricks à laquelle elle est autorisée à accéder.

4. Copiez la access_token valeur de la réponse.

Générer un jeton d’accès au niveau de l’espace de travail

Utilisez un jeton au niveau de l’espace de travail uniquement avec les API REST de cet espace de travail.

1. Construisez l'URL du point de terminaison en remplaçant <databricks-instance> par votre <databricks-instance>, avec le nom de l'instance de l'espace de travail Azure Databricks, par exemple adb-1234567890123456.7.azuredatabricks.net :

   https://<databricks-instance>/oidc/v1/token
   

2. Utilisez curl pour demander un jeton d'accès OAuth. Replace:

   • <token-endpoint-URL> en utilisant l’URL ci-dessus.
   • <client-id> avec l’ID client du principal de service (ID d’application).
   • <client-secret> avec le secret OAuth du principal de service.

   export CLIENT_ID=<client-id>
   export CLIENT_SECRET=<client-secret>
   
   curl --request POST \
   --url <token-endpoint-URL> \
   --user "$CLIENT_ID:$CLIENT_SECRET" \
   --data 'grant_type=client_credentials&scope=all-apis'
   

   Une réponse similaire à celle ci est générée :

   {
     "access_token": "eyJraWQiOiJkYTA4ZTVjZ…",
     "token_type": "Bearer",
     "expires_in": 3600
   }
   

3. Copiez la access_token valeur de la réponse.

Assumer un rôle

Un principal de service peut assumer un rôle lorsqu’il demande un jeton d’accès au niveau de l’espace de travail. Lorsqu’un principal de service endosse un rôle, les autorisations du rôle remplacent ses propres autorisations. Dans Azure Databricks, un rôle est implémenté en tant que groupe, et le principal de service doit avoir l’autorisation Assume sur ce groupe. Pour plus d’informations, consultez Contrôle d’accès en fonction du rôle (RBAC).

Pour assumer un rôle, ajoutez le assume_group paramètre à la demande de jeton :

export CLIENT_ID=<client-id>
export CLIENT_SECRET=<client-secret>

curl --request POST \
--url <token-endpoint-URL> \
--user "$CLIENT_ID:$CLIENT_SECRET" \
--data 'grant_type=client_credentials&scope=all-apis&assume_group=<group-id>'

Remplacez <group-id> par l’ID numérique du groupe de support du rôle.

En supposant qu’un rôle présente les exigences et limitations suivantes :

• Pris en charge uniquement pour les jetons au niveau de l’espace de travail. Si vous incluez assume_group dans une demande de jeton au niveau du compte, la demande échoue.
• Le principal de service et le rôle doivent tous deux être assignés à l’espace de travail cible. La prise de rôle ne remplace pas l’attribution de l’espace de travail du principal de service. Voir Assigner un principal de service à un espace de travail et Assigner un groupe à un espace de travail.
• Le principal de service doit avoir l’autorisation Assume sur le groupe. Si ce n’est pas le cas, la requête échoue. Pour accorder la permission Assume, voir Gérer les permissions sur un groupe.

Après la création du jeton, utilisez-le pour appeler les API de l’espace de travail sans préciser assume_group à nouveau.

Pour un exemple complet avec les requêtes SQL autorisées et refusées ainsi que la vérification d’audit, voir le tutoriel : Définir l’accès d’un agent IA avec RBAC. Pour d’autres méthodes d’authentification, voir Changer de rôles RBAC.

Appeler une API REST Azure Databricks

Utilisez le jeton d’accès OAuth pour appeler les API REST au niveau du compte ou de l’espace de travail . Pour appeler des API au niveau du compte, le principal de service doit être un administrateur de compte.

Incluez le jeton dans l’en-tête d’autorisation avec Bearer authentification.

Exemple de demande d’API REST au niveau du compte

Cet exemple répertorie tous les espaces de travail d’un compte. Replace:

• <oauth-access-token> avec le jeton d’accès OAuth du principal de service.
• <account-id> avec votre identifiant de compte.

export OAUTH_TOKEN=<oauth-access-token>

curl --request GET --header "Authorization: Bearer $OAUTH_TOKEN" \
'https://accounts.azuredatabricks.net/api/2.0/accounts/<account-id>/workspaces'

Exemple de demande d’API REST au niveau de l’espace de travail

Cet exemple répertorie tous les clusters disponibles dans un espace de travail. Replace:

• <oauth-access-token> avec le jeton d’accès OAuth du principal de service.
• <databricks-instance> avec le nom d’instance de l’espace de travail Azure Databricks , par exemple adb-1234567890123456.7.azuredatabricks.net.

export OAUTH_TOKEN=<oauth-access-token>

curl --request GET --header "Authorization: Bearer $OAUTH_TOKEN" \
'https://<workspace-URL>/api/2.0/clusters/list'

Résoudre les problèmes d’authentification OAuth M2M

Utilisez ces étapes pour résoudre les problèmes les plus courants liés à l’authentification OAuth M2M de Databricks pour les entités de service.

Vérifications rapides

Commencez par vérifier ces problèmes de configuration courants qui provoquent des échecs d’authentification OAuth M2M :

• Identifiants :DATABRICKS_CLIENT_ID est défini sur l’ID d’application du principal du service (ID client) et DATABRICKS_CLIENT_SECRET sur la valeur secrète OAuth, tous deux sans espaces supplémentaires.
• Hôte : redirige vers pour les opérations de compte ou l’URL dédiée à un espace de travail , par exemple pour les opérations d’espace de travail. N’incluez pas /api.
• Attribution : Pour les jetons d’espace de travail, le principal de service est attribué à l’espace de travail cible. Lors de l’adoption d’un rôle, ce rôle doit également être assigné à cet espace de travail. Vérifiez que le principal de service dispose de l’autorisation Assume et incluez assume_group dans la requête de jeton. Voir Endosser un rôle.
• Autorisations : L’identité utilisée par le jeton, soit le principal de service, soit le rôle assumé, possède les autorisations requises sur la ressource cible.
• Conflits: Aucune variable en conflit telle que DATABRICKS_TOKEN, DATABRICKS_USERNAME. Exécuter env | grep DATABRICKS et annuler les conflits.
• Outils: Utilisez l’authentification unifiée et les versions actuelles de l’interface CLI ou du SDK.

401 Non autorisé

Causes et correctifs probables :

• ID client ou secret incorrect : Recopiez DATABRICKS_CLIENT_ID et DATABRICKS_CLIENT_SECRET. Veuillez régénérer le secret si vous n'êtes pas sûr.
• Secret expiré : Créez un secret si celui-ci a expiré.
• Émetteur de jeton incorrect : Pour M2M, utilisez le point de terminaison de jeton OAuth Databricks, et non votre idP ou votre point de terminaison de jeton cloud.
• Incompatibilité de l’hôte : Si vous vous authentifiez pour les API d’espace de travail, DATABRICKS_HOST doit être l’URL de l’espace de travail que vous appelez.

403 Interdit

Causes et correctifs probables :

• Permissions de ressources manquantes : Accorder à l’identité utilisée par le jeton les autorisations requises, telles que CAN USE ou CAN MANAGE sur des clusters ou des entrepôts SQL, ainsi que des autorisations au niveau de l’objet sur des notebooks, des jobs ou des objets de données. Pour un jeton à portée de rôle, accordez ces permissions au rôle.
• Pas d’attribution d’espace de travail : Attribuer le principal de service à l’espace de travail. Pour un jeton à portée de rôle, attribuez également le rôle à l’espace de travail, accordez au principal de service l’autorisation Assume, et incluez assume_group lors de la création du jeton. Voir Endosser un rôle.
• Accès à l’API administrateur : Pour les API d’administration d’espaces de travail, l’identité utilisée par le jeton doit être celle d’un administrateur d’espace de travail. Pour les API d’administration de compte, l’entité de service doit être un administrateur de compte. L’assomption de rôle n’est prise en charge que pour les jetons au niveau de l’espace de travail.

Problèmes de configuration

Les symptômes incluent les temps d’attente dépassé, « hôte introuvable », « compte introuvable » ou « espace de travail introuvable ».

Correctifs :

• Règles d’hôte : Utilisez l’URL de la console de compte pour les API de compte. Utilisez l’URL de l’espace de travail pour les API d’espace de travail. N’incluez pas le /api suffixe.
• ID de compte : Indiquez DATABRICKS_ACCOUNT_ID uniquement les opérations au niveau du compte. Utilisez l’UUID à partir de la console de compte.
• Sélection de profil : Si vous utilisez plusieurs profils, passez --profile <name> ou définissez DATABRICKS_CONFIG_PROFILE.

Connectivity

Si l’authentification OAuth M2M échoue en raison de problèmes réseau, utilisez ces tests pour vérifier que votre environnement peut atteindre les points de terminaison Databricks :

• DNS:nslookup <your-host> (doit retourner des adresses IP pour le nom d’hôte)
• TLS et accessibilité :curl -I https://<your-host> (doit retourner l’état HTTP 200, 401 ou 403)
• Réseau d’entreprise : Vérifiez que les règles de proxy ou de pare-feu autorisent HTTPS aux points de terminaison Databricks

Ressources supplémentaires

• Principaux de service
• Vue d’ensemble du modèle d’identité Databricks
• Informations supplémentaires sur l’authentification et le contrôle d’accès