Azure Role Selector

Azure Role Selector (RBAC Least Privilege)

Azure RBAC grants access through role assignments = security principal + role definition + scope. The goal is least privilege: the minimum role at the narrowest scope that meets the need, assigned to the right kind of principal (group for humans, managed identity for workloads), and time-bound via PIM where it is privileged.

When to use

Choosing the correct role for a user, group, service principal, or managed identity - or reviewing existing assignments for excess privilege.

Do not use this skill for:

• Entra ID directory roles (Global Admin, User Admin, etc.) (use entra-id)
• Microsoft 365 admin roles (use m365-govern-manage)
• Activating privileged roles or designing access reviews (use azure-pim)
• Multicloud entitlement management (use entra-permissions-management)

Pick the right role family

Rule of thumb: Control-plane roles do not automatically grant data-plane access. Reader lets you see a storage account exists; it does not let you read a blob. Pick the right plane explicitly. This is the single most common RBAC mistake.

Approach

1. Define the required actions precisely - List the exact operations the principal must perform. Distinguish control plane (manage the resource: create, delete, list, configure) from data plane (read or write the data inside: blobs, secrets, queue messages, rows). Verify: requirements are written as verbs and resource types, e.g. "read blob contents in container X" rather than "access storage".
2. Match the most specific built-in role - Prefer the most specific built-in role whose Actions and DataActions cover the need. Built-in roles are maintained by Microsoft and evolve as services add capability. Avoid broad roles (Owner, Contributor) unless genuinely required. Verify: the chosen built-in role's Actions/DataActions cover every required operation and nothing more (use az role definition show).
3. Decide custom vs built-in - Create a custom role only when no built-in role fits. Define minimal Actions/DataActions and NotActions, version the JSON in source control, and pin assignable scopes. Verify: a custom role exists only after confirming no built-in role covers the need; the JSON is in repo with a change history.
4. Scope narrowly - Assign at the lowest effective scope: resource > resource group > subscription > management group. A Storage Blob Data Reader at one container is safer than at the storage account, which is safer than at the subscription. Verify: the assignment scope is the smallest that satisfies the requirement; subscription- wide grants for a single resource are flagged.
5. Prefer identities and groups - Assign to Entra groups for users (not direct user assignments) and managed identities for workloads (not service principals with secrets where avoidable). Group-based assignment scales; per-user assignment does not. Verify: zero direct user assignments at subscription scope; workloads use managed identities, not user accounts.
6. Combine with PIM for privileged roles - For Owner, User Access Administrator, Contributor at broad scopes, and any custom role with write at subscription scope, require PIM activation (just-in-time, MFA, approval where appropriate, time-bound). Verify: privileged role assignments are Eligible, not Active; activation requires MFA and produces an audit log.
7. Govern continuously - Run access reviews quarterly on privileged scopes, remove unused assignments detected by Entra Permissions Management or PIM activity reports, and re-baseline when ownership changes. Verify: an access-review cadence is documented; unused-assignment report is reviewed and actioned.