terraform-provider-azurerm: azurerm_kusto_database_principal_assignment: Error: waiting for creation of Database Principal Assignment when using User Assigned Managed Identity
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
Terraform Version
1.2.3
AzureRM Provider Version
3.7.0
Affected Resource(s)/Data Source(s)
azurerm_kusto_database_principal_assignment
Terraform Configuration Files
resource "azurerm_user_assigned_identity" "api_identity" {
resource_group_name = var.resource_group_name
location = var.location
name = "id-example"
}
resource "azurerm_kusto_database_principal_assignment" "adx_principal_assignment" {
name = "adx-example-viewer"
resource_group_name = var.resource_group_name
cluster_name = var.adx_cluster_name
database_name = var.example_db
tenant_id = data.azurerm_client_config.current.tenant_id
principal_id = azurerm_user_assigned_identity.api_identity.principal_id
principal_type = "App"
role = "Viewer"
}
Debug Output/Panic Output
Error: waiting for creation of Database Principal Assignment: (Principal Assignment Name "adx-example-viewer" / Database Name "example_db" / Cluster Name "examplecluster" / Resource Group "example-rg"): Code="BadInput" Message="[BadRequest] Entity ID 'xxxxxx-xxxx' of type 'AAD Application Id' was not found in AAD tenant 'xxxxxx'."
Expected Behaviour
I would expect the assignment to complete.
Actual Behaviour
The ADX assignment is not able to find the managed identity in the tenant. This seems to be a timing issue as the ID is available if manually searching AAD. After creation of the managed identity it must take some time for it to be available to ADX.
Steps to Reproduce
No response
Important Factoids
No response
References
No response
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 1
- Comments: 15 (8 by maintainers)
Hi @liuwuliuyun,
Thanks for your suggestion. I have tried to reproduce the issue using your example, and have done this in 2 ways:
If I take your example above and run as it, ie create the ADX cluster, db, MI and db assignment in the same terraform run then everything works as you experienced. As described previously this is not how we are working.
If I take your example and create the cluster and db in 1 terraform run, then in a 2nd run add the MI and database principal assignment I get an error which describes the MI is not available, eg Entity ID âxxxâ of type âAAD Application Idâ was not found in AAD tenant.
My assumption here is that in attempt 1, the MI is created long before the ADX, as the ADX takes some minutes to become available. After this assignment is successful as the MI can be found. As in step 2 the time taken to create the MI and do the assignment appears not to be enough for the MI to be properly available in AAD. It appears that some delay/retry is needed between the MI creation and assignment for ADX.
Could you test it from your-side as I did in attempt 2?
To add to this: We create the cluster that can be used by various services (other stages, like James mentioned) as base for their Terraform based infrastructural runs. So, by the time we create the cluster through TF, we donât know what/how many managed identites there will assigned via azurerm_kusto_database_principal_assignment later nor is it possible, if a certain serviceâs infrastructure gets created and with that, its MI, to update the identities on the cluster as the complete MI list is unknown to that very service. So, with TF capabilities, I donât think itâs possible to update the clusterâs identities like you proposed.
But anyhow: Could you try the approach without predefining the identities on the cluster, say, skip setting of âidentity_idsâ to check whether you can reproduce the issue? It worked on our side, but only after several trials. So maybe there is something that could be improved here.