2.1.3.1. Design for role-based access control (RBAC)

💡 First Principle: A robust authorization system defines who can do what, and where, by assigning specific permissions (roles) to identities (principals) at a defined scope, thereby enforcing the principle of least privilege.

Scenario: You are designing the access control for a production application's resource group. The DevOps team needs "Contributor" access to manage resources, but the security team wants to ensure no one, including DevOps, can delete any Virtual Networks within that resource group.

Azure RBAC provides fine-grained access management for Azure resources.

RBAC Core Components:

1. Security Principal (Who):
   • Definition: Identities that request access—users, groups, service principals (for applications), and managed identities (for Azure services).
   • Design Consideration: Organize these using groups for easier management and automation, minimizing direct assignments to individual users.
2. Role Definition (What):
   • Definition: A set of permissions. Azure provides built-in roles:
     • Owner: Full management, including access control.
     • Contributor: Manage resources, not access.
     • Reader: View resources only.
     • User Access Administrator: Manage access assignments.
   • Design Consideration: Use built-in roles for standard needs. Create custom roles when built-ins are too broad or too narrow, tailoring permissions to specific job functions.
3. Scope (Where):
   • Definition: Defines where access applies: management group, subscription, resource group, or individual resource.
   • Design Consideration: Assign roles at the lowest possible scope to reduce risk and enforce least privilege.

⚠️ Common Pitfall: Assigning roles at a higher scope than necessary (e.g., giving a user "Contributor" on a subscription when they only need it on a single resource group). This violates the principle of least privilege and increases the potential blast radius of a compromised account.

Key Trade-Offs:

• Built-in Roles vs. Custom Roles: Built-in roles are simpler to manage but may be too permissive. Custom roles provide precise permissions but require more effort to create and maintain.

Practical Implementation: Creating a Custom Role with Azure CLI

# 1. Get the JSON definition for the built-in 'Reader' role
az role definition list --name "Reader" > reader_role.json

# 2. Modify reader_role.json to add a specific write permission
# (e.g., "Microsoft.Storage/storageAccounts/write")

# 3. Create the custom role from the modified JSON file
az role definition create --role-definition @reader_role.json

Reflection Question: How does designing for Azure RBAC (using built-in roles, custom roles, and deny assignments at appropriate scopes) fundamentally enable precise control by defining who can do what, and where, thereby enforcing the principle of least privilege and ensuring secure resource management?