RBAC, ABAC & Lighthouse
Scopes · Built-in & custom roles · Conditions · Cross-tenant management
Practice questions for this topic →
How Azure RBAC works
| Part | Detail |
|---|---|
| Role assignment | A security principal (user, group, service principal or managed identity) + a role definition + a scope |
| Scopes | Management group, subscription, resource group, resource; assignments are inherited by child scopes |
| Data actions | Separate permissions for data inside a resource (blobs, messages); control-plane roles don't grant them |
| Custom roles | When built-ins are too broad: define Actions, NotActions, DataActions, NotDataActions; 5,000 per tenant; assignable at management group, subscription and resource group scopes; shared across subscriptions in the tenant; start from a built-in role |
| Role | Can |
|---|---|
| Owner | Everything, including granting access |
| Contributor | Manage resources, not grant access |
| Reader | View |
| User Access Administrator | Manage access only |
| Role Based Access Control Administrator | Manage role assignments (can be constrained by conditions) |
| Data roles (e.g. Storage Blob Data Reader) | Data-plane access |
Beyond RBAC
| Feature | Use for |
|---|---|
| ABAC conditions | Narrow a role assignment by attributes (for example blob tag Project=Blue); reduces the number of assignments; can't explicitly deny; bypassed by Shared Key and SAS (not user-delegation SAS) and by ACLs; restrict rename when conditions use paths |
| Azure Lighthouse | A provider tenant manages customer subscriptions or resource groups with delegated RBAC without an account in the customer tenant; at no extra cost |
- Lighthouse mechanics: onboarding creates a registration definition (managing tenant ID and authorizations) and a registration assignment (the delegated scope) in the customer tenant; the result is a logical projection of customer resources into the provider tenant. Onboarding needs a deployment by an account with role-assignment permissions in the customer tenant (for example Owner). Customers can audit and remove access.
Exam Tips
Tick each tip once you can answer it without looking.
“Team can manage VMs but must not grant access to others” → Contributor (or Virtual Machine Contributor). Trap: Owner can grant access.
“Least privilege: built-in roles grant too much” → Custom role.
“Users can read blobs only if tagged with their project” → ABAC role assignment condition on Storage Blob Data Reader.
“ABAC conditions are being bypassed” → Disable Shared Key authorization (SAS/account keys skip conditions).
“Delegate role assignment but only for specific roles” → RBAC Administrator role with conditions (constrained delegation).
“Contributor can see the storage account but can't read blob data via Entra ID” → Assign a data role (Storage Blob Data Reader/Contributor).
“MSP manages 50 customer tenants from its own tenant” → Azure Lighthouse.
“Apply access to all subscriptions in a division” → Assign at the management group scope (inherits down).
“Parts of a role assignment” → Security principal + role definition + scope (management group, subscription, resource group or resource). Trap: Assignments are inherited by child scopes.
“Custom role limits” → 5,000 per tenant; Actions, NotActions, DataActions, NotDataActions; assignable at management group, subscription or resource group. Trap: Start from an existing built-in role.
“Azure Lighthouse mechanics” → A registration definition and a registration assignment in the customer tenant; providers need no account there. Trap: Onboarding needs an Owner-level deployment in the customer tenant.