Limitations du contrôle d’accès en fonction du rôle (RBAC)

Certaines fonctionnalités d’Azure Databricks ont des fonctionnalités limitées ou des erreurs de retour lorsque vous les utilisez comme rôle RBAC. Vérifiez les limitations des fonctionnalités et les problèmes connus sur cette page avant d’utiliser un rôle pour votre charge de travail.

Pour les limitations spécifiques à la méthode lors de l’utilisation d’un calcul dédié assigné à un groupe, voir Limitations connues.

Pour savoir comment les fonctions SQL liées à l’identité (session_user(), , is_memberis_account_group_member) se comportent en supposant un rôle, consultez Comment les fonctions d’identité se comportent en supposant un rôle.

Fonctionnalités non prises en charge et partiellement prises en charge

Les fonctionnalités suivantes ne fonctionnent pas ou se comportent différemment lorsqu’elles agissent en tant que rôle :

• Briques d’agent : la création d’agents en tant que rôle n’est pas prise en charge.
• Alertes : la gestion des alertes en tant que rôle n’est pas prise en charge.
• Databricks Applications : La connexion à une application fonctionne. Une application peut autoriser comme propre principal de service ou, lorsqu’un utilisateur se connecte, en tant que rôle que l’utilisateur a l’autorisation de supposer. Le principal de service d’une application ne peut pas jouer un rôle d’accès programmatique (machine à machine).
• Traçabilité : la system.access.table_lineage.created_by colonne est correctement remplie avec le rôle, mais l’utilisateur qui a pris le rôle n’est pas capturé.
• Politiques d’utilisation serverless : En tant que rôle, le menu déroulant des espaces de travail dans le formulaire de création de politique d’utilisation serverless est vide, donc vous ne pouvez pas définir une politique pour des espaces de travail spécifiques. Comme solution de contournement, créez la politique comme votre identité utilisateur.
• Recherche IA : la gestion des terminaux de recherche IA en tant que rôle est prise en charge, mais la création d’index en tant que rôle échoue. Pour contourner ce problème, créez l’index en tant qu’utilisateur, puis remplacez le propriétaire par un rôle. L’interrogation des terminaux et index de recherche IA en tant que rôle est correctement capturée lors des événements d’audit.

Gestion des identités et des groupes

• Lorsque vous jouez un rôle, l’API du Workspace System for Cross-domain Identity Management (SCIM) ne/api/2.0/preview/scim/v2 prend pas en charge la création ou la gestion de groupes. Utilisez plutôt l’API des groupes de comptes via le point de terminaison du compte (/api/2.1/accounts/{account-id}/scim/v2/) ou le point de terminaison de l’espace de travail (/api/2.0/account/scim/v2/).
• Les contrôles de partage d’assets d’espace de travail peuvent être appliqués par défaut à un maximum de 100 groupes. De plus, les groupes systèmes, tels que account users et admins, ne peuvent pas être restreints avec des contrôles de partage d’assets de l’espace de travail. Voir Limites et contraintes.

Problèmes connus

Lorsque RBAC est activé, un rapport Power BI qui se connecte à Azure Databricks via le pilote ODBC de Databricks ne se recharge pas lorsque le rapport contient environ 10 connexions simultanées ou plus. Les rapports avec seulement quelques connexions ne sont pas affectés. Cela a été observé avec le pilote ODBC de Databricks version 2.9.1.

Le connecteur Power BI natif pour Azure Databricks n’est pas affecté. Dans Power BI Desktop, connectez-vous avec le connecteur natif au lieu du pilote ODBC : dans Get data, recherchez Databricks ou Azure Databricks. Le connecteur natif est livré avec Power BI, donc il n’y a rien à installer. Voir Connecter Power BI Desktop à Azure Databricks.

Power BI Report Server et Microsoft Excel se connectent uniquement à Azure Databricks via le pilote ODBC. Il n’y a pas de solution de contournement pour ces surfaces.