Azure RBAC
Azure Role-Based Access Control (RBAC) is a system in Azure that enables you to manage access to resources by assigning roles to users, groups, and service principals. With RBAC, you can define and control what actions are allowed on Azure resources, ensuring that only authorized users have the appropriate level of access to resources.
RBAC works by defining roles that have specific permissions, which are then assigned to users, groups, or service principals. It helps enforce the principle of least privilege, ensuring users only have the permissions they need to perform their tasks.
Azure RBAC Components
1. Azure Actions
In the context of Azure RBAC, actions define the operations a user can perform on Azure resources. Actions are the permissions granted to a role for performing specific tasks on resources.
Actions in Azure can be categorized into the following:
Read: Permissions to view or query resources.
Write: Permissions to modify or create resources.
Delete: Permissions to remove resources.
Action: Permissions to invoke an action on a resource, such as restarting a virtual machine or running a function.
Each role in Azure RBAC has a set of actions that define the permissions for that role. For example, the Reader role may have read access to resources, while the Contributor role has permissions to create, modify, or delete resources.
2. Action Bundles
An Action Bundle is a group of related actions that are often grouped together to simplify permission management. These bundles represent common sets of permissions related to a particular service or resource. For instance, actions related to storage management, such as creating and deleting storage accounts, may be bundled together.
Instead of defining each individual action, Azure RBAC uses action bundles to make role definitions more manageable and less granular. Action bundles help define common sets of permissions to apply across a service or set of resources, making role management more efficient.
3. Role-Based Actions are Applied
Azure RBAC roles are applied to resources to determine what actions a user can perform. When a role is assigned to a user, group, or service principal, the permissions within the role are applied to those entities. These actions can be applied at different scopes (such as subscription, resource group, or individual resource level).
RBAC allows fine-grained control of who can perform specific actions on resources. For example:
Owner: Can perform any action on the resources, including managing access.
Contributor: Can manage resources but cannot grant access.
Reader: Can only view resources, but cannot modify or delete them.
Roles are Given Based on the Following Elements:
1. Service Principal
A Service Principal is a security identity used by applications or automated tools to access Azure resources. Service principals are commonly used for managing Azure resources through automation (such as Azure CLI, PowerShell, or Azure DevOps pipelines).
A service principal can be assigned an Azure RBAC role just like a user.
It allows applications to authenticate securely to Azure resources without needing user credentials.
Service principals are typically used for non-interactive access scenarios (e.g., automated tasks, APIs, or managed identities).
When defining roles in RBAC for service principals, you assign them the necessary actions (permissions) to perform specific tasks on resources.
2. Scope
Scope in Azure RBAC defines the boundary or level at which the role is assigned. The scope determines which resources the role and its permissions apply to. The three primary levels of scope are:
Subscription: The highest level, where permissions can be assigned to a user for access to resources across the entire subscription.
Resource Group: A collection of resources grouped together for easier management. Roles assigned at this level affect all resources within that resource group.
Resource: The individual Azure resource (e.g., a virtual machine, database, or storage account). Roles can be assigned at the resource level to control access to a specific resource.
Scope helps control how granular the permissions are, providing flexibility in managing access across your Azure environment.
3. Role Definition
A Role Definition is a collection of permissions (actions) that a specific role can perform. It defines the allowed actions that users or service principals can carry out on resources. In Azure, there are built-in roles like Owner, Contributor, Reader, and more specialized roles like Virtual Machine Contributor, which define specific sets of permissions for resource management.
Custom Roles: You can also create custom roles to define a more tailored set of permissions. This is useful when the built-in roles do not fully meet your needs.
Each role definition includes the following components:
Actions: What actions the role can perform.
NotActions: What actions the role cannot perform (i.e., deny).
Data Actions: Actions related to data access and management (e.g., read/write to blob storage).
NotDataActions: Restrictions related to data actions.
Last updated