Support for set parameter assignee-principal-type in azurerm_role_assignment

[dav1dli]

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

In case when access to Graph API is blocked (security policy for example) role assignment fails with an error

Error: authorization.RoleAssignmentsClient#Create: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="AuthorizationFailed" Message="The client 'XXX' with object id 'XXX' does not have authorization to perform action 'Microsoft.Authorization/roleAssignments/write' over scope '/subscriptions/YYY/resourceGroups/RG-XXX/providers/Microsoft.ContainerRegistry/registries/ACRXXX/providers/Microsoft.Authorization/roleAssignments/ZZZ' or the scope is invalid. If access was recently granted, please refresh your credentials."

similar error is produced when trying to az role assignment create --assignee XXX --role "AcrPull" --scope "/subscriptions/YYY/resourceGroups/RG-XXX/providers/Microsoft.ContainerRegistry/registries/ACREXXX with addition

Failed to query AAAA by invoking Graph API. If you don't have permission to query Graph API, please specify --assignee-object-id and --assignee-principal-type.
Assuming AAAA as an object ID.

but trying

az role assignment create --assignee-object-id AAAA --assignee-principal-type  ServicePrincipal --role 'AcrPull' --scope /subscriptions/YYY/resourceGroups/RG-XXX/providers/Microsoft.ContainerRegistry/registries/ACRXXX

produces desired result.

The documentation says:

