Azure RBAC role assignments grant permissions over a scope — a set of resources such as a resource group, subscription, or management group. Assigning roles at subscription or management group scope grants access to all resources within that entire boundary and should be avoided in favour of narrower scopes.

Why is this an issue?

The widest scopes a role can be assigned to are the Subscription scope, which grants access to all resources in a subscription, and the Management Group scope, which grants access to all resources across all subscriptions in that group. Assigning roles at these wide scopes violates the principle of least privilege. In the event of a compromised identity, an attacker gains access to a large portion of the infrastructure rather than a narrowly scoped set of resources.

What is the potential impact?

If an identity with a subscription- or management-group-scoped role assignment is compromised, an attacker gains permissions over all resources within that scope. This can lead to unauthorized access, data exfiltration, or destruction of resources across the entire subscription or management group.

How to fix it

Code examples

The following code creates a role assignment scoped to an entire subscription or management group, granting the assigned principal access to all resources within that scope.

Noncompliant code example

resource "azurerm_role_assignment" "example" {
  scope                = data.azurerm_subscription.primary.id # Noncompliant
  role_definition_name = "Reader"
  principal_id         = data.azuread_user.user.object_id
}

Compliant solution

resource "azurerm_role_assignment" "example" {
  scope                = azurerm_resource_group.example.id
  role_definition_name = "Reader"
  principal_id         = data.azuread_user.user.object_id
}

Resources

Documentation

Standards