Limites du contrôle d'accès basé sur les rôles (RBAC)

Cette page répertorie les fonctionnalités et les comportements qui ne fonctionnent pas, ou qui ne fonctionnent que partiellement, lorsqu'ils agissent en tant que rôle. Les fonctionnalités non répertoriées ici se comportent de la même manière lorsqu'elles agissent en tant que rôle que lorsqu'elles agissent en tant qu'identité d'utilisateur.

Pour savoir comment les fonctions SQL liées à l'identité (current_user(), is_member, is_account_group_member) se comportent lors de l'attribution d'un rôle, consultez Fonctionnement des fonctions d'identité lors de l'attribution d'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 :

• Agent Bricks : 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 s'authentifier en tant que son propre Service Principal ou, lorsqu'un utilisateur se connecte, en tant que rôle que cet utilisateur est autorisé à assumer. Le Service Principal d'une application ne peut pas encore assumer un rôle pour l'accès programmatique (de machine à machine) aux données.
• Traçabilité : la colonne system.access.table_lineage.created_by est correctement renseignée avec le rôle, mais l'utilisateur qui a assumé le rôle n'est pas capturé.
• Pipelines : Lakeflow pipelines ne sont pas pris en charge pour les rôles.
• Serverless usage policies : lorsque vous agissez en tant que rôle, le menu déroulant des Workspace dans le formulaire de création de politique d’utilisation Serverless est vide ; vous ne pouvez donc pas limiter une politique à des Workspace spécifiques. En guise de solution de contournement, créez la politique en utilisant votre identité utilisateur.
• Vector Search : la gestion des Endpoint de recherche vectorielle en tant que rôle est prise en charge, mais la création d'index en tant que rôle échoue. En guise de solution de contournement, créez l'index en tant qu'utilisateur, puis modifiez le propriétaire pour un rôle. L'interrogation des Endpoints et des index vectoriels en tant que rôle est correctement enregistrée dans les événements d'audit.

Gestion des identités et des groupes

• L'API SCIM du workspace (/api/2.0/preview/scim/v2) ne prend pas en charge la création ou la gestion de groupes. Utilisez l'API SCIM du compte (/api/2.1/accounts/{account-id}/scim/v2/) ou l'API SCIM du compte du workspace (/api/2.0/account/scim/v2/) à la place.
• Les contrôles de partage des assets de Workspace peuvent être appliqués à un maximum de 100 groupes par default. De plus, les groupes système, tels que all account users et admins, ne peuvent pas être restreints par les contrôles de partage des ressources de workspace. Voir Limites et contraintes.

Problèmes connus

Lorsque le RBAC est activé, un rapport Power BI qui se connecte à Databricks via le driver ODBC Databricks échoue lors du rechargement si le rapport maintient environ 10 connexions simultanées ou plus. Les rapports ne comportant que quelques connexions ne sont pas affectés. Ceci a été observé avec la version 2.9.1 du driver ODBC Databricks.

Le connecteur Power BI natif pour Databricks n'est pas affecté. Dans Power BI Desktop, connectez-vous avec le connecteur natif plutôt qu’avec le driver ODBC : dans Obtenir des données , recherchez Databricks ou Azure Databricks . Le connecteur natif est fourni avec Power BI, il n’y a donc rien à installer. Voir Connecter Power BI Desktop à Databricks.

Power BI Report Server et Microsoft Excel se connectent à Databricks uniquement via le Driver ODBC. Il n'existe aucune solution de contournement pour ces surfaces.