Le point de départ
On crée un rôle OneLake scopé sur un dossier, on y ajoute un utilisateur, et on s’attend à ce qu’il ne voie plus que ce dossier. Ça marche, à une condition : qu’aucun autre rôle ne lui donne déjà accès à autre chose. OneLake combine en effet les rôles par union, et le rôle par défaut DefaultReader suit une logique à part.
Cet article couvre la combinaison des rôles dans l’explorateur du lakehouse. Le point de terminaison SQL, qui ignore les rôles OneLake tant qu’il est en mode delegated, fait l’objet d’un article séparé. Ici, le point de terminaison est en mode user’s identity.
Règle suivie ici : chaque affirmation est vérifiée en lab avant d’être écrite. Les captures proviennent d’un workspace de test (ws_dp700_sandbox, lakehouse lh_dp700_sandbox) avec deux comptes : fab.admin (Admin) et Alpha, dont on fait varier le rôle de workspace.
1. Trois règles de la documentation
- Deny by default : sans rôle OneLake qui l’accorde, un utilisateur n’a accès à rien. Les rôles de type Deny n’existent pas.
- Union entre rôles : un utilisateur dans plusieurs rôles obtient l’union de leurs accès (modèle least-restrictive). Un rôle ne peut donc jamais retirer ce qu’un autre accorde.
- Rôles par défaut : chaque lakehouse est créé avec un rôle
DefaultReaderdont les membres sont virtualisés : tous les utilisateurs du workspace qui ont la permissionReadAll. Les rôles Admin, Member et Contributor ont de toute façon un accès élevé, indépendant des rôles OneLake.
2. Alpha, sans rôle de workspace
Alpha tente d’accéder au lakehouse : 401 PowerBINotAuthorizedException. Le workspace n’apparaît même pas dans sa liste. Sans rôle de workspace (au minimum Viewer), il n’y a pas de porte d’entrée.
3. Alpha en Viewer, avec un rôle étroit
On ajoute Alpha en Viewer sur le workspace.
On crée ensuite ReadersSalesFolder, un rôle Read scopé sur Files/raw, dont Alpha est le seul membre.
Alpha voit le lakehouse, ce qui est normal pour un Viewer. Dans l’explorateur, il ne voit que Files/raw/sales (trois fichiers), et Tables est bloqué.
Un clic sur Tables renvoie une erreur Forbidden.
4. Un second rôle, plus large : l’union
À 15h05, on crée ReadersAllSalesData, un rôle Read qui couvre le schéma dbo (Tables) et le dossier Files/raw, et on y ajoute Alpha. Alpha reste membre de ReadersSalesFolder : il est maintenant dans deux rôles.
À 15h06, après rechargement, Alpha voit Tables → dbo → sales en plus de Files/raw/sales. Les accès des deux rôles se cumulent : le rôle restrictif n’enlève rien à ce que le rôle large accorde.
À 15h09, on retire Alpha de ReadersAllSalesData. À 15h10, après rechargement, Tables est de nouveau bloqué et seul Files/raw/sales reste visible : Alpha est revenu à son seul rôle étroit.
Dans notre lab, les changements de membres ont pris effet en moins de deux minutes, dans les deux sens.
5. DefaultReader : qui y est, et pourquoi
DefaultReader est le rôle par défaut de chaque lakehouse. Dans notre sandbox, il couvre le schéma dbo et le dossier raw, c’est-à-dire tout le contenu du lakehouse.
Ses membres ne sont pas ajoutés à la main : ils viennent de la permission ReadAll. Ici, seul fab.admin (Admin) y figure, avec la mention Added Using: Permission group-ReadAll. Alpha, simple Viewer, n’y est pas.
6. Le test décisif : passer Alpha en Contributor
On passe Alpha de Viewer à Contributor dans le workspace. Il n’est toujours membre que de ReadersSalesFolder : ReadersAllSalesData est vide.
Le rôle DefaultReader liste maintenant Alpha, avec la mention Permission group-ReadAll : le rôle de workspace lui a donné ReadAll, et Fabric l’a ajouté automatiquement.
Dans l’explorateur, Alpha voit Tables → dbo → sales alors que son seul rôle OneLake ne couvre que Files/raw. Les boutons d’écriture de la barre d’outils, grisés en Viewer, sont actifs.
On repasse Alpha en Viewer à 15h22.
À 15h23, Tables est de nouveau bloqué.
Récapitulatif anti-pièges
| Piège | Ce qu’il faut retenir |
|---|---|
| Rôle étroit + rôle large | Union : l’utilisateur obtient l’accès du rôle le plus large |
| Rôles Deny | N’existent pas : un rôle ne peut pas retirer l’accès d’un autre |
Membres de DefaultReader | Tous les utilisateurs avec ReadAll, virtualisés, non ajoutés à la main |
| Viewer | Pas dans DefaultReader : ses rôles OneLake décident de ce qu’il voit |
| Contributor / Member / Admin | Entrent dans DefaultReader via ReadAll, accès élevé non limité par les rôles |
| Test avec un compte Admin | Ne prouve rien sur un rôle restrictif |
Retirer l’accès de DefaultReader | Modifier ou supprimer le rôle ou son scope de données (global) |
Pourquoi ça compte au-delà de l’examen
Pour l’examen DP-700 (domaine “Implement and manage an analytics solution”, sécurité et gouvernance), savoir que les rôles OneLake se combinent par union, et qui DefaultReader inclut, évite les mauvaises réponses sur « qui voit quoi ».
En production, l’enjeu est de vérifier tous les rôles d’un utilisateur, y compris DefaultReader et son rôle de workspace, avant de considérer qu’un rôle restrictif protège une donnée. Un Contributor n’est pas limité par vos rôles étroits, et un rôle large oublié annule silencieusement un rôle restrictif.
En résumé
- OneLake est en deny by default et combine les rôles par union : un rôle restrictif ne retire rien à ce qu’un autre accorde.
DefaultReaderest alimenté par la permissionReadAll: un Contributor, un Member ou un Admin y entre automatiquement, et n’est pas limité par vos rôles restrictifs.- Pour restreindre les membres de
DefaultReader, la documentation prévoit de modifier ou supprimer ce rôle (ou son scope de données) : une restriction globale, à décider délibérément. - Testez vos rôles avec un compte Viewer dédié, jamais avec un compte administrateur ou Contributor.
Pour le point de terminaison SQL et le mode delegated, voir OneLake security : le point de terminaison SQL lit vos tables.
Sources officielles
- How OneLake security controls data access : deny by default ; rôles de type Grant uniquement ; rôles par défaut et membres virtualisés (
DefaultReader: tous les utilisateurs avecReadAll) ; les rôles par défaut s’appliquent aux Viewers, Admin, Member et Contributor ayant un accès élevé ; on peut modifier ou supprimer un rôle par défaut ; combinaison des rôles par union (least-restrictive). - Data security in OneLake : les rôles OneLake accordent l’accès aux Viewers ou aux utilisateurs avec Read sur l’item ; Admin, Member et Contributor ne sont pas affectés par ces rôles ;
DefaultReaderexiste dans tous les lakehouses et peut être modifié ou supprimé. - Create and manage OneLake security roles : création, modification et suppression des rôles, affectation des membres.
- OneLake security for SQL analytics endpoints : mode d’accès du point de terminaison SQL (voir l’article dédié).