Azure Role-Based Access Control (RBAC): who can do what, where
Slide deck explaining Azure Role-Based Access Control (RBAC): how role assignments grant permissions to Azure resources, scope hierarchy, built-in roles, and how RBAC differs from Conditional Access, Azure Policy, and resource locks.
Azure Role-Based Access Control (RBAC): who can do what, where
Introduction to Azure Role-Based Access Control (RBAC): managing permissions to Azure resources through role assignments.
Azure Role-Based Access Control (RBAC): who can do what, where
Introduction to Azure Role-Based Access Control (RBAC): managing permissions to Azure resources through role assignments.
What Azure RBAC is for
Azure Role-Based Access Control (RBAC) manages permissions to Azure resources. Authorization (permissions), not sign-in. Controls actions on Azure resources. Built around 'least privilege'. Uses role assignments to grant access.
AuthN vs AuthZ
Authentication (AuthN) proves identity; authorization (AuthZ) grants permissions. Authentication (AuthN): 'Who are you?'. Authorization (AuthZ): 'What can you do?'. Microsoft Entra ID: where identities live. Azure RBAC: permissions to Azure resources.
Role assignment = who + what + where
Access is granted by combining an identity, a role, and a scope. Who: security principal (user/group/service principal/managed identity). What: role definition (permissions). Where: scope (boundary for permissions). Rule: 'who can do what at which scope'.
Scope hierarchy and inheritance
A role at a higher scope applies to everything below it. Management group → Subscription → Resource group → Resource. Higher scope equals broader impact. Inheritance flows downward. Use the smallest scope that works.
Common built-in roles
Roles define what actions you're allowed to perform. Reader: view only. Contributor: manage resources (not access). Owner: full access plus can assign roles. User Access Administrator: can manage access (role assignments).
Least privilege: role + scope
Pick the smallest scope and the most specific role that still works. Start: Reader → then Contributor. Use Owner/User Access Administrator only for access management. Scope matters as much as role. Two levers: role specificity plus scope size.
Scenario: developer restarts VMs
Grant the needed VM permissions at the resource group scope. Need: restart virtual machines (VMs). Scope: resource group (not subscription). Role: specific to VM management actions. Avoid: Owner 'to prevent blockers'.
RBAC vs Conditional Access
Conditional Access controls sign-in conditions; RBAC controls resource actions. Conditional Access: sign-in rules (MFA, device, location). Multi-factor authentication (MFA) is a sign-in requirement. Azure RBAC: permissions on Azure resources. Use the right tool for the job.
RBAC vs Azure Policy
Policy can deny configurations even when you have RBAC permissions. Azure RBAC: who can perform actions. Azure Policy: what configs/resources are allowed. Policies can deny regions/types/SKUs (stock keeping units). Don't assume every failure is RBAC.
RBAC vs resource locks
Locks can block changes even when RBAC allows the action. Locks: CanNotDelete / ReadOnly. Protection layer over resources. Can override 'Contributor can delete' expectations. Check locks at resource and parent scopes.
RBAC quick checklist
Scope small, role specific, and troubleshoot with the right control. Use smallest scope that meets the need. Prefer Reader/Contributor over Owner. MFA issues → Conditional Access. Deployment blocks → Azure Policy. Delete blocked → resource locks.