// tools/role-right-sizer

Role right-sizer

Load an Azure Activity log export, pick a user, app or managed identity, and get a custom role that holds only the actions it actually used. You'll see how much access it would lose, whether a built-in role already fits, and the commands to make the swap.

Runs entirely in your browser. Nothing you paste is sent anywhere.

Activity log (JSON or CSV)

load export

Not sure how to get it? See get the log below. The sample is made up: contoso.com and every name in it are fictional.

Get the log

Export everything one identity changed in the last 90 days. Run it once for each subscription it works in, or combine the files. The command returns only 50 events unless you raise --max-events.

shell4 lines

1
2
3
4az monitor activity-log list \
  --subscription "<subscription name or ID>" \
  --caller "<UPN, or the identity's ID as it appears in the log>" \
  --offset 90d --max-events 10000 > activity.json

Leave out --caller to export everyone, then pick the identity here. If you send the activity log to a Log Analytics workspace, you can look back further than 90 days. Run this and export the results as CSV:

kql4 lines

1
2
3
4AzureActivity
| where TimeGenerated > ago(180d)
| where CategoryValue == "Administrative"
| project TimeGenerated, Caller, OperationNameValue, ActivityStatusValue, ActivitySubstatusValue, _ResourceId, ResourceGroup, CorrelationId

What it can't see

Reads. Microsoft says the activity log "doesn't typically capture read operations", so the tool can't tell which resources an identity looks at. Choose how much read access to keep in the options.
Data access. Reading a blob, a database or a Key Vault secret is a data plane operation. Those go to resource logs, not the activity log, and only if you've turned them on. If the identity needs data access, add the DataActions yourself.
Anything older than the export. Azure keeps activity log events for 90 days. A task that runs once a quarter or once a year may not be in it, so check the "seen once" list before you remove access.
Other identities. If a pipeline sometimes runs as a different service principal, that identity's changes won't show here.

Test the new role alongside the old assignment first, then remove the old one once nothing has failed for a while. Each tenant can have up to 5,000 custom roles.

How it works

Events with the same correlation ID are grouped, so a change counts once. Actions that only ever failed are listed but left out, because the identity has been working without them. You can tick any of them to keep it.
The action string comes from the event's authorization.action, which is the permission Azure checked, or the operation name if that's missing. Each one is written out in full, without wildcards, as Microsoft recommends. Read access uses one wildcard per provider, such as Microsoft.Web/*/read.
Built-in roles and action descriptions come from Microsoft's published role and resource provider operations lists, refreshed with the least-privilege role finder. Action counts are counts of documented operations, so treat them as a guide to scale.

Sources