[Attributes Reference](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/role_assignment#attributes-reference)
In addition to the Arguments listed above - the following Attributes are exported:

[principal_type](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/role_assignment#principal_type) - The type of the principal_id, e.g. User, Group, Service Principal, Application, etc.

so the parameter supported but it cannot be set.

Please allow to set the parameter.

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

azurerm_role_assignment

Potential Terraform Configuration

No response

References

No response

[dav1dli]

Workaround to the same effect:

resource "random_uuid" "assignment_name" {
}
data "azurerm_role_definition" "role_acrpull" {
  name  = "AcrPull"
  scope = data.azurerm_container_registry.acr.id
}
resource "azapi_resource" "role_assignment_acrpull" {
  type = "Microsoft.Authorization/roleAssignments@2022-04-01"
  name = random_uuid.assignment_name.result
  parent_id = data.azurerm_container_registry.acr.id
  body = jsonencode({
    properties = {
      principalId = azurerm_user_assigned_identity.aca_user_identity.principal_id
      principalType = "ServicePrincipal"
      roleDefinitionId = data.azurerm_role_definition.role_acrpull.id
    }
  })
}

[wuxu92]

hi @dav1dli Thanks for filing this issue. Could you please have a try with skip_service_principal_aad_check.the PrincipalType will set to ServicePrincipal when this property is set to true.

resource "azurerm_role_assignment" "test" {
  name                             = random_uuid.assignment_name.result
  roleDefinitionId             = data.azurerm_role_definition.role_acrpull.id
  principal_id                   = azurerm_user_assigned_identity.aca_user_identity.principal_id
  skip_service_principal_aad_check = true
}

[dav1dli]

skip_service_principal_aad_check = true

Thanks! That worked. And at least in my case I could use this:

resource "azurerm_role_assignment" "user_managed_idn_acr" {
  scope                = data.azurerm_container_registry.acr.id
  role_definition_name = "AcrPull"
  principal_id         = azurerm_user_assigned_identity.aca_user_identity.principal_id
  skip_service_principal_aad_check = true
}

so, it is not necessary to refer a role by ID and assign a name.

I would suggest adding a note to the documentation.

[dav1dli]

The suggested solution helped. But since the option is not similar to the option provided by az it might be counter-intuitive to use it. I think that it is useful to support options named similarly to those provided by vendor's tools. If not I suggest adding a note to the configuration.
From my perspective the ticket can be closed.

[mafis-hh]

The described workarround is nice if we know the principal-type and only deploy a single role assignment for a single Service Principal and we know it is definitely a Service Principal.
But in case of generic code with configuration files and "for_each" implementation, where we don't know if "each.value" is a User, a Group or a ServicePrincipal. So this won't fix the problem itself.

Both azurerm resources azurerm_synapse_role_assignment and azurerm_role_assignment do not set the attribute "principalType" (available in the Azure API), so it remains NULL. Many sub-componenst even work with this incomplete role assignment.
But there are Synapse-Subcomponents which will have a problem with missing principalType attribute. I identfied at least the SQL Serverless Engine (dedicated might be as well, but I didn't test) has a big problem when it comes to the roles "Synapse Administrator" and "Synapse SQL Administrator". Both Roles have the effect, that in the SQL Engine a LOGIN will be created.
Unfortunatley the SID creation of SQL Server requires the information "Service Principal" or not.

This is exactly the problem we are having.
The Service Principal which creates the Synapse Workspace will become the owner of the Synapse Workspace, and automatically it will be in the role "Synapse Administrator". The problem is, that the SID of this SP is wrong in the SQL Database. So there is no chance to login with this SP into the SQL engine at all.
At least for the Synapse SQL Engine it is essential that the role assignment is complete with the correct principal type, that all following processes in the SQL engine will work correctly.

In other words a synapse role assinment made by azure api or azure cli will create a correct role assignment with the correct SID in SQL engine, but when the Terraform azurerm provider creates the assignment the role assingment is incomplete and the SQL Engine's SID creation will be broken. So there is no chance to login with the SP at the SQL engine in the end.

@rcskosir , can you please re-open this issue?

[rcskosir]

@mafis-hh Reopening!

[jczerniak]

Hi Guys!

After much testing I found this thread. I think this also doesn't work when the user is assigned the "Role-Based Access Control Administrator" role with an ABAC condition imposed

(
 (
  !(ActionMatches{'Microsoft.Authorization/roleAssignments/write'})
 )
 OR
 (
  (
   NOT @Request[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {18d7d88d-d35e-4fb5-a5c3-7773c20a72d9, 8e3af657-a8ff-443c-a75c-2fe8c4bcb635, b24988ac-6180-42a0-ab88-20f7382dd24c, f58310d9-a9f6-439a-9e8d-f62e7b41a168}
   AND
   NOT @Request[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'}
  )
 )
)
AND
(
 (
  !(ActionMatches{'Microsoft.Authorization/roleAssignments/delete'})
 )
 OR
 (
  NOT @Resource[Microsoft.Authorization/roleAssignments:RoleDefinitionId] ForAnyOfAnyValues:GuidEquals {8e3af657-a8ff-443c-a75c-2fe8c4bcb635, f58310d9-a9f6-439a-9e8d-f62e7b41a168, 18d7d88d-d35e-4fb5-a5c3-7773c20a72d9, b24988ac-6180-42a0-ab88-20f7382dd24c}
  AND
  NOT @Resource[Microsoft.Authorization/roleAssignments:PrincipalType] ForAnyOfAnyValues:StringEqualsIgnoreCase {'User'}
 )
)

https://learn.microsoft.com/en-us/azure/role-based-access-control/conditions-overview

Best Regards,
Jacek

[wuxu92]

Hi @mafis-hh, I think this is a separate case related to the azurerm_synapse_role_assignment resource. While the azurerm_role_assignment resource can set the principalType as ServicePrincipal using the skip_service_principal_aad_check property, this property is not available for synapse_role_assignment. Would your issue be resolved if the provider added a similar skip_service_principal_aad_check property to the synpse_role_assignment resource? If so, could you please create a separate issue so that we can keep track of it and address it with a new pull request linked to it?

[mafis-hh]

Hi @wuxu92, you are right. It is a separate case, there are two terraform resources which can handle the same Azure resource.
My case was for the second terraform resource azurerm_synapse_role_assignment.
Within our development team we created the PR #24089 which can fix the issue, by adding the principal type as additional property.
In our case the skip_service_principal_aad_check property will not fix the issue. Can you please review our PR?
Thank you in advance.
Marco

[HammerNL89]

We are having the same issue when using:
https://learn.microsoft.com/en-us/azure/role-based-access-control/delegate-role-assignments-portal?tabs=template

Our app reg, that we use to deploy TF resources, is assigned the role Role Based Access Control Administrator with custom condition that looks for PrincipalType. When we try to create an azurerm_role_assignment linked to an managed identity it fails with an Status=403 Code="AuthorizationFailed"

Creating the role assignment with the azure cli, works, with the same app reg.

Based on our findings and other comments, the request body doesn't contain the PrincipalType when using Terraform and therefore failing the condition. The workaround skip_service_principal_aad_check = true , does the job, but setting the type on the resource itself., would be better. The workaround seems to be limited to type ServicePrincipal.

Would be nice if the PR could be reviewed / merged:
#24271

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.