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.

Guardrails

• Owner includes the ability to grant access - restrict tightly and prefer User Access Administrator only where delegation is actually needed. Owner is rarely the right answer.
• Control-plane roles (Reader / Contributor) do not automatically grant data-plane access - choose the data role explicitly. Reader + Storage Blob Data Reader is the correct combo for "see the account and read the blobs".
• Review and remove unused assignments; pair high-privilege roles with PIM and access reviews. Standing privilege is the attack surface that compounds over time.
• Custom roles are a maintenance burden - every Microsoft change to the action catalog can break them. Pick built-in unless you genuinely cannot.
• Group-based, not user-based. Direct user assignments do not scale, do not survive joiner/ mover/leaver, and become orphaned permissions.
• Managed identity over service principal with secret wherever the target service supports it - no secret to rotate, no secret to leak.
• Scope at the smallest unit that meets the need. A role at subscription "because it's simpler" is the lazy answer that becomes next year's incident.

Common anti-patterns

• "They need Owner because Reader does not work for blob data." No - they need Storage Blob Data Reader (data plane). Adding Owner solves the wrong problem.
• Custom role that mirrors a built-in with one extra action. Build a follow-up assignment for that one action instead of forking a built-in role you now own forever.
• Per-user assignments at subscription scope. Joiner/mover/leaver leaves orphans; one audit later, the cleanup is a project.
• Owner / Contributor at subscription for an automation service principal. Blast radius equals the subscription. Scope to the resource group and the data role on the target resources only.
• Standing Owner roles. If a role is genuinely needed permanently, it usually is not Owner - it is a narrower role. If Owner is genuinely required, it must be in PIM.
• No access review cadence. Permissions never get smaller without a forcing function.

Example prompts

• Which built-in Azure role gives least-privilege access to read blob data?
• Should I use a built-in or custom role for this scenario?
• Pick the minimal role for a managed identity to access a specific Key Vault secret.
• How do I scope a role assignment correctly for least privilege?
• Move privileged Owner assignments into PIM.

Microsoft Learn

• RBAC overview: https://learn.microsoft.com/azure/role-based-access-control/overview
• Built-in roles: https://learn.microsoft.com/azure/role-based-access-control/built-in-roles
• Custom roles: https://learn.microsoft.com/azure/role-based-access-control/custom-roles
• RBAC best practices: https://learn.microsoft.com/azure/role-based-access-control/best-practices
• Understand role assignments: https://learn.microsoft.com/azure/role-based-access-control/role-assignments
• Storage data plane roles: https://learn.microsoft.com/azure/storage/blobs/authorize-access-azure-active-directory