Build custom RBAC role definitions with granular actions, notActions, dataActions, and assignable scopes.
Output will appear here...Build an Azure custom RBAC role definition with Actions (control-plane operations), NotActions (carve-outs from a broader Actions wildcard), DataActions/NotDataActions (data-plane operations, a genuinely separate permission model from control-plane Actions), and AssignableScopes limiting where the role can actually be assigned. NotActions doesn't work the way a Deny statement does in some other systems, it only subtracts from what's granted by Actions within the same role definition, it has zero effect on permissions granted by a different role assigned to the same principal, so a principal with this role's Actions-minus-NotActions plus a second, broader role assigned separately still gets the union of both, NotActions never actually blocks anything at the principal's overall effective-permission level.
No, NotActions only carves out exceptions from the Actions list within the same role definition, it has no effect on permissions granted by any other role assigned to the same principal. If a principal has this custom role (with delete excluded via NotActions) plus a separate built-in Contributor role also assigned, they still effectively have delete access via Contributor, NotActions never functions as an overriding deny across a principal's full effective permission set.
Actions govern control-plane operations, managing the resource itself (creating, deleting, configuring a storage account). DataActions govern data-plane operations, operating on the data within that resource (reading or writing a blob inside the storage account). They're evaluated as entirely separate permission sets, a role granting broad Actions on a storage account grants no ability to read the actual blob data inside it unless DataActions also explicitly includes that data-plane permission.
No, AssignableScopes is a hard boundary, Azure will reject an attempt to assign the role at any scope not listed in (or nested under) AssignableScopes. This is what prevents a role custom-built and intended for one resource group from later being assigned tenant-wide by someone with sufficient privilege at a broader scope, it's an enforced constraint on the role definition itself, not just a documentation convention.
The tool builds the role definition from the actions/notActions/dataActions/notDataActions/assignableScopes inputs, requiring at least one action in the Actions field and at least one entry in assignableScopes before generating output, mirroring the minimum fields Azure's role definition schema requires; it can't verify the listed Actions/DataActions strings are valid, currently-existing Azure resource provider operations, that's only checked when the role definition is actually created against a live subscription.
Don't rely on NotActions as a security boundary against a principal's overall access, it only shapes what this one role grants, verify a principal's actual effective permissions across every role assigned to them, not just this role definition in isolation.
Remember Actions and DataActions are separate permission planes, a role that looks comprehensive based on its Actions list can still grant zero access to the actual data inside a resource if DataActions wasn't also populated, a common gap when adapting a control-plane-focused role for a data-access use case.
Scope AssignableScopes as narrowly as the role's actual intended use requires, a custom role scoped to the tenant root when it's only ever meant for one resource group widens where it could later be misapplied.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.