Authentification de l’accès aux ressources Azure Databricks
Pour accéder à une ressource Azure Databricks avec l’interface CLI Databricks ou les API REST, les clients doivent s’authentifier à l’aide d’un compte Azure Databricks disposant de l’autorisation requise pour accéder à la ressource. Pour exécuter en toute sécurité une commande d’interface CLI Databricks ou appeler une requête d’API Databricks qui nécessite un accès autorisé à un compte ou à un espace de travail, vous devez fournir un jeton d’accès basé sur des informations d’identification de compte Azure Databricks valides. Cet article décrit les options d’authentification permettant de fournir ces informations d’identification et d’autoriser l’accès à un espace de travail ou compte Azure Databricks.
Le tableau suivant présente les méthodes d’authentification disponibles pour votre compte Azure Databricks.
Méthodes d’authentification Azure Databricks
Étant donné que les outils et SDK Azure Databricks fonctionnent avec une ou plusieurs méthodes d’authentification Azure Databricks prises en charge, vous pouvez sélectionner la meilleure méthode d’authentification pour votre cas d’usage. Pour plus d’informations, consultez la documentation de l’outil ou du Kit de développement logiciel (SDK) dans Outils de développement.
Méthode | Description | Cas d’usage |
---|---|---|
OAuth pour les principaux de service (OAuth M2M) | Jetons OAuth de courte durée pour les principaux de service. | Scénarios d’authentification sans assistance, tels que des flux de travail CI/CD entièrement automatisés. |
OAuth pour les utilisateurs (OAuth U2M) | Jetons OAuth de courte durée pour les utilisateurs. | Scénarios d’authentification avec assistance, où vous utilisez votre navigateur web pour vous authentifier auprès d’Azure Databricks en temps réel, lorsque vous y êtes invité. |
Jetons d’accès personnels (PAT) | Jetons de courte durée ou de longue durée pour les utilisateurs ou les principaux de service. | Scénarios où votre outil cible ne prend pas en charge OAuth. |
Authentification par identités managées Azure | Jetons Microsoft Entra ID pour les identités managées Azure. | Utilisez-les uniquement avec les ressources Azure qui prennent en charge les identités managées, telles que les machines virtuelles Azure. |
Authentification du principal de service Microsoft Entra ID | Jetons Microsoft Entra ID pour les principaux de service Microsoft Entra ID. | Utilisez-les seulement avec les ressources Azure qui prennent en charge les jetons Microsoft Entra ID et non les identités managées, comme Azure DevOps. |
Authentification Azure CLI | Jetons Microsoft Entra ID pour les utilisateurs ou les principaux de service Microsoft Entra ID. | Utilisez-les pour authentifier l’accès auprès des ressources Azure et Azure Databricks à l’aide d’Azure CLI. |
Authentification utilisateur Microsoft Entra ID | Jetons Microsoft Entra ID pour les utilisateurs. | Utilisez-les seulement avec les ressources Azure qui prennent uniquement en charge les jetons Microsoft Entra ID. Databricks ne recommande pas de créer manuellement des jetons Microsoft Entra ID pour les utilisateurs Azure Databricks. |
Quelle approche d’authentification dois-je choisir ?
Vous avez deux options pour authentifier une commande ou un appel d’API Databricks pour accéder à vos ressources Azure Databricks :
- Utilisez un compte d’utilisateur Azure Databricks (méthode appelée authentification « utilisateur à machine » ou U2M). Choisissez cette option uniquement lorsque vous exécutez une commande Azure Databricks CLI à partir de votre environnement client local ou lorsque vous appelez une requête d’API Azure Databricks depuis du code que vous possédez et exécutez exclusivement.
- Utilisez un principal de service Azure Databricks (authentification « machine à machine » ou M2M). Choisissez cette option si d’autres utilisateurs exécuteront votre code (en particulier dans le cas d’une application) ou si vous créez une automatisation qui appellera des commandes CLI Azure Databricks ou des requêtes d’API.
- Si vous utilisez Azure Databricks, vous pouvez également utiliser un principal de service MS Entra pour authentifier l’accès à votre compte ou espace de travail Azure Databricks. Toutefois, Databricks vous recommande d’utiliser un principal de service Databricks avec notre authentification OAuth fournie via l’authentification du principal de service MS Entra. C’est parce que Databricks utilise des jetons d’accès OAuth plus robustes lors de l’authentification avec uniquement Azure Databricks.
Pour plus d’informations sur l’utilisation d’un principal de service MS Entra pour accéder aux ressources Databricks, consultez Authentification du principal de service MS Entra.
Vous devez également disposer d’un jeton d’accès lié au compte que vous comptez utiliser pour appeler l’API Databricks. Ce jeton peut être un jeton d’accès OAuth 2.0 ou un jeton d’accès personnel (PAT). Toutefois, Azure Databricks vous recommande vivement d’utiliser OAuth plutôt que des PAT pour l’autorisation, car les jetons OAuth sont automatiquement actualisés par défaut et ne nécessitent pas la gestion directe du jeton d’accès, ce qui améliore votre sécurité contre le détournement de jetons et l’accès indésirable. Étant donné qu’OAuth crée et gère le jeton d’accès pour vous, vous fournissez une URL de point de terminaison de jeton OAuth, un ID client et un secret que vous générez à partir de votre espace de travail Azure Databricks au lieu de fournir directement une chaîne de jeton vous-même. Les PAT exposent le risque de jetons de longue durée fournissant des opportunités d’émission s’ils ne sont pas régulièrement audités et pivotés ou révoqués, ou si les chaînes de jeton et les mots de passe ne sont pas gérés de façon sûre pour votre environnement de développement.
Comment utiliser OAuth pour s’authentifier auprès d’Azure Databricks ?
Azure Databricks fournit une authentification client unifiée pour vous aider avec en utilisant un ensemble par défaut de variables d’environnement que vous pouvez définir sur des valeurs d’informations d’identification spécifiques. Cela vous permet de travailler plus facilement et de manière plus sécurisée, car ces variables d’environnement sont spécifiques à l’environnement qui exécute les commandes CLI Azure Databricks ou appellent des API Azure Databricks.
- Pour l’authentification par compte d’utilisateur (utilisateur à machine), Azure Databricks OAuth est géré pour vous avec l’authentification client unifiée Databricks, tant que les outils et SDK implémentent sa norme. Si ce n’est pas le cas, vous pouvez générer manuellement un vérificateur de code OAuth et une paire de vérificateur à utiliser directement dans vos commandes et requêtes d’API Azure Databricks. Consultez Étape 1 : Générer une paire vérificateur de code et test de code OAuth.
- Pour l’authentification du principal de service (machine à machine), Azure Databricks OAuth exige que l’appelant fournisse les informations d’identification du client, ainsi qu’une URL de point de terminaison de jeton dans laquelle la requête peut être autorisée. (Cela est géré pour vous si vous utilisez des outils et SDK Azure Databricks qui prennent en charge l’authentification client unifiée Databricks.) Les informations d’identification incluent un ID client unique et une clé secrète client. Le client, qui est le principal de service Databricks qui exécutera votre code, doit être affecté aux espaces de travail Databricks. Après avoir affecté le principal de service aux espaces de travail auxquels il accède, vous disposez d’un ID client et d’une clé secrète client, que vous allez définir avec des variables d’environnement spécifiques.
Ces variables d’environnement sont :
DATABRICKS_HOST
: cette variable d’environnement est définie sur l’URL de votre console de compte Azure Databricks (http://accounts.cloud.databricks.com
) ou de votre URL d’espace de travail Azure Databricks (https://{workspace-id}.cloud.databricks.com
). Choisissez un type d’URL d’hôte selon le type d’opérations que vous effectuerez dans votre code. Plus précisément, si vous utilisez des commandes CLI au niveau du compte Azure Databricks ou des requêtes d’API REST, définissez cette variable sur votre URL de compte Azure Databricks. Si vous utilisez des commandes CLI au niveau de l’espace de travail Azure Databricks ou des requêtes d’API REST, utilisez votre URL d’espace de travail Azure Databricks.DATABRICKS_ACCOUNT_ID
: utilisé pour les opérations au niveau du compte Azure Databricks. Il s’agit de l’ID de votre compte Azure Databricks. Pour l’obtenir, consultez Localiser votre ID de compte.DATABRICKS_CLIENT_ID
: (M2M OAuth uniquement) l’ID client que vous avez affecté lors de la création de votre principal de service.DATABRICKS_CLIENT_SECRET
: (M2M OAuth uniquement) le secret client que vous avez généré lors de la création de votre principal de service.
Vous pouvez les définir directement ou via un profil de configuration Databricks (.databrickscfg
) sur votre ordinateur client.
Pour utiliser un jeton d’accès OAuth, votre administrateur de compte Azure Databricks ou d’espace de travail doit avoir accordé à votre compte d’utilisateur ou principal de service le privilège CAN USE
pour les fonctionnalités du compte et de l’espace de travail auquel votre code accède.
Pour plus d’informations sur la configuration de l’autorisation OAuth pour votre client et pour passer en revue les options d’autorisation spécifiques au fournisseur cloud, consultez Authentification client unifiée.
Authentification pour des outils et services tiers
Si vous écrivez du code qui accède à des services, outils ou SDK tiers, vous devez utiliser les mécanismes d’authentification et d’autorisation fournis par le tiers. Toutefois, si vous devez accorder à un outil, un SDK ou un service tiers l’accès à vos ressources de compte ou d’espace de travail Azure Databricks, Databricks fournit la prise en charge suivante :
Fournisseur Databricks Terraform : cet outil peut accéder aux API Azure Databricks à partir de Terraform en votre nom, à l’aide de votre compte d’utilisateur Azure Databricks. Pour plus de détails, consultez Approvisionner un principal de service en utilisant Terraform.
Les fournisseurs Git tels que GitHub, GitLab et Bitbucket peuvent accéder aux API Azure Databricks via un principal de service Databricks. Pour plus d'informations, consultez Principaux de service pour CI/CD.
Jenkins peut accéder aux API Azure Databricks via un principal de service Databricks. Pour plus d’informations, consultez CI/CD avec Jenkins sur Azure Databricks.
Azure DevOps peut accéder aux API Azure Databricks via un principal et un ID de service MS Entra. Pour plus d’informations, consultez S’authentifier avec Azure DevOps sur Databricks.
Profils de configuration Azure Databricks
Un profil de configuration Azure Databricks contient des paramètres et d’autres informations qu’Azure Databricks doit authentifier. Les profils de configuration Azure Databricks sont stockés dans des fichiers locaux que vos outils, kits de développement logiciel (SDK), scripts et applications peuvent utiliser. Le fichier de profil de configuration standard est nommé .databrickscfg
. Pour plus d’informations, consultez Profils de configuration Azure Databricks.