Demystifying Azure Security - Custom RBAC Roles

This blog post is part of the Demystifying Azure Security series. All posts in the series can be found here: Demystifying Azure Security - Series Index

Before going through this blog, please ensure that you have visited the basics of RBAC Roles in general, explained in a primer here: Demystifying Azure Security - RBAC Roles.

This blog explains an easy approach to understand and create your own Custom RBAC Roles in Azure (ARM model). We will inspect an existing simple role and will reverse engineer the way to create Custom RBAC Roles.

Inspecting Existing Role's Definition

Start by inspecting any existing Role's Definition. To do this run the cmdlet Get-AzureRMRoleDefinition and provide the name of any built-in RBAC Role. For this blog, run the below script to inspect the "Reader" and "Virtual Machine Contributor" roles.

Login-AzureRMAccount

Get-AzureRMRoleDefinition -Name "Reader" | ConvertTo-Json | Out-File C:\rbacrole-reader.json

Get-AzureRMRoleDefinition -Name "Virtual Machine Contributor" | ConvertTo-Json | Out-File C:\rbacrole-VMContributor.json

If you open and inspect the "rbacrole-reader.json" file you will see the JSON similar to below:

{
    "Name":  "Reader",
    "Id":  "aaaa11a1-3333-48ef-bd42-f606fba81ae7",
    "IsCustom":  false,
    "Description":  "Lets you view everything, but not make any changes.",
    "Actions":  [
                    "*/read"
                ],
    "NotActions":  [

                   ],
    "AssignableScopes":  [
                             "/"
                         ]
}

Notice above that there are below sections in the definition:

1. Name - Name of the role
2. Id - unique guid for the role
3. IsCustom - boolean value. "true" for the Custom Roles and "false" for the built-in roles
4. Description - description of the role
5. Actions - Allowed list of actions for the Role
6. NotActions - Not Allowed list of actions for the Role
7. AssignableScopes - Scope at which this role can be assigned. E.g. all the subscription Ids. It's mandatory that the RBAC role contains the explicit subscription IDs where it is used otherwise you will not be able to use the role.

Understanding Actions and NotActions

As mentioned before, Actions describe the allowed list of action for the Role whereas the NotActions describe the not allowed actions for the Role. You can use wildcard * and special syntax to define the Actions and NotActions, as per the Microsoft documentation here: Create custom roles for Azure Role-Based Access Control:

Operation strings that contain wildcards (*) grant access to all operations that match the operation string. For instance:

• */read grants access to read operations for all resource types of all Azure resource providers.
• Microsoft.Compute/* grants access to all operations for all resource types in the Microsoft.Compute resource provider.
• Microsoft.Network/*/read grants access to read operations for all resource types in the Microsoft.Network resource provider of Azure.
• Microsoft.Compute/virtualMachines/* grants access to all operations of virtual machines and its child resource types.
• Microsoft.Web/sites/restart/Action grants access to restart websites.

Use Get-AzureRmProviderOperation (in PowerShell) or azure provider operations show (in Azure CLI) to list operations of Azure resource providers. You may also use these commands to verify that an operation string is valid and to expand wildcard operation strings.

Get-AzureRMProviderOperation Microsoft.Compute/virtualMachines/*/action | FT Operation, OperationName

Get-AzureRMProviderOperation Microsoft.Network/*

Defining a Custom role

Let's define a custom role, who can start or restart a VM in Azure but can't open a support ticket.

Save the following code as "yourCustomRole01.json" file on your C drive (or any other location).

{
  "Name": "Virtual Machine Start and Restart",
  "Id": "7ed03a9f-b372-4341-ba8d-38ef8e614038",
  "IsCustom": true,
  "Description": "Can restart virtual machines but can't open support tickets.",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/restart/action"
  ],
  "NotActions": [
    "Microsoft.Support/*"
  ],
  "AssignableScopes": [
    "/subscriptions/aaaaaaaa-1111-1111-1111-111111111111",
    "/subscriptions/aaaaaaaa-2222-2222-2222-222222222222",
    "/subscriptions/aaaaaaaa-3333-3333-3333-333333333333/resourceGroups/RG-Prod-USE2"
  ]
}

Notice the Action and NotAction area are set as per the requirements.

Also, note that under Assignable Scope the role is available for assignment to all Resources and Resource Groups in the first two subscriptions but only in Resource Group named "RG-Prod-USE2" for the third subscription in the list.

Creating New Custom role

Once you have the definition ready in a JSON file, you can use the "New-AzureRMRoleDefinition" cmdlet to create the Custom Role Definition, as shown below. Make sure to alter the path to the json file as per your environment.

New-AzureRMRoleDefinition -InputFile "C:\yourCustomRole01.json"

Now you will be able to use this new Custom Role while assigning access to someone. You will be able to tweak the access and provide only the access that you need to your internal and external resources.