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

Cette page répertorie les fonctionnalités et comportements qui ne fonctionnent pas ou ne fonctionnent que partiellement, lorsqu’elles agissent en tant que rôle. Les fonctionnalités non répertoriées ici se comportent de la même façon lorsqu’elles agissent en tant que rôle qu’elles agissent en tant qu’identité de l’utilisateur.

Pour savoir comment les fonctions SQL liées à l’identité (current_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.
• 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 encore assumer un rôle pour l’accès aux données par programmation (machine à ordinateur).
• 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é.
• Pipelines : les pipelines Lakeflow ne sont pas pris en charge pour les rôles.
• 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 vectorielle : la gestion des points de terminaison de recherche vectorielle 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 points de terminaison et des index vectoriels en tant que rôle est capturé correctement dans les événements d’audit.

Gestion des identités et des groupes

• L’API SCIM de l’espace de travail (/api/2.0/preview/scim/v2) ne prend pas en charge la création ou la gestion de groupes. Utilisez l’API SCIM de compte (/api/2.1/accounts/{account-id}/scim/v2/) ou l’API SCIM du compte d’espace de travail (/api/2.0/account/scim/v2/) à la place.
• 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 all 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.