Changer les rôles RBAC

Dans Azure Databricks, vous pouvez endosser un rôle à l’aide du contrôle d’accès en fonction du rôle (RBAC) de plusieurs façons. Les autorisations du rôle s’appliquent aux requêtes ou aux opérations de calcul effectuées en tant que ce rôle. Le périmètre dépend de la méthode : changer de rôle dans l’espace de travail modifie la session du navigateur, tandis que l’authentification d’un profil CLI Databricks ou la connexion au calcul de groupe affecte ce profil ou cette session de calcul.

Requirements

Pour endosser un rôle, vous devez disposer de l’autorisation Assume sur celui-ci. Vous pouvez recevoir l’autorisation Assume directement, par l’intermédiaire d’un groupe auquel elle a été accordée, ou en étant membre du groupe qui implémente le rôle. Le rôle doit être attribué à l’espace de travail avec les droits d’accès dont il a besoin. Consultez Configurer l’accès à l’espace de travail.

Sélecteur de rôles dans l’espace de travail

Utilisez le sélecteur de rôles pour assumer un rôle dans l’ensemble de l’espace de travail. Tous les accès, autorisations, droits de propriété et actions sont ceux du rôle pendant toute la durée de la session.

1. Dans l’espace de travail Azure Databricks, cliquez sur le nom de l’espace de travail dans le coin supérieur droit de la barre supérieure.
2. Pointez sur l’espace de travail actuel (élément supérieur du menu) pour afficher le sous-menu du sélecteur de rôles.
3. Dans le sous-menu, cliquez sur le rôle que vous souhaitez supposer.

L’interface utilisateur recharge et l’identité affichée sous le nom de l’espace de travail passe au rôle que vous avez sélectionné.

Pour revenir à votre identité utilisateur, ouvrez le même sous-menu et sélectionnez votre nom d’utilisateur. Si vous avez accédé à l’espace de travail en endossant un rôle parce que vous n’y êtes pas affecté, votre nom d’utilisateur n’est pas disponible dans la liste de sélection. Voyez quand vous devez prendre un rôle pour accéder à un espace de travail.

Quand il faut endosser un rôle pour accéder à un espace de travail

Si vous n’êtes pas affecté à un espace de travail, directement ou par l’intermédiaire d’un groupe dont vous êtes membre, mais que vous disposez de l’autorisation Assume sur un groupe affecté à cet espace de travail, vous devez endosser un rôle pour y accéder. Cela dépend de votre propre attribution d’espace de travail, pas d’un paramètre d’espace de travail, donc les autres utilisateurs assignés au même espace de travail accèdent toujours en leur propre nom.

Pour obtenir les instructions de configuration et découvrir comment accéder à l’espace de travail en endossant un rôle, consultez Tutoriel : Exiger des utilisateurs qu’ils endossent un rôle pour accéder à l’espace de travail.

URL de l’espace de travail (lien profond)

Vous pouvez endosser un rôle directement depuis l’URL de l’espace de travail en ajoutant le paramètre de requête aid (ID d’endossement), défini sur l’ID du groupe : aid=<group-id>. L’ouverture de cette URL vous authentifie en tant qu’identité utilisateur comme d’habitude, puis assume automatiquement le rôle. Vous n’avez donc pas besoin d’utiliser le sélecteur de rôles.

Par exemple, pour ouvrir un espace de travail agissant déjà en tant que rôle :

https://<workspace-url>/?o=<workspace-id>&aid=<group-id>

Cela est utile pour créer un signet ou partager un lien menant directement à un rôle. Azure Databricks conserve le aid paramètre lorsque vous naviguez dans l’espace de travail, de sorte que vous restez dans le rôle de la session. Le changement d’espace de travail efface ce paramètre. Le rôle est un groupe au niveau du compte et doit être affecté à chaque espace de travail dans lequel vous l’utilisez.

Pour récupérer l’identifiant d’un groupe, utilisez l’API des groupes de comptes. Pour changer de rôle ou revenir à votre identité d’utilisateur après avoir ouvert le lien, utilisez le sélecteur de rôles.

Calcul dédié affecté à un groupe

Lorsque vous vous connectez à une ressource de calcul dédiée assignée à un groupe, les opérations utilisant le principal attribué au calcul utilisent les permissions de ce groupe. Vous n’avez pas besoin de changer de rôle dans l’interface de l’espace de travail d’abord.

L’espace de travail doit être activé pour Unity Catalog, et le cluster de calcul doit utiliser Databricks Runtime 15.4 ou supérieur. Le groupe a également besoin d’accéder aux notebooks et autres ressources utilisés dans l’environnement de calcul. Les opérations gérées par l’environnement de carnet, telles que %run, utilisent les permissions de l’utilisateur plutôt que celles du groupe. Voir Accès dédié au groupe de calcul pour la configuration et les limitations.

Databricks CLI

