Quick start
- Use By role to look up a role you already know the name of.
- Use By action to work backwards: paste an operation such as
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read. - The least-privilege candidate is called out above the results, and the list is ordered narrowest first.
- Open a role to see its Actions, NotActions, DataActions and NotDataActions.
- Use Compare to see exactly what one role grants that another does not.
Searching by action
This is the part that is hard to do by hand, and it is where the tool earns its place.
- Wildcards work in both directions. Searching
Microsoft.Compute/*/readfinds Reader (which holds the broader*/read) and Virtual Machine Contributor (which holds the narrowerMicrosoft.Compute/virtualMachines/*). Neither pattern contains the other as text; they overlap atMicrosoft.Compute/virtualMachines/read. - A
*spans slashes. It is not segment-limited. Reader's single action is*/read, and that really does grant a read five segments deep. - NotActions are subtracted. Contributor holds
*but excludesMicrosoft.Authorization/*/Write, so it does not appear when you search forMicrosoft.Authorization/roleAssignments/write. This is the single most common mistake made by eye, and it is the reason Contributor cannot create role assignments. - Action names are case-insensitive, matching Azure's own behaviour.
How "least privilege" is ranked
Each role carries a breadth: how many of the catalogue's 2,553 known operations it actually grants, with its exclusions subtracted. Owner grants all 2,553; Contributor grants 2,548 — the difference is exactly its five Authorization exclusions; Storage Blob Data Reader grants 3.
Roles are ordered by that number, so the narrowest genuine candidate is first.
Treat it as a ranking, not a verdict. The catalogue only contains operations that built-in roles happen to name, so it is a large sample rather than the whole of Azure. Read the permissions before assigning anything.
Custom role definitions
Export as custom role JSON produces an ARM custom role seeded from the built-in one, with IsCustom: true and no Id — it is a starting point to edit and deploy, not a copy of the original. Fill in AssignableScopes (it defaults to a {subscriptionId} placeholder) before running az role definition create.
Where the data comes from
The role definitions are parsed from Microsoft's published built-in roles reference — 19 category pages, each carrying the real ARM definition for every role. The generated date is shown under the search box, and the data ships with the page, so nothing you search for leaves the browser.
Because it is a snapshot, a role added by Microsoft last week may not be present yet. Run pnpm refresh:azure-rbac to re-pull. Reference data is © Microsoft and used under CC-BY-4.0.
Troubleshooting
- A role you expected is missing from an action search. Check its NotActions — an exclusion covering your action removes it deliberately. Open the role and look at the subtracted bucket.
- Nothing matches your action. Check the spelling against the provider's operation list, or widen it with a wildcard. Not every Azure operation is granted by a built-in role; some genuinely need a custom one.
- The breadth number looks low for a data-plane role. Data-plane permissions are usually written as wildcards, so they are measured with a representative operation rather than an enumerated list. The ordering holds; the absolute number is a sample.
- A role appears "via
*". It matched because it holds a catch-all, not because it names your operation. Those roles sort last for exactly that reason.