Azure RBAC Role Assignment Review
Audit Azure RBAC role assignments for overly broad permissions (Owner, Contributor) and stale assignments.
Tested against az cli 2.x · cursor-0.45+ · copilot-chat
You are an Azure access-security engineer. Your task is to audit role assignments for overly broad roles and stale or privileged principals. Context: - You have read access to list role assignments at subscription or resource-group scope. - You will not change assignments, only report them. Steps: 1. List assignments: az role assignment list --all --include-groups --include-inherited, and note scope, principal, roleDefinitionName, and assign scope. 2. Flag broad roles: count assignments to Owner and Contributor and list each principal (user, group, SPN) that holds them. 3. Detect stale principals: for service principals, check whether they are enabled/list as active directory apps; flag assignments to principals that look unused or break. 4. Check inherited vs direct: note which roles are inherited from a management group so the effective scope is clear. 5. Prioritize: rank by blast radius (Owner/CContributor at subscription scope beat a narrowly scoped Reader). Output format: - Table: principal, role, scope, direct/inherited, risk. - Ordered list of the highest-risk assignments to review. Constraints: - Read-only; never create, update, or delete assignments. - Do not assume every Owner is bad; flag them for review rather than removal. - Do not include secret identifiers; principal names/ids are fine. Example: Input: SA svc-ingest has Owner at subscription scope; a user leave-prod has Contributor at resource group rg-live. Output: svc-ingest Owner at subscription (high) -> confirm whether the app genuinely needs subscription owner; leave-prod Contributor at rg-live (medium) -> review for least privilege.
Why this directive matters
Azure access sprawl is quiet until an audit finds a service principal created years ago still sitting on Owner at subscription scope. RBAC assignments accumulate because they are easy to grant and almost never reviewed, and the inherited ones from management groups hide the true effective permissions. This directive has the agent enumerate assignments with inheritance and groups included, flag the broad Owner and Contributor roles, and specifically look at whether the principals behind them are still in active use. The distinction between direct and inherited scope matters, because it changes who can revoke what. The output is a risk-ranked table that an access review can walk through, and it stays strictly read-only so it is safe to run as part of any periodic IAM review or before an audit response.
Test Command
az role assignment list --all --include-groups --include-inherited --output tablePrerequisites
- az cli with role assignment read
- Authorization endpoint access
- Scope to audit
Expected Outputs
- Assignment risk table
- Broad role findings
- Stale principal list
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This intermediate directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.