Lorsque vous utilisez l’authentification OAuth utilisateur-machine (U2M) avec la CLI Databricks, votre navigateur web s’ouvre pour compléter le flux d’authentification. Si vous avez l’autorisation Assume sur un ou plusieurs rôles, vous choisissez dans le navigateur si vous souhaitez vous authentifier avec votre propre identité utilisateur ou en tant que l’un de ces rôles. Si vous n’êtes pas affecté à l’espace de travail, vous ne pouvez pas vous authentifier avec votre propre identité et devez choisir un rôle. Voyez quand vous devez prendre un rôle pour accéder à un espace de travail. Installez l’interface de ligne de commande Databricks avant de commencer. Consultez Installer ou mettre à jour l’interface CLI Databricks. Pour lancer le flux de connexion, exécutez :

databricks auth login --host <workspace-url> --profile <profile-name>

Après avoir terminé le flux de connexion, l’interface de ligne de commande Databricks enregistre un profil de configuration et gère des jetons OAuth éphémères pour celui-ci. Les commandes utilisant ce profil s’exécutent en fonction du rôle que vous avez sélectionné. Changer de rôle dans l’interface utilisateur de l’espace de travail ne modifie pas l’identité de ce profil. Par exemple:

databricks warehouses list --profile <profile-name>

Pour plus de détails sur l’authentification de la CLI Databricks, voir Authentification pour la CLI Databricks.

API (OAuth access tokens)

Vous pouvez générer un jeton d’accès OAuth au niveau de l’espace de travail pour effectuer des appels d’API en tant que rôle. Les scopes OAuth du token limitent les API qu’il peut appeler, et les permissions du rôle déterminent son accès aux ressources.

Pour générer un jeton à portée de rôle, exécutez databricks auth login comme décrit dans Databricks CLI et sélectionnez le rôle dans votre navigateur web. Récupérez un jeton d’accès pour le profil :

databricks auth token --profile <profile-name>

Utilisez le access_token de la réponse dans l’en-tête Authorization: Bearer de la requête API. Un jeton copié dans une autre application ne se rafraîchit pas lui-même. Voir databricks auth token.

Pour un flux U2M manuel, ajoutez assume_group=<group-id> à l’URL d’autorisation de l’espace de travail. Voir Générer un code d’autorisation au niveau de l’espace de travail.

Pour un processus sans intervention utilisant un principal de service, incluez assume_group=<group-id> dans la demande de jeton d’espace de travail de machine à machine (M2M). Le principal de service et le rôle doivent tous deux être affectés à l’espace de travail. Les demandes de jeton au niveau du compte ne prennent pas en charge l’endossement de rôle. Voir Assume a role et Tutoriel : Définir l’accès d’un agent IA avec RBAC.

Outils décisionnels tiers

Les outils décisionnels tiers qui prennent en charge OAuth (tels que Tableau et Power BI) peuvent autoriser en tant que rôle. Après l’autorisation, les requêtes envoyées via cette connexion utilisent les autorisations du rôle. Le rôle doit disposer des autorisations nécessaires pour utiliser le calcul sélectionné et accéder aux données interrogées. Suivez la configuration d’authentification et de calcul prise en charge par l’outil. Voir Databricks ODBC et JDBC Drivers.

Pour les problèmes connus qui affectent les outils et pilotes BI lorsqu’ils agissent en tant que rôle, voir Problèmes connus.

Modifications apportées lorsque vous assumez un rôle

Lorsque vous utilisez le sélecteur de rôles de l’espace de travail :

• Notebooks et requêtes : Exécuter avec ce rôle. Les autorisations du rôle régissent les requêtes interactives et les opérations Unity Catalog effectuées en tant que ce rôle.
• Travaux : lorsque vous créez un travail en tant que rôle, le paramètre Exécuter en tant que de ce travail correspond à ce rôle. Vous pouvez également définir le paramètre Exécuter en tant que d’un travail sur un groupe sans avoir à endosser ce rôle au préalable. Voir Définir l’exécution en tant que groupe.
• Actifs de l’espace de travail : Le rôle possède tous les assets que vous créez (notebooks, requêtes SQL, entrepôts SQL, jobs).
• Journaux d’audit : Distinguer l’identité qui a initié un événement (identity_metadata.run_by) de l’identité utilisée pour l’autorisation (identity_metadata.run_as). Pour les requêtes interactives, elles identifient respectivement votre identité utilisateur et le rôle. Les charges de travail des travaux enregistrent le principal de service d’application du service Jobs en tant que run_by. Voir Vérifier l’attribution de l’audit.

Les exécutions de travaux utilisent l’identité configurée dans le paramètre Exécuter en tant que. Les tâches de requête peuvent également dépendre des paramètres de partage de la ressource SQL, et le calcul dédié peut utiliser le principal qui lui est affecté. Voir Définir l’exécution en tant que groupe.

Pour les fonctionnalités qui ne sont pas prises en charge ou uniquement partiellement prises en charge lors de l’action en tant que rôle, consultez les limitations du contrôle d’accès en fonction du rôle (RBAC).

Ressources supplémentaires