IntermediateAccess Control

Access Control (RBAC)

Master Role-Based Access Control (RBAC), the primary authorization mechanism in Azure. Learn built-in roles, custom roles, scope management, and least privilege principles.

🧠 ELI5 Explanation

RBAC is like job titles in a company. Role = job (Manager, Developer, Viewer). Scope = where you work (Building A, Floor 3, Desk 5). Assignment = giving alice the "Manager" role at "Building A" (alice can now manage Building A, but not Building B).

Least privilege = "Give alice only what she needs": if she's a junior dev, don't make her admin.

Technical Explanation

Role-Based Access Control Fundamentals

RBAC has three key components:

Principal: Who (user, service principal, managed identity)
Role: What permissions (built-in or custom)
Scope: Where (subscription, resource group, resource)

Example: Alice (principal) gets "Virtual Machine Contributor" role (permissions to create/modify VMs) scoped to "ResourceGroup-Production".

Built-in Roles vs Custom Roles

Aspect	Built-in Roles	Custom Roles
Maintenance	Microsoft maintains & updates	You maintain
When to use	Standard jobs (Developer, Admin, Owner)	Specific company needs (e.g., "DB Viewer")
Examples	Owner, Contributor, Reader, VM Admin	"Can scale VMs but not delete", "Can read logs"
Complexity	Simple, predefined	Define JSON with actions/dataActions

Key built-in roles:

Owner: Full access including permissions
Contributor: Create/modify resources, but cannot manage access
Reader: View only, no modifications

Scope Hierarchy

RBAC scope is hierarchical. Higher scope = broader permissions:

Subscription: Broadest (alice can manage all resource groups)
Resource Group: bob can manage all resources in this group
Resource: Narrowest (charlie can only manage this specific VM)

Inheritance: If alice is "Contributor" at subscription level, she's contributor in all resource groups. But you can restrict at resource level.

Best practice: Always use most restrictive scope (resource > resource group > subscription).

Visual Representation

RBAC Scope Hierarchy


      Management Group (optional)

      ├── Subscription (Production)

      │   ├── Resource Group (WebApp)

      │   │   ├── App Service

      │   │   ├── SQL Database

      │   │   └── Storage Account

      │   └── Resource Group (Databases)

      │       ├── SQL Server

      │       └── Backup Vault

      └── Subscription (Dev)

          └── Resource Group (Testing)

              └── VM (Test Server)


      Role assignment: alice = Reader at "Databases" RG

      → alice can view SQL Server and Backup Vault only

Hands-on: Viewing & Assigning Roles

# List all built-in roles
az role definition list --query "[].{name:name, description:description}" --output table

# View role assignments in current subscription
az role assignment list --output table

# View specific user's role assignments
az role assignment list --assignee alice@contoso.com --output table

# Assign Contributor role to user at resource group scope
az role assignment create \
 --assignee alice@contoso.com \
 --role "Contributor" \
 --resource-group "myResourceGroup"

# Assign Reader role to service principal at subscription scope
az role assignment create \
 --assignee /subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{identity} \
 --role "Reader" \
 --scope /subscriptions/{subscriptionId}

# Remove role assignment
az role assignment delete \
 --assignee alice@contoso.com \
 --role "Contributor" \
 --resource-group "myResourceGroup"

Real-world Use Case

Scenario: E-commerce app with teams: DevOps (infra), Developers (code), DBAs.

Least Privilege Role Design:
• DevOps team: "Virtual Machine Contributor" in Prod RG (can manage VMs, but not delete)
• Developer team: "App Service Contributor" in Prod RG (manage web apps, not infrastructure)
• DBA team: Custom role "SQL DB Manager" (only SQL operations, no app/VM access)
• Everyone: "Reader" at subscription (view costs, compliance status)

Benefit: If developer's account is compromised, attacker can modify app but not drop database or delete VMs.

Summary

RBAC: Authorizes what authenticated users can do via roles and scopes.
Built-in roles: Owner, Contributor, Reader—use when standard job suffices.
Custom roles: Define granular permissions for specific needs.
Scope: Subscription > Resource Group > Resource—more restrictive is more secure.
Least Privilege: Grant minimum permissions needed; review regularly.

Interview Questions

Q (Beginner): What does RBAC stand for and what does it control?
A: Role-Based Access Control. It controls **authorization**—what authenticated users can do on resources.

Q (Beginner): What's the difference between Owner and Contributor?
A: Owner can manage access (assign roles), Contributor cannot. Owner > Contributor.

Q (Intermediate): Why should you avoid assigning roles at subscription scope?
A: Violates least privilege. Subscription scope is too broad. Assign at resource group or resource scope to limit blast radius.

Q (Intermediate): How would you design RBAC for a startup with limited Azure resources?
A: Start with broad roles (Owner for lead dev), implement granular custom roles as team grows. Use service principals for apps, managed identities for VMs. Review quarterly.

Q (Scenario): A contractor needs temporary access (1 month) to test a database. What's the secure RBAC approach?
A: Assign custom "DB Test Reader" role at resource scope (not RG), set expiration date (Azure AD PIM), use Conditional Access (require MFA + managed device), audit access logs.