Azure Resource Manager built-in roles such as Owner, Contributor, and User Access Administrator grant extensive permissions that can pose a significant security risk.

Why is this an issue?

Azure Resource Manager offers built-in roles that can be assigned to users, groups, or service principals. Roles such as Owner (8e3af657-a8ff-443c-a75c-2fe8c4bcb635), Contributor (b24988ac-6180-42a0-ab88-20f7382dd24c), and User Access Administrator (18d7d88d-d35e-4fb5-a5c3-7773c20a72d9) grant broad permissions — including the ability to reset passwords for all users or manage every resource in a subscription. Assigning these roles without following the principle of least privilege fails to separate duties and creates a large attack surface.

What is the potential impact?

If an account holding a high-privilege role is compromised, an attacker gains extensive control over the Azure environment. This can lead to unauthorized access, data exfiltration, resource modification or deletion, and disruption of business operations.

How to fix it

Code examples

The following code assigns a high-privilege built-in role to a principal, granting broad permissions across the Azure environment.

Noncompliant code example

resource "azurerm_role_assignment" "example" {
  scope                = azurerm_resource_group.example.id
  role_definition_name = "Owner" # Noncompliant
  principal_id         = data.azuread_user.example.id
}

Compliant solution

resource "azurerm_role_assignment" "example" {
  scope                = azurerm_resource_group.example.id
  role_definition_name = "Azure Maps Data Reader"
  principal_id         = data.azuread_user.example.id
}

Resources

Documentation

Standards