Azure RBAC
Azure provides authentication using Azure Active Directory for its resources. Once an identity has been authenticated, the resources the identity will be allowed to access should be decided. This is known as authorization. Authorization evaluates the permissions that have been afforded to an identity. Anybody with access to an Azure subscription should be given just enough permissions so that their specific job can be performed, and nothing more.
Authorization is popularly also known as RBAC. RBAC in Azure refers to the assigning of permissions to identities within a scope. The scope could be a management group, a subscription, a resource group, or individual resources.
RBAC helps in the creation and assignment of different permissions to different identities. This helps in segregating duties within teams, rather than everyone having all permissions. RBAC helps in making people responsible for their job only, because others might not even have the necessary access to perform it. It should be noted that providing permissions at a greater scope automatically ensures that child resources inherit those permissions. For example, providing an identity with read access to a resource group means that the identity will have read access to all the resources within that group, too.
Azure provides three general-purpose, built-in roles. They are as follows:
The owner role, which has full access to all resources
The contributor role, which has access to read/write resources
The reader role, which has read-only permissions to resources
There are more roles provided by Azure, but they are resource-specific, such as the network contributor and security manager roles.
To get all roles provided by Azure for all resources, execute the Get-AzRoleDefinition command in the PowerShell console.
Each role definition has certain allowed and disallowed actions. For example, the owner role has all actions permitted; no action is prohibited:
PS C:\Users\riskaria> Get-AzRoleDefinition -Name "Owner"
Name : Owner
Id : 8e3af657-a8ff-443c-a75c-2fe8c4bcb635
IsCustom : False
Description : Lets you manage everything, including access to resources.
Actions : {*}
NotActions : {}
DataActions : {}
NotDataActions : {}
AssignableScopes : {/}
Each role comprises multiple permissions. Each resource provides a list of operations. The operations supported by a resource can be obtained using the Get-AzProviderOperation cmdlet. This cmdlet takes the name of the provider and resource to retrieve the operations:
PS C:\Users\riskaria> Get-AzProviderOperation -OperationSearchString "Microsoft.Insights/*" | select Operation
This will result in the following output:
PS C:\Users\riskaria> Get-AzProviderOperation -OperationSearchString "Microsoft.Insights/*" | select Operation
Operation
---------
Microsoft.Insights/Metrics/Action
Microsoft.Insights/Register/Action
Microsoft.Insights/Unregister/Action
Microsoft.Insights/ListMigrationDate/Action
Microsoft.Insights/MigrateToNewpricingModel/Action
Microsoft.Insights/RollbackToLegacyPricingModel/Action
.
.
.
.
.
.
.
.
Microsoft.Insights/PrivateLinkScopes/PrivateEndpointConnectionProxies/Read
Microsoft.Insights/PrivateLinkScopes/PrivateEndpointConnectionProxies/Write
Microsoft.Insights/PrivateLinkScopes/PrivateEndpointConnectionProxies/Delete
Microsoft.Insights/PrivateLinkScopeOperationStatuses/Read
Microsoft.Insights/DiagnosticSettingsCategories/Read
The output shown here provides all the actions available within the Microsoft.Insights resource provider across its associated resources. The resources include Metrics, Register, and others, while the actions include Read, Write, and others.
Let's now look at custom roles.
Custom roles
Azure provides numerous out-of-the-box generic roles, such as owner, contributor, and reader, as well as specialized resource-specific roles, such as virtual machine contributor. Having a reader role assigned to a user/group or service principal will mean reader permissions being assigned to the scope. The scope could be a resource, resource group, or a subscription. Similarly, a contributor would be able to read as well as modify the assigned scope. A virtual machine contributor would be able to modify virtual machine settings and not any other resource settings. There are, however, times when existing roles might not suit our requirements. In such cases, Azure allows the creation of custom roles. They can be assigned to users, groups, and service principals and are applicable to resources, resource groups, and subscriptions.
Custom roles are created by combining multiple permissions. For example, a custom role can consist of operations from multiple resources. In the next code block, a new role definition is being created, but instead of setting all properties manually, one of the existing "Virtual Machine Contributor" roles is retrieved because it almost matches with the configuration of the new custom role. Avoid using the same name as built-in roles, as that would create conflict. Then, the ID property is nullified and a new name and description is provided. The code also clears all the actions, adds some actions, adds a new scope after clearing the existing scope, and finally creates a new custom role:
$role = Get-AzRoleDefinition "Virtual Machine Contributor"
$role.Id = $null
$role.Name = "Virtual Machine Operator"
$role.Description = "Can monitor and restart virtual machines."
$role.Actions.Clear()
$role.Actions.Add("Microsoft.Storage/*/read")
$role.Actions.Add("Microsoft.Network/*/read")
$role.Actions.Add("Microsoft.Compute/*/read")
$role.Actions.Add("Microsoft.Compute/virtualMachines/start/action")
$role.Actions.Add("Microsoft.Compute/virtualMachines/restart/action")
$role.Actions.Add("Microsoft.Authorization/*/read")
$role.Actions.Add("Microsoft.Resources/subscriptions/resourceGroups/read")
$role.Actions.Add("Microsoft.Insights/alertRules/*")
$role.Actions.Add("Microsoft.Support/*")
$role.AssignableScopes.Clear()
$role.AssignableScopes.Add("/subscriptions/548f7d26-b5b1-468e-ad45-6ee12accf7e7")
New-AzRoleDefinition -Role $role
There is a preview feature available in the Azure portal that you can use to create custom RBAC roles from the Azure portal itself. You have the option to create roles from scratch, clone an existing role, or start writing the JSON manifest. Figure 5.3 shows the Create a custom role blade, which is available at IAM > +Add section:
Figure 5.3: Creating custom roles from the Azure portal
This makes the process of custom role creation hassle-free.
How are locks different from RBAC?
Locks are not the same as RBAC. RBAC helps in allowing or denying permissions for resources. These permissions relate to performing operations, such as read, write, and update operations on resources. Locks, on the other hand, relate to disallowing permissions to configure or delete resources.
In the next section, we will be discussing Azure Blueprints, which helps us with the orchestration of artifacts, such as role assignments, policy assignments, and more, that we have discussed so far.