# 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://ghoulsec.gitbook.io/ghoulsec-vault/exam-prep-notes/az-900/azure-services/azure-security-services/azure-rbac.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.