# Azure Role Selector

> Guidance for selecting the right Azure RBAC role with least privilege - mapping required actions to built-in roles, deciding when a custom role is needed, scoping assignments correctly, and choosing between control-plane and data-plane roles. Covers scope levels (management group → resource), groups vs direct assignment, and PIM for privileged roles. WHEN: which Azure role, least privilege role,…

- **Type:** Skill
- **Install:** `agentstack add skill-vinayaklatthe-microsoft-security-skills-azure-role-selector`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [vinayaklatthe](https://agentstack.voostack.com/s/vinayaklatthe)
- **Installs:** 0
- **Category:** [Cloud & Infrastructure](https://agentstack.voostack.com/c/cloud-infrastructure)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [vinayaklatthe](https://github.com/vinayaklatthe)
- **Source:** https://github.com/vinayaklatthe/microsoft-security-skills/tree/main/skills/azure-role-selector

## Install

```sh
agentstack add skill-vinayaklatthe-microsoft-security-skills-azure-role-selector
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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

| Caller needs to... | Look at | Avoid |
|---|---|---|
| Read storage **account properties** | Control-plane: *Reader* / *Storage Account Contributor* | Owner |
| Read **blob contents** | Data-plane: **Storage Blob Data Reader** | Reader alone (no data access) |
| Write **blob contents** | Data-plane: **Storage Blob Data Contributor** | Owner / Contributor |
| Read **Key Vault secrets** (RBAC mode) | Data-plane: **Key Vault Secrets User** | Key Vault Administrator |
| Manage Key Vault itself | Control-plane: *Key Vault Contributor* | Owner |
| Run an Azure Function with managed identity | Data role on target resource only | Subscription Contributor |
| Delegate role assignment to others | **User Access Administrator** at narrow scope | Owner |
| Read everything in a subscription | *Reader* at subscription | Owner / Contributor |
| Manage one resource group only | *Contributor* at the resource group | Subscription Contributor |

> **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

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [vinayaklatthe](https://github.com/vinayaklatthe)
- **Source:** [vinayaklatthe/microsoft-security-skills](https://github.com/vinayaklatthe/microsoft-security-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-vinayaklatthe-microsoft-security-skills-azure-role-selector
- Seller: https://agentstack.voostack.com/s/vinayaklatthe
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.