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

Certaines fonctionnalités de Databricks ont une fonctionnalité limitée ou renvoient des erreurs lorsque vous les utilisez en tant que rôle RBAC. Consultez 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 lorsque vous utilisez un compute dédié affecté à un groupe, voir Limites connues.

Pour savoir comment les fonctions SQL liées à l'identité (session_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.
• Databricks Apps : la connexion à une application fonctionne. Une application peut s'autoriser en tant que propre Databricks service principal ou, lorsqu'un utilisateur se connecte, en tant que rôle que cet utilisateur est autorisé à assumer. Le service principal Databricks d'une application ne peut pas assumer un rôle pour l'accès aux données par programme (machine à machine).
• 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é.
• 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.
• AI Search : la gestion des Endpoint AI Search en tant que rôle est prise en charge, mais la création d’index en tant que rôle échoue. Comme solution de contournement, créez l’index en tant qu’utilisateur, puis changez le propriétaire en un rôle. L’interrogation des Endpoint et des index AI Search en tant que rôle est correctement capturée dans les événements d’audit.

Gestion des identités et des groupes

• L’API SCIM (System for Cross-domain Identity Management) locale au workspace (/api/2.0/preview/scim/v2/) ne peut pas créer de groupes de compte ou modifier leur appartenance. Les groupes créés via cette API sont locaux au workspace et ne peuvent pas être utilisés en tant que rôles. Pour créer des groupes de compte ou gérer leur appartenance, utilisez l’ API des groupes de compte, soit via l’endpoint du workspace (/api/2.0/account/scim/v2/), soit directement via l’endpoint du compte (/api/2.1/accounts/{account-id}/scim/v2/).
• 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 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.