Why is this an issue?

Defining a custom role for a Subscription or a Management group that allows all actions will give them the same capabilities as the built-in Owner role.

This rule raises an issue when a custom role has an assignable scope set to a Subscription or a Management Group and allows all actions (*).

To reduce the risk of intrusion of a compromised owner, it is recommended to limit the number of subscription owners.

How to fix it

Code examples

Noncompliant code example

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Authorization/roleDefinitions",
      "apiVersion": "2022-04-01",
      "properties": {
        "permissions": [
          {
            "actions": ["*"],
            "notActions": []
          }
        ],
        "assignableScopes": [
          "[subscription().id]"
        ]
      }
    }
  ]
}

targetScope = 'managementGroup'

resource roleDef 'Microsoft.Authorization/roleDefinitions@2022-04-01' = { // Sensitive
  properties: {
    permissions: [
      {
        actions: ['*']
        notActions: []
      }
    ]

    assignableScopes: [
      managementGroup().id
    ]
  }
}

Compliant solution

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "name": "example",
      "type": "Microsoft.Authorization/roleDefinitions",
      "apiVersion": "2022-04-01",
      "properties": {
        "permissions": [
          {
            "actions": ["Microsoft.Compute/*"],
            "notActions": []
          }
        ],
        "assignableScopes": [
          "[subscription().id]"
        ]
      }
    }
  ]
}

targetScope = 'managementGroup'

resource roleDef 'Microsoft.Authorization/roleDefinitions@2022-04-01' = {
  properties: {
    permissions: [
      {
        actions: ['Microsoft.Compute/*']
        notActions: []
      }
    ]

    assignableScopes: [
      managementGroup().id
    ]
  }
}

Going the extra mile

Here is a list of recommendations that can be followed regarding good usages of roles:

• Apply the least privilege principle by creating a custom role with as few permissions as possible.
• As custom roles can be updated, gradually add atomic permissions when required.
• Limit the assignable scopes of the custom role to a set of Resources or Ressource Groups.
• When necessary, use the built-in Owner role instead of a custom role granting subscription owner capabilities.
• Limit the assignments of Owner roles to less than three people or service principals.

Resources

Documentation

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2021 Category A4 - Insecure Design
• OWASP Top 10 2017 Category A5 - Broken Access Control
• MITRE, CWE-266 - Incorrect Privilege Assignment
• Azure Documentation - Azure custom roles
• Azure Documentation - Best practices for Azure RBAC