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".

1. 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).

1. 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.

1. 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.

1. 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.

1. 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.

1. 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