Azure Management: Role-Based Access Control (RBAC)

Introduction to RBAC

Azure Role-Based Access Control (RBAC) helps you manage who has access to what resources in Azure. It's a fundamental part of Azure security, allowing you to grant users, groups, and service principals the permissions they need to perform their jobs, and no more.

RBAC is used to grant granular access to Azure resources. This is different from Azure subscription management, which controls access to subscription-level resources. With RBAC, you can control access at various levels, such as the management group, subscription, resource group, or even a single resource.

Roles

A role definition consists of a set of permissions. Azure RBAC has three fundamental types of roles:

• Built-in roles: These are predefined roles provided by Azure, such as Owner, Contributor, Reader, User Access Administrator, and Security Admin.
• Custom roles: You can create your own custom roles if the built-in roles don't meet your specific needs.
• The Owner role: This role has full access to all resources, including the right to delegate access to others.
• The Contributor role: This role can create and manage all types of Azure resources but cannot grant access to others.
• The Reader role: This role allows viewing all Azure resources but cannot make any changes.
• The User Access Administrator role: This role can manage user access to Azure resources.

Permissions

Permissions define what operations are allowed on a resource. Permissions are grouped into roles. Azure RBAC includes a set of permissions, such as:

• Microsoft.Compute/virtualMachines/read - Allows reading virtual machines.
• Microsoft.Storage/storageAccounts/write - Allows writing to storage accounts.
• Microsoft.Network/publicIPAddresses/delete - Allows deleting public IP addresses.

A role can contain many permissions. When you assign a role to a principal, you are granting them all the permissions included in that role.

Scope

Scope is the set of resources to which access applies. Azure RBAC has four levels of scope:

• Management group: Applies policies and controls to multiple subscriptions.
• Subscription: Applies policies and controls to all resource groups and resources within the subscription.
• Resource group: Applies policies and controls to all resources within the resource group.
• Resource: Applies policies and controls to a single resource.

Access is inherited down the hierarchy. For example, permissions assigned at the subscription scope are inherited by all resource groups and resources within that subscription.

Role Assignments

A role assignment is the process of granting a principal (user, group, service principal, or managed identity) a specific role at a specific scope. This is how you effectively grant permissions.

To create a role assignment, you need:

1. The security principal that needs access.
2. The role definition to assign.
3. The scope at which to assign the role.

You can manage role assignments through the Azure portal, Azure CLI, Azure PowerShell, or REST API.

az role assignment create --role "Reader" --assignee "user@example.com" --resource-group "myResourceGroup"

Custom Roles

If Azure's built-in roles don't meet your organization's needs, you can create custom roles. Custom roles allow you to define a specific set of permissions that align with your security requirements.

Custom roles are defined using JSON. They can be created at the subscription or resource group scope.

Key properties of a custom role definition:

• Name: The unique name of the custom role.
• Description: A brief description of the role.
• Actions: The permissions that the role grants.
• NotActions: Permissions that are excluded from the role.
• DataActions: Data operations that the role grants (e.g., accessing blob data).
• NotDataActions: Data operations that are excluded.

Best Practices for RBAC

Following best practices ensures effective security and manageability:

• Principle of Least Privilege: Grant only the minimum permissions required for a user or service to perform their task.
• Use Groups: Assign roles to Azure AD groups rather than individual users. This simplifies management as you only need to manage group membership.
• Use Specific Scopes: Assign roles at the most specific scope necessary. Avoid assigning broad roles at the subscription level unless truly required.
• Regularly Review Assignments: Periodically review role assignments to ensure they are still necessary and appropriate. Remove stale assignments.
• Leverage Built-in Roles: Use built-in roles whenever possible before creating custom roles.
• Use Managed Identities for Applications: For applications running in Azure, use managed identities instead of service principals with stored credentials.