RBAC

rbac

rbac is the evidence view behind Azure role-based access control.

Use it when you need to see which principals are assigned to which roles at which scopes, without skipping straight to summary conclusions.

What This Command Answers

• Which Azure role assignments are visible in the current scope?
• Which principal has which role?
• How broad is each assignment?
• What assignment evidence explains why a principal looks powerful?

Run It

azurefox rbac --output table

For deeper review or correlation:

azurefox rbac --output json

Example Table Output

id	scope id	principal type	role name
ra-1	/subscriptions/...2222	ServicePrincipal	Owner
ra-2	/subscriptions/...2222	User	Reader

When To Use It

• after Permissions identifies a principal worth verifying
• when you need exact role and scope evidence
• when you want to confirm whether access is broad, narrow, repeated, or potentially inherited

What To Look For

• high-impact roles such as Owner or User Access Administrator
• broad scopes such as subscription-level assignments
• repeated assignments affecting the same principal
• role and scope combinations that explain why a principal is operationally important

Why It Matters

Higher-level commands are most useful when you can still trace them back to concrete assignment evidence.

rbac is where you verify the actual role and scope story instead of treating summary output as a black box. It keeps privilege review defensible and helps separate real control from noisy low-impact access.

What Should Stand Out First

• high-impact roles before low-impact roles
• broader scopes before narrow ones
• assignments tied to the current identity or another already-interesting principal
• enough assignment detail to defend why a row matters

If You See..., Go Next To...

• If you see role_name=Owner or role_name=User Access Administrator at subscription scope, go next to Permissions because it collapses the raw assignments into the small set of principals that matter first.
• If a high-impact assignment belongs to a service principal or workload identity, go next to Role-Trusts because it explains who can modify that identity or trust into it.
• If the powerful assignment belongs to the current identity, go next to Privesc because it shows whether that access already creates a direct abuse or escalation path.

What To Do Next

• Use Permissions if you need a shorter prioritized list of the most important principals.
• Use Privesc if the assignment pattern suggests a likely escalation path.
• Use Role Trusts if the interesting path is indirect control rather than direct RBAC.

Boundary

rbac should expose assignment evidence clearly.

It is not the final judgment layer for effective permissions, indirect trust, or escalation-path analysis.