Why is this an issue?
Azure Resource Manager allows creating custom roles that can be assigned to users, groups, or service principals. A custom role that grants access
to all resources of a subscription will have the same capabilities as the built-in Owner role.
It’s recommended to limit the number of subscription owners in order to mitigate the risk of being breached by a compromised owner. Having a custom
role that grants subscription Owner capabilities makes it way more difficult to enforce this limitation.
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
(*)
Recommendations
- Apply the least privilege principle by creating a custom role with as few permissions as possible.
- As custom role 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.
Noncompliant code example
resource "azurerm_role_definition" "example" { # Sensitive
name = "example"
scope = data.azurerm_subscription.primary.id
permissions {
actions = ["*"]
not_actions = []
}
assignable_scopes = [
data.azurerm_subscription.primary.id
]
}
Compliant solution
resource "azurerm_role_definition" "example" {
name = "example
scope = data.azurerm_subscription.primary.id
permissions {
actions = ["Microsoft.Compute/*"]
not_actions = []
}
assignable_scopes = [
data.azurerm_subscription.primary.id
]
}
Resources
