Azure RBAC Design for Multi-Team Environments
Security & Identity
Azure RBAC done poorly either over-provisions access (a security risk) or creates constant friction for engineering teams (an operational risk). This is the role assignment model I apply to enterprise Azure environments with multiple teams.
Key Patterns & Steps
- Principle of least privilege: start with no access, grant the minimum required scope — not the opposite
- Assignment scope: prefer resource group scope over subscription scope; avoid subscription Owner assignments except for platform admins
- Use built-in roles first: Contributor, Reader, Storage Blob Data Contributor — only create custom roles when built-ins genuinely do not fit
- Service principals and managed identities for applications — no human credentials embedded in application config
- Privileged Identity Management (PIM): require just-in-time elevation for high-privilege roles; all elevations logged and time-limited
- Regular access reviews: quarterly review of all assignments; remove access within 24 hours of offboarding
Lessons Learned
The incident that triggered an RBAC overhaul was a departed contractor whose subscription Contributor access had never been revoked. Automate offboarding to Azure AD group removal — do not rely on a manual ticket process.
Technologies
← Back to Architecture Notes