Support for azurerm_role_assignment separate resource to add conditions

[anwarnk]

Is there an existing issue for this?

• I have searched the existing issues

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 and review the contribution guide to help.

Description

Currently we are assigning rbac using azurerm_role_assignment with conditions. This works great, however we have a requirement to assign additional conditions in another resource. However, there isn't an option to just add conditions and if we use the same resource it complains with:

Error: authorization.RoleAssignmentsClient#Create: Failure responding to request: StatusCode=409 -- Original Error: autorest/azure: Service returned an error. Status=409 Code="RoleAssignmentExists" Message="The role assignment already exists."

New or Affected Resource(s)/Data Source(s)

azurerm_role_assignment

Potential Terraform Configuration

azurerm_role_condition {

scope                = "/subscriptions/xxxxxxxxxxxxxxxx/providers/Microsoft.Authorization/roleAssignments/xxxxxxxx"
  condition_version    = "2.0"
  condition            = << additional policy 
}

References

No response

[harshavmb]

Hi @anwarnk ,

I don't think this is a constraint of azurerm_role_assignment resource. The scope argument together with one of role_definition_id, role_definition_name and principal_id guarantees the unique combination.

I would like to know more about however we have a requirement to assign additional conditions in another resource.. For other resources, you create new resource provider with it's own unique name (uuid in this case) preferably with for_each right?

Can you post your configuration to have some more idea on this? Could be that I'm missing something here.

[harshavmb]

I've got another idea, in your azurerm_role_assignment resource you can generate name argument by using random_uuid which gets triggered by an arbitrary map of values that, when changed, will trigger recreation of resource. In this case it would be one of the below arguments ::

1. scope
2. role_definition_id/role_definition_name
3. principal_id

[anwarnk]

For clarification we have a for_each setup in terraform with its own state file. The for_each is set for each new subscription, the role assigned in the condition is what we deem as generic.

#Assignment for Service Principle Groups LZ Subscription
resource "azurerm_role_assignment" "sp_group_rbac_subscriptions" {
  for_each             = local.flat_environments
  scope                = "/subscriptions/${each.value.subscription_id}"
  role_definition_name = "Role Based Access Control Administrator"
  principal_id         = module.service_principal_environment[each.key].group_id
  condition_version    = "2.0"
  condition            = <<-EOT
(
 (
  !(ActionMatches{'Microsoft.Authorization/roleAssignments/write'})
 )
 OR 
 (
  @Request[Microsoft.Authorization/roleAssignments:RoleDefinitionId]
 ForAnyOfAnyValues:GuidEquals {${join(",", values(local.role_guids))}}

 )
)
AND
(
 (
  !(ActionMatches{'Microsoft.Authorization/roleAssignments/delete'})
 )
 OR 
 (
  @Resource[Microsoft.Authorization/roleAssignments:RoleDefinitionId]
 ForAnyOfAnyValues:GuidEquals {${join(",", values(local.role_guids))}}

 )
)
EOT  
}

However, further in the code development we may need to customise the role assignment for maybe one principal_id to add additional roles (this would be in a different state file). However, if I try and do it today, using the same role with different conditions it will error, which is what I suspected before even trying it out. What I am asking for if there's a possibility to something similar like resource "azuread_group_member" > add member to an existing group but in this case add condition to an exiting one.

For now we have a workaround and that is we created a new role definition with different GUID and then added the extra conditions that we wanted.

[harshavmb]

Thanks for the clarification!

I indeed see the limitation coming from the restapi specs here as they don't offer update HTTP method. So the terraform resource here more or less follows the REST API specs.

It appears to me like you have to create another role assignment with a new condition but you can flag this with Microsoft Dev team if they are planning to support in near future.

I'm open if Hashicorp team has other thoughts on this.