Role-based access control (RBAC) facilitates the management of access to Azure resources by entities referred to as security principals, as well as controls what actions those entities can
perform. In addition to determining who can do what, in Azure, access can be granted to users, groups, service principals, and managed identities through role assignments, which are then applied at a scope, such as a management group, subscription, a resource group, or even an individual resource. Azure RBAC is applicable to the management of resources created in the Azure Resource Manager (ARM) deployment model.
A role is the definition of what actions are allowed and/or denied. RBAC is configured by selecting a role and associating the role with a security principal, such as a user, group, or service principal. Then this combination of role and security principal is applied to a scope of a management group, subscription, a resource group, or a specific resource through a role assignment.
Azure RBAC also includes role inheritance, where child resources inherit the role assign- ments of any parents. For example, if a user is granted Reader access to a subscription, that user will have Reader access to all the resource groups and resources in that subscription. If a managed identity is granted Contributor rights for a single resource group, that security princi- pal can only interact with that resource group and its child resources, but it cannot create new resource groups or access resources in other resource groups unless an explicit role assignment is made.
Azure RBAC uses the additive model. As you begin to apply roles to security principals in Azure, it is not uncommon to have overlapping assignments where a security principal is
assigned a different role assignment at both a parent and a child scope. For example, if a user is granted Contributor rights at the management group scope and then is granted Reader rights in a subscription, the user will still have Contributor rights across the subscription along with
Contributor rights to any other subscriptions under the management group. Another way to think of this is that the most privileged access right takes precedence.
Before a security principal such as a user or group can interact with Azure resources, they must be granted access at a scope through a role assignment. Once a security principal has been granted access, it can perform any action that it has rights to perform. It is always recom- mended to provide the minimum privileges to an object or user to perform actions as needed. Figure 1-14 shows a suggested access pattern that adheres to the principles of least privilege. In this example, a security group in Entra ID, called IT Audit, is granted Reader access rights at the subscription scope, granting members of the group Reader access to all resource groups and resources in the subscription. A security group called Application Admins is granted Contribu- tor access rights to only selected resource groups. Another security group called Application Owners is granted Owner access rights to selected resource groups as well. By using multiple security groups and role assignments at the proper scope, access can be granted in the future just by updating the security group membership in Entra ID.
FIGURE 1-14 Azure RBAC role assignments
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
