Azure Role Based Access Control (RBAC)

In this article, I am covering some of the important concepts behind Azure Role Based Access Control.

Security Principals:

An object that represents an individual, collection of individuals, an application or a service that requires access to an Azure resource, for example Azure WebApp, Azure VM or Blob Storage.

Now, these applications and services can be represented as a thing called a Service Principal.

Scope:

The scope is the boundary that access applies to the following levels:

• Management Group
• Subscription
• Resource Group
• Resource

Why Azure RBAC?

Principle of least privilege is that only grant that access which is actually required rather than that access that might be required. And Role-based access control allows you to reduce the chance of unauthorised actions being performed. It also allows you to reduce the chance of accidental actions being performed.

How RBAC determines the Access?

• Security Principal acquires token for ARM.
• REST API call is made to ARM with a token.
• Azure Resource Manager then retrieves all role assignments and deny assignments that apply to the resource against to which the action is occurring.
• Azure Resource Manager then determines role assignments that apply to the security principal for this particular resource.
• If the security principal doesn’t have a role with that action in that requested scope, access will not be granted.

Another important thing to notice here is Azure AD administrator roles are different from Azure role-based access control roles.

• Use Azure role-based access control roles to manage permissions to Azure resources.
• Use Azure AD administrator roles to manage permissions to Azure Active Directory resources.

4 Fundamental RBAC Roles:

• Owner role can manage everything, including access to resources.
• Contributor can manage everything except access to resources
• Reader has read-only access to everything.
• User Access Administrator can manage user access to Azure resources.

How can we assign RBAC roles?

With PowerShell :

Use the New-AzureRMRoleAssignment command to grant access. Access is granted by assigning the appropriate RBAC role to them at the right scope.

New-AzureRmRoleAssignment -ResourceGroupName rg1 -SignInName allen.young@live.com -RoleDefinitionName Reader -AllowDelegation

RBAC Auditing:

Role-based access control auditing : Whenever a change is made to role assignments or role definitions within a subscription, details of those changes are going to be written to the Azure Activity Log. The following RBAC operations are written to Azure Activity Log:

• Creating role assignments,
• Deleting role assignments,
• Creating or updating custom role definitions,
• Deleting custom role definitions.

We can query the logs using the portal, using Azure CLI, PowerShell or the Azure Monitor REST API.

To list all the roles that are assigned to a specified user and the roles that are assigned to the groups to which the user belongs, use Get-AzRoleAssignment.

Get-AzRoleAssignment -SignInName someonw@example.com -ExpandPrincipalGroups | FL DisplayName, RoleDefinitionName, Scope

To view RBAC Activity Log

Azure Policy

Azure policies allow you to enforce different rules and effects over resources. They can control the types of resources that can be deployed, and they can be used to verify whether a particular resource exists and to deploy the resource if it is not present using an ARM template. So, if we think of it this way :

RBAC focuses on what can be done within a scope. e.g.

• allow a service to deploy a virtual machine
• or allow members of a particular Azure AD group to start a virtual machine.

Azure policies can control the specifics of what is done at a particular scope. e.g.:

• which VM SKUs can be deployed.
• How resources such as virtual machines are named.

So with RBAC, I can give you the permission to deploy a virtual machine. With Azure policies, I can specify what type of virtual machine and how you name the virtual machine. Example 1: Create a policy definition by using a policy file:

{
   “if”: {
     “field”: “location”,
     “notIn”: [“eastus”, “westus”, “centralus”]
   },
   “then”: {
     “effect”: “audit”
   }
}
New-AzureRmPolicyDefinition -Name ‘LocationDefinition’ -Policy C:\LocationPolicy.json

The New-AzureRmPolicyAssignment cmdlet creates a policy assignment. Specify a policy and scope.

Creating Custom Roles

In terms of creating custom roles, your best practice is to base the custom role on an existing role, and then once you’ve got an existing role, figure out what you want to change about the existing role and then make those modifications. You need the Owner role or the User Access Administrator role within the subscription to actually go and create a custom role.

The New-AzureRmRoleDefinition cmdlet creates a custom role in Azure Role-Based Access Control.

New-AzureRmRoleDefinition -InputFile C:\Temp\roleDefinition.json