Support for MCA billing roles in azurerm_role_assignment

[keesvandenhoekict]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

This request is to add support in azurerm_role_assignment to support billing role assignment for MCA(Microsoft Customer Agreement) customers. The equivalent change for Enterprise Agreement customers (enrollment accounts) has been realised in #10547

New or Affected Resource(s)

• azurerm_role_assignment

Potential Terraform Configuration

resource "azurerm_role_assignment" "create_subscription_role_on_invoice_section" {
  scope                = "providers/Microsoft.Billing/billingAccounts/<SECRET1>/billingProfiles/<SECRET-2>/invoiceSections/<“SECRET-3>
  role_definition_name = "Azure subscription creator"
  principal_id         = azurerm_user_assigned_identity.example.principal_id
}

References

• https://github.com/hashicorp/terraform-provider-azurerm/issues/10547
• https://docs.microsoft.com/en-us/rest/api/billing/2019-10-01-preview/billing-role-assignments/add-by-billing-account
• https://docs.microsoft.com/en-us/rest/api/billing/2019-10-01-preview/billing-role-assignments/add-by-billing-profile
• https://docs.microsoft.com/en-us/rest/api/billing/2019-10-01-preview/billing-role-assignments/add-by-invoice-section

[b-c-lucas]

@jackofallops, would this be a matter of adding 3 levels of scoping to azurerm_role_assignment like done in #10890?

Scopes:

• billing account:
  • "providers/Microsoft.Billing/billingAccounts/abc-123"
• billing profile:
  • "providers/Microsoft.Billing/billingAccounts/abc-123/billingProfiles/def-456"
• invoice section:
  • "providers/Microsoft.Billing/billingAccounts/abc-123/billingProfiles/def-456/invoiceSections/ghi-789"

[eastlondoner]

Ran into this today. I wonder if the validation should be relaxed here. There is already a function: ParseAzureResourceIDWithoutSubscription - this could be sufficient validation for role assignments - rather than finding every case of resource ids without subscription and implementing separate role assignment validation for them.

An example of another entity that does not have a subscription but I think should support role assignment are tenants.

e.g. I think that this should work:

resource "azurerm_role_assignment" "create_global_admin_role_on_tenant" {
  scope                = "tenants/<TENANT ID>"
  role_definition_name = "Global administrator"
  principal_id         = azurerm_user_assigned_identity.example.principal_id
}

[circa10a]

Any thoughts on this issue? This is still a blocker today

[circa10a]

For anyone else reading this, I worked around the issue by creating a group with the appropriate billing permissions and added identities such as service principals to said group

[omerfsen]

For anyone else reading this, I worked around the issue by creating a group with the appropriate billing permissions and added identities such as service principals to said group

thoug not required adding a sample code for ur workaround would be nice

[omerfsen]

why not use azuread_directory_role_assignment instead of azurerm_role_assignment ? It seems azuread is better suited

[FrancoisPoinsot]

In case someone ends up on that issue while looking for a solution, here is a related issue with a workaround: https://github.com/Azure/terraform-provider-azapi/issues/400