3.1.5.1. Implement Role-Based Access Control (RBAC)

First Principle: Azure RBAC (Role-Based Access Control) is the main authorization system for managing access to Azure resources. Its core purpose is to enable precise control by defining who can do what, and where, thereby enforcing the "principle of least privilege".

What It Is: "Azure RBAC" provides fine-grained access management for Azure resources.

Visual: "Azure RBAC Core Components and Hierarchy"

Loading diagram...

"RBAC Core Components":

• "Security Principal": The identity requesting access—"user", "group", "service principal" (for apps), or "managed identity" (for Azure services).
• "Role Definition": A set of permissions. Azure provides "built-in roles" (Owner, Contributor, Reader, User Access Administrator) and supports "custom roles" for tailored needs.
• "Scope": The boundary where access applies: "management group", "subscription", "resource group", or individual resource.

Assigning Roles:

• "Azure Portal": Go to the resource, select "Access control (IAM)", click "Add role assignment", pick the "role", assign to a principal, and set the "scope".
• Azure CLI:

  az role assignment create --assignee <principal-id> --role <role-name> --scope <scope>
  

• Azure PowerShell:

  New-AzRoleAssignment -ObjectId <principal-id> -RoleDefinitionName <role-name> -Scope <scope>
  

Best Practices for Least Privilege:

• Grant only the permissions required for the task.
• Use "built-in roles" when possible; create "custom roles" only as needed.
• Regularly review and remove unnecessary assignments.
• Limit "scope" to the smallest necessary resource.

"Deny Assignments": "Deny assignments" can explicitly block access, overriding "role assignments" when needed.

Scenario: You need to grant a new developer full access to create and manage all resources within a specific resource group for their project, but explicitly prevent them from deleting any Virtual Networks in that resource group.

Reflection Question: How does implementing "Azure RBAC", by defining "Security Principals", "Role Definitions", and "Scope", fundamentally enable precise control over who can do what and where, enforcing the "principle of least privilege"?

💡 Tip: Remember that permissions are additive in "RBAC" unless a "deny assignment" is present. If a user is part of multiple groups with different roles, their effective permissions are the union of all granted permissions.