1. Executive Summary
The team is moving Maxim Crane's Microsoft Fabric tenant from an ad-hoc, individual-user permission model to a group-driven, role-based model governed by Microsoft Entra ID. Today, access drifts because users, service principals, and connections are added one-by-one to workspaces, semantic models, deployment pipelines, connections, and Azure resources. This creates onboarding friction, orphaned objects, and unclear ownership.
Two parallel security tracks were defined:
- Machine/automation access — via Workspace Identity (credential-free managed service principal) for cross-workspace refreshes, pipelines, Key Vault, and ADLS Gen2 access.
- Human access — via Entra ID groups mapped to the four built-in Fabric workspace roles (Viewer / Contributor / Member / Admin), reinforced by Row-Level Security (RLS) on semantic models.
The biggest unresolved tension is auditability vs. manageability: groups simplify onboarding, but the team needs to confirm Fabric audit logs still resolve actions back to the individual user (Microsoft Docs confirm: yes, audit logs capture the individual user identity, not the group).
2. Discussion Themes
| # | Theme | Pain Point Today | Direction Agreed |
|---|
| 1 | Workspace Identity | Created as ad-hoc service principals; permissions to Azure (Key Vault, blob, graph) granted reactively | Standardize: every new workspace identity gets a documented checklist of Azure permissions |
| 2 | Cross-workspace refresh | Reports in Reporting-Dev couldn't refresh from Maxim Data Marts | Add source workspace identity to the target workspace's Manage Access |
| 3 | User access | Individual users sprinkled across workspaces; new hire = manual add everywhere | Replace with Entra groups: Fabric-{Env}-Workspace-{Role} and Fabric-{Domain}-{Role} |
| 4 | Domain segmentation | Finance / HR / Operations data co-mingled; no domain-scoped groups | Per-domain groups (Viewer / Member / Contributor); RLS for data-level filtering |
| 5 | Dev / Test / Prod | Same admin pool across environments | Same Viewer/Contributor across envs; restrict Admin in Prod to deployment engineers only |
| 6 | Deployment pipelines | Pipeline permissions are separate from workspace permissions; previous owner left → pipelines orphaned | Use a group plus named individuals on pipelines for auditability and continuity |
| 7 | Connections | Hundreds of duplicate/orphaned connections; case-sensitive name drift; notebook connections behave oddly | Adopt naming standard [Env] Source – Purpose; consolidate; one workspace-identity connection per source workspace |
| 8 | Secure / sensitive data | HR (ADP) and potentially financial data need stricter isolation | Add a future *-Secure role tier and warehouse-level grants on those lakehouses |
| 9 | Modify semantic models | Concern users could edit shared models | Confirmed: business users do not edit models today — keep it that way |
| 10 | Admin portal hardening | Tenant settings largely untouched; defaults favor usability over security | Audit tenant settings; disable unused export/share defaults |
3. Use Cases Extracted
UC-1 — Cross-Workspace Semantic Model Refresh
A Power BI report in Reporting-Dev needs to refresh from a lakehouse in Maxim-Data-Marts.
Resolution: Create workspace identity on Reporting-Dev; grant it Viewer (or higher) on Maxim-Data-Marts; switch the connection to "Workspace Identity" auth. (Validated in session.)
UC-2 — New Developer Onboarding
Today: add user individually to every workspace, connection, pipeline, capacity.
Future: add user to one Entra group → inherits access everywhere.
UC-3 — Domain Self-Service (Finance, HR, Operations)
Domain users edit reports in their own domain workspace (Member/Contributor), but are Viewer-only on shared gold-layer reporting workspaces. Data-level access enforced by RLS on the semantic model.
UC-4 — Promotion to Production
Anyone in IT may push Dev → Test. Only a small group (e.g., Fabric-Prod-Workspace-Admin) may push Test → Prod. Pipeline ownership stays auditable via individual + group assignment.
UC-5 — Workspace Identity Accessing External Azure Resources
Workspace identity needs Key Vault Secrets User, Storage Blob Data Reader/Contributor on ADLS Gen2, etc. Build a standard "WS-Identity provisioning checklist."
UC-6 — Secure Domain (HR / Financial PII)
Lakehouse/warehouse-level grants restricted to a Fabric-HR-Secure group; even tenant admins outside that group cannot read rows.
UC-7 — Connection Consolidation
Eliminate duplicate connections (e.g., notebook connections that re-create themselves on deploy) using a naming convention and group-based access on the connection itself.
4. Action-Item Takeaways
| Owner | Action | Priority |
|---|
| Jacob | Draft Entra group catalog (env × role, domain × role) and circulate | High |
| Jacob/Joey | Stand up test in repurposed CI/CD workspaces — prove audit trail when groups are used | High |
| Joey | Document workspace-identity provisioning checklist (Key Vault, blob, etc.) | High |
| Chris | Validate which connections are actually in use; delete orphans | Medium |
| Andy | Review Fabric tenant admin settings vs. Microsoft baseline (export, sharing, SPN-can-use-APIs) | Medium |
| All | Define naming standard for connections and workspace identities | Medium |
| All | Decide policy on individual + group dual-assignment for deployment pipelines | Medium |
| All | Plan a *-Secure tier for HR / financial data | Low (future) |
5. Microsoft Best-Practice Alignment
Cross-referenced with Fabric Security baseline, Workspace roles, RLS, and Deployment pipelines.
5.1 Identity & Access — Zero Trust foundation
- Use workspace identity for service-to-service auth — credential-free, no rotation overhead. ✅ matches team direction.
- Always map roles to Entra security groups, not individuals. Microsoft explicitly recommends this for both workspace roles and RLS role mappings.
- Audit logs still capture the individual user even when access is granted via a group — so the team's auditability concern is mitigated.
- Enforce Conditional Access + MFA + PIM for admin roles.
⚠ Important change (July 27, 2025): New workspace identities no longer get default Contributor access to their own workspace. You must grant the role explicitly. (This is exactly what Joey ran into.)
5.2 Workspace Role Model (built-in)
| Role | Read | Write | Share | Manage | Best fit |
|---|
| Viewer | ✅ | ❌ | ❌ | ❌ | Business consumers; RLS enforced here |
| Contributor | ✅ | ✅ | ❌ | ❌ | IT developers in Dev/Test |
| Member | ✅ | ✅ | ✅ | partial | Domain power users, deployment engineers |
| Admin | ✅ | ✅ | ✅ | ✅ | Tenant/Workspace owners; smallest possible group in Prod |
RLS reminder: RLS only filters for the Viewer role — Contributors/Members/Admins bypass RLS. So domain power users with Member/Contributor see all rows in their workspace's semantic models.
5.3 Deployment Pipelines (the gotcha)
- Pipeline permissions are independent of workspace permissions.
- To deploy: must be both
Pipeline Admin and at least Contributor on both source and target workspaces.
- Microsoft 365 groups are not supported as pipeline admins — use security groups or individuals.
- ✅ Team's plan (group + named individuals) is the recommended pattern for continuity and auditability.
5.4 Isolation Boundaries
- Workspaces are the primary security boundary — Microsoft recommends one workspace per domain/team/medallion-layer. ✅
- For HR/PII: combine workspace isolation with OneLake security roles (folder/table-level RBAC) for the Secure tier.
5.5 Connections
- Workspace identity is the recommended Prod auth for connections; user-based is OK in Dev/Test for traceability.
- Standardize naming early — Fabric auto-creates connections on copy/deploy, so drift is inevitable without a convention.
5.6 Tenant Hardening Checklist (review in admin portal)
- Restrict workspace creation to admins.
- Disable "anyone with the link" sharing.
- Disable external sharing if not required.
- Require sensitivity labels.
- Enforce OAuth/managed-identity; disable basic auth.
- Confirm "Service principals can use Fabric APIs" is enabled only for the SPNs that need it.
- Enable audit log export to a SIEM / Log Analytics.
5.7 Workspace Limits (heads-up)
Rolling out Aug 2025: max 1,000 users/groups per workspace role. Group-based access protects you from ever hitting this.
6. Visuals for Managers
6.1 Two-Layer Security Model
flowchart LR
subgraph IDENTITY["Identity Layer — Microsoft Entra ID"]
U[Users]
G[Security Groups]
WI[Workspace Identity / Service Principal]
U --> G
end
subgraph FABRIC["Microsoft Fabric"]
WS[Workspaces
Viewer / Contributor / Member / Admin]
SM[Semantic Models
+ Row-Level Security]
DP[Deployment Pipelines]
CN[Connections]
end
subgraph AZURE["Azure Resources"]
KV[Key Vault]
ADLS[ADLS Gen2 / Blob]
SQL[SQL / DB sources]
end
G -->|access| WS
WS -->|inherit| SM
G -->|RLS mapping| SM
G -->|Pipeline Admin + workspace role| DP
WI -->|auth| CN
WI -->|granted role| KV
WI -->|granted role| ADLS
WI -->|granted role| SQL
CN --> WS
6.2 Target Entra Group Catalog (proposed)
flowchart TB
classDef it fill:#dbeafe,stroke:#1d4ed8,color:#0b1f55
classDef domain fill:#dcfce7,stroke:#15803d,color:#052e16
classDef secure fill:#fee2e2,stroke:#b91c1c,color:#450a0a
subgraph IT["IT / Platform groups (env-scoped)"]
A1[Fabric-Dev-Workspace-Admin]:::it
A2[Fabric-Dev-Workspace-Member]:::it
A3[Fabric-Dev-Workspace-Contributor]:::it
A4[Fabric-Dev-Workspace-Viewer]:::it
B1[Fabric-Test-Workspace-Admin]:::it
B2[Fabric-Test-Workspace-Contributor]:::it
C1[Fabric-Prod-Workspace-Admin
SMALL — deploy engineers]:::it
C2[Fabric-Prod-Workspace-Contributor]:::it
C3[Fabric-Prod-Workspace-Viewer]:::it
end
subgraph DOM["Domain groups (business)"]
F1[Fabric-Finance-Viewer]:::domain
F2[Fabric-Finance-Contributor]:::domain
F3[Fabric-Finance-Member]:::domain
H1[Fabric-HR-Viewer]:::domain
O1[Fabric-Operations-Viewer]:::domain
O2[Fabric-Operations-Contributor]:::domain
end
subgraph SEC["Secure tier (future)"]
S1[Fabric-HR-Secure]:::secure
S2[Fabric-Finance-Secure]:::secure
end
6.3 Where Each Control Lives
flowchart LR
USER[Business User]
USER -->|in| GRP[Entra Group]
GRP -->|workspace role| WS1[Domain Workspace
Gold Reports]
WS1 -->|opens| RPT[Power BI Report]
RPT -->|reads| SM[Semantic Model]
SM -->|RLS filter by group| ROWS[(Rows user can see)]
subgraph CTRL1["Controls access to the WORKSPACE"]
GRP
end
subgraph CTRL2["Controls which ROWS are visible"]
SM
end
subgraph CTRL3["Controls which TABLES/FOLDERS (Secure tier)"]
OLS[OneLake Security Roles]
end
OLS -.->|optional| SM
6.4 Promotion / CI-CD Flow with Auditability
flowchart LR
DEV[Dev Workspace
everyone can deploy] --> TST[Test Workspace
most of IT]
TST --> PRD[Prod Workspace
only Prod-Admin group]
DEV -.->|Pipeline Admin = group
+ named individuals| PIPE[Deployment Pipeline]
TST -.-> PIPE
PRD -.-> PIPE
PIPE -.->|Fabric audit log
captures named user| LOG[(Audit / SIEM)]
6.5 Workspace Identity Provisioning Checklist (machine access)
flowchart TD
START([New Workspace Identity needed]) --> CREATE[Create WS Identity
in Workspace Settings]
CREATE --> GRANT[Explicitly grant the
workspace role
⚠ no default Contributor since Jul 2025]
GRANT --> NEEDS{What does it need
to reach?}
NEEDS -->|Another Fabric WS| W[Add WS Identity to
target workspace role]
NEEDS -->|Key Vault secrets| K[Grant Key Vault
Secrets User on the vault]
NEEDS -->|ADLS Gen2 / Blob| B[Grant Storage Blob
Data Reader/Contributor]
NEEDS -->|External SQL / API| S[Add to data-source
access list]
W & K & B & S --> CONN[Create Fabric connection
auth = Workspace Identity]
CONN --> DOC[Record in inventory
standard naming]
6.6 Current vs. Target State (manager view)
flowchart LR
subgraph TODAY["TODAY — high friction"]
T1[Users added individually
to each workspace]
T2[Hundreds of duplicate
connections]
T3[Service principals
provisioned ad-hoc]
T4[Prod deploy access
= same as Dev]
T5[Auditability OK
but onboarding slow]
end
subgraph TARGET["TARGET — low friction, governed"]
G1[Entra groups by
env × role and
domain × role]
G2[Standardized connection
naming + WI auth in Prod]
G3[Workspace Identity
with provisioning checklist]
G4[Restricted Prod-Admin
group + named individuals]
G5[Audit log retained;
onboarding = 1 group add]
end
TODAY -->|3-phase rollout:
1 Groups, 2 WS Identity, 3 Connections cleanup| TARGET
7. Recommended Sequencing
- Stand up the Entra group catalog (one week). Naming standard, no permission changes yet.
- Pilot in CI/CD workspaces — assign groups, perform actions as different members, confirm Fabric audit log resolves to the individual.
- Workspace Identity provisioning checklist — publish, then retrofit existing workspaces one domain at a time.
- Migrate users: replace individual assignments with group assignments domain-by-domain (Finance first, since data-mart use case is already live).
- Connection consolidation — once groups are on connections, delete orphans.
- Tenant-admin hardening pass against the Microsoft Fabric security baseline.
- Secure tier — design and apply OneLake security roles for HR / financial data.
8. Open Questions to Resolve
- Does Fabric audit log resolve individual identity when access is granted only via a nested group? (Plan: test in CI/CD workspace; Microsoft Docs say yes.)
- For deployment pipelines, will dual-assignment (group + individual) cause "who deployed" attribution to flip? (Test.)
- Is the older on-prem SQL Server compatible with the service-account model Chris is building, or only the new SQL platform?
- Is "Fabric IQ" (mentioned at end) relevant to governance posture? Triage separately.