The specific permissions that are applied to a resource with RBAC are defined in a role definition. A role definition contains the list of permissions—or declared permissions—and those permissions define what actions can or cannot be performed against a type of resource, such as read, write, or delete.
Role definitions, or roles, can be either built-in or custom. There are a number of built-in role definitions in Azure. An example of a built-in role is the Owner role, which includes permis- sions to manage resources, security, and the application of role assignments. Also, there are
built-in roles with limited permission sets, such as a Storage Blob Data Reader, which allows the assigned security principal to only read and list containers and blobs.
There are many built-in roles in Azure, which can be found at https://docs.microsoft.com/ azure/role-based-access-control/built-in-roles. Microsoft adds new built-in roles as services evolve or as new services are introduced.
IMPORTANT AZURE ROLES AND ENTRA ID ROLES
RBAC roles are different from the Entra ID administrative roles. RBAC roles are used to manage access and allow or restrict users to Azure resources, while Entra ID administrative roles are used to allow or restrict admins to perform identity tasks, such as creating new users, reset- ting the users’ passwords, and so on. For example, a user who is granted Global Administrator rights in Entra ID does not have permissions to create resources in Azure, but they can perform all the identity tasks for an Entra tenant.
The access rights are controlled with a logical boundary known as scope. For example, to grant a user Contributor rights to all the resources in a resource group, the Contributor role can be assigned to the group at the resource group scope where it is then inherited by all of the resources in the resource group.
There are four scopes at which RBAC can be applied, and scopes are structured in a parent- child relationship where RBAC is inherited by any child scopes. The highest scope, or top-most parent scope, is a management group.
EXAM TIP
Management groups are not applicable in all scenarios, and in some cases, a subscription will be the highest scope you will work with when applying role assignments. This will be determined by your organization’s Azure landing zone deployment stamp.
Under the management group are more management groups and/or subscriptions; under subscriptions are resource groups; and under resource groups are resources. Figure 1-15 shows a sample hierarchy with a parent management group and two subscriptions, each with a resource group and child resources. Note that you can also create another management group under a root management group. An Entra ID tenant can support up to 10,000 management groups.
IMPORTANT RBAC INHERITANCE
The concept of RBAC inheritance is critical. Granting a user access to the Owner role at the management group scope will grant that user Owner rights to all the resources (management groups, subscriptions, resource groups, and resources) under the management group that is inclusive of all the resource groups and resources within them.
FIGURE 1-15 Scope hierarchy
After you have identified the role, security principal, and scope at which the role will be assigned, you can make the assignment. Remember, security principals do not have access to Azure resources until a role assignment is made, and that access can be revoked by removing a role assignment.
IMPORTANT ROLE ASSIGNMENT LIMITS
You can have up to 4,000 role assignments in each subscription, and you can have up to 500 role assignments per management group. These limits are independent of each other and have been adjusted over time. Check the latest quotas and limits at https://learn.microsoft. com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits.
To create and remove role assignments, you must have Microsoft.Authorization/role- Assignments/* permission at the necessary scope. This permission is granted through the Owner or User Access Administrator built-in roles, or it can be included in custom roles.
NOTE AZURE ROLE ASSIGNMENTS
With Azure role assignments, there is no way to revoke access rights at a child scope through the application of a more restrictive role assignment because the role assignment is inherited from the parent. It is, however, possible to apply a deny assignment at a scope when using Azure Blueprints, Deployment Stacks, and resource locks. Deny assignments are evaluated before role assignments and can be used to exclude service principals from accessing child scopes. For more information, see https://learn.microsoft.com/en-us/azure/governance/ blueprints/tutorials/protect-new-resources.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
