Zugriff und Rollen¶
Der Zugriff auf die Plattform läuft über Entra-ID-Gruppen. Einzelnen Benutzern werden in der Konfiguration keine Rollen zugewiesen.
Workspace-Rollen sind Fabric-Rollen (verwaltet über die Ressource fabric_workspace_role_assignment), keine Azure-RBAC-Rollen.
Workspace-Rollen¶
Jeder Workspace kann für jede von vier Rollen eine Gruppe haben. Alle vier sind in der Konfiguration optional.
| Rolle | Was sie erlaubt |
|---|---|
| Admin | Volle Kontrolle über den Workspace: Einstellungen verwalten, Benutzer und Gruppen hinzufügen und entfernen, Features auf Workspace-Ebene konfigurieren. Hebt den Zugriff des deployenden Service Principals nicht auf. |
| Contributor | Items im Workspace erstellen, bearbeiten und löschen. Erhält Nutzungsrechte auf den Connections des Workspaces (siehe unten). |
| Member | Erweiterte Rechte, einschließlich der Verwaltung von Workspace-Einstellungen. |
| Viewer | Lesezugriff auf Workspace-Items. |
Die Gruppen werden als Object-ID oder als Anzeigename angegeben. Die ID hat Vorrang, wenn beides gesetzt ist. Der Anzeigename wird zur plan-Zeit aufgelöst.
Eine Rolle pro Gruppe
Fabric erzwingt pro Workspace eine Rolle pro Principal. Verwende für jede Rolle eine andere Gruppe. Die Konfiguration enthält eine Prüfung, die dieselbe Gruppe in zwei Rollen meldet, und Fabric lehnt sie beim apply ab.
Die optionale Admin-Gruppe¶
Mit der Rolle Admin kann dein Team Workspace-Einstellungen und Benutzer verwalten, ohne für jede Änderung ein Ticket zu eröffnen. Konfiguriere sie mit
admins_group_id an jedem Workspace.
Was ein Workspace-Admin tun kann:
- Benutzer und Gruppen für Contributor, Member und Viewer hinzufügen und entfernen,
- Workspace-Einstellungen verwalten (Beschreibung, Sensitivity Labels, Endorsement),
- Features auf Workspace-Ebene konfigurieren (Lineage, Einstellungen der Git-Integration),
- Workspace-Items löschen und Zugriffsanfragen verwalten.
Was ein Workspace-Admin nicht tun kann:
- die Capacity des Workspaces ändern (von der Plattform verwaltet),
- die Network Policies ändern (von der Plattform über Terraform verwaltet),
- den Zugriff des deployenden Service Principals entfernen, der als Ersteller des Workspaces implizite Admin-Rechte behält.
Was du bereitstellst¶
| Punkt | Wer | Hinweise |
|---|---|---|
| Entra-ID-Sicherheitsgruppe pro Umgebungsgrenze | Workload-Team oder dein Identity-Team | Zum Beispiel eine für Produktions- und Vorproduktions-Workspaces und eine für Entwicklungs-Workspaces |
| Object-ID jeder Gruppe | Workload-Team, an das Plattform-Team | |
| Gruppenmitgliedschaft | Workload-Team | Du fügst deine eigenen Leute hinzu |
Das Plattform-Team trägt die Object-ID in die Workspace-Konfiguration ein und deployt. Der plan zeigt dann nur additive Änderungen (eine neue Rollenzuweisung). Workspaces werden nicht neu erstellt, und nichts wird gestört. Für ein Rollback entfernst du die Gruppe aus der Konfiguration: Das nächste Deployment entfernt die Zuweisung.
Drift und manuelle Rollenzuweisungen¶
Terraform verwaltet nur die Zuweisungen, die es selbst erstellt.
- Wenn ein Workspace-Admin im Fabric-Portal weitere Zuweisungen hinzufügt, erkennt oder revertiert Terraform sie nicht. Die Plattform verwaltet die Baseline, das Workload-Team verwaltet die Extras.
- Wenn jemand eine Zuweisung entfernt, die Terraform verwaltet, erstellt das nächste Deployment sie neu.
Fehlerbehebung¶
| Symptom | Ursache | Lösung |
|---|---|---|
409 Conflict beim Deployment |
Die Gruppe wurde im Fabric-Portal bereits manuell als Admin zugewiesen | Das Plattform-Team fügt einen temporären Terraform-import-Block für die Zuweisung hinzu (ID: <workspace id>/<principal id>), deployt einmal und entfernt den Block wieder. Oder entferne zuerst die manuelle Zuweisung. |
Warnung der Prüfung unique_role_groups |
Dieselbe Gruppe wird für zwei Rollen verwendet | Verwende unterschiedliche Gruppen oder entferne das Duplikat |
| Die Admin-Gruppe sieht den Workspace nicht | Falsche Object-ID, oder die Gruppe hat keine Mitglieder | Prüfe die ID in Entra ID und stelle sicher, dass die Gruppe mindestens ein Mitglied hat |
Nutzungsrechte auf Connections¶
Die Connections, die die Plattform erstellt, werden über die Connection-Rolle User mit Gruppen geteilt:
| Connection | Gruppen, die im Code die Rolle User erhalten |
|---|---|
| ADLS, SQL (beide Authentifizierungsarten), Oracle Cloud Storage | Die Contributor-Gruppe des Workspaces |
| GitHub-Connection eines Workspaces mit Git-Verknüpfung | Die Contributor-Gruppe und die Member-Gruppe des Workspaces |
Die Servicebeschreibung sagt, dass Contributors und Members Nutzungsrechte auf Workspace-Connections erhalten. Kläre mit deinem Plattform-Team, welche Gruppen in deinem Deployment angewendet werden.
Capacity-Rollen¶
| Rolle | Wo | Wer |
|---|---|---|
| Capacity administrator | Auf der Fabric capacity | Service Principals der spokes, die auf die Capacity deployen, und optional einzelne Benutzer. Gruppen können diese Rolle nicht halten. |
| Fabric Capacity Operator (benutzerdefinierte Azure-Rolle) | Auf der gemeinsamen Resource group | Die Logic Apps für Pause und Resume sowie die Entra-ID-Gruppen, die manuell pausieren und fortsetzen dürfen. Siehe Kostenoptimierung. |
Weiterer Zugriff¶
| Ressource | Zugriffsmodell |
|---|---|
| Managed Grafana | Drei eigene Entra-ID-Gruppen für Admin, Editor und Viewer. Sie sind getrennt von den Fabric-Workspace-Gruppen: Zugriff auf Grafana ist kein Zugriff auf Fabric. Siehe Monitoring. |
| Microsoft Purview | Der deployende Principal hat Contributor auf dem Account, eine optionale Gruppe des Datenteams hat Reader. Siehe Governance. |
| Data-Lake-Storage | Nur OAuth. Der deployende Service Principal hat Storage Blob Data Contributor. |
| Key Vault | Connection-Secrets werden von der Deployment-Identity gelesen, wenn die pipeline läuft. |
Zugriffsanfragen folgen dem normalen Änderungsprozess: Anfragen und Änderungen. Allgemeine Regeln für Gruppen und Just-in-Time-Zugriff auf der Plattform stehen unter Zugriff, Gruppen und PIM.