terraform-provider-azapi
terraform-provider-azapi copied to clipboard
Failed to delete PIM's roleEligibleScheduleRequest with 403 error.
Hello Developers,
We use the AzAPI provider (1.0.0) to delete a PIM roleEligibileScheduleRequest. The template is as follows:
Once we run "terraform apply", it returns the 403 error as follows:
RESPONSE 403: 403 Forbidden
ERROR CODE: AuthorizationFailed
{ "error": { "code": "AuthorizationFailed", "message": "The client '744089d3-2f3b-4c26-8642-cf028d43895c' with object id '744089d3-2f3b-4c26-8642-cf028d43895c' does not have authorization to perform action 'Microsoft.Authorization/roleEligibilityScheduleRequests/delete' over scope '/providers/Microsoft.Subscription/subscriptions/bed8cf5c-7832-4b70-a6d8-ac3e94a98b7f/providers/Microsoft.Authorization/roleEligibilityScheduleRequests/77bdd9c3-e0bc-489f-82cf-8648c522f814' or the scope is invalid. If access was recently granted, please refresh your credentials." } }
The problem doesn't happen when we remove the terraform state file. After comparing the good and problem attemps, we found that when the problem is it sends a HTTP "delete" request to AzureAD. However, the correct way should "post" a request with "RequestType = AdminRemove" to Azure AD. Upon the document https://learn.microsoft.com/en-us/azure/templates/microsoft.authorization/roleeligibilityschedulerequests?pivots=deployment-language-terraform mentions, the "Put" request with "RequestType=AdminRemove" is the correct method. Terraform should not send a HTTP "delete" request to AAD Direclty. From the backend, I do see the 403 error returned from AAD Gateway.
The following is the difference between them:
With State file:

Without state file:

Would you please check whether this is the problem in AZAPI provider? and how can we fix the issue accordingly?
Best Regards
Fun, I was just gonna report this. But - it is not a direct issue with the AzAPI provider, as it completely ignores all the different resource types, and just does everything the same we. What we need here is a feature to "forget" resources, such as being able to set "ForgetWhenDestroy=true" on the resource. Too bad Terraform lifecycle meta argument does not support something like this.
Hi @msjunyao ,
Thank you for taking time to report this issue!
I have a workaround for it:
azapi_resource_action is more flexible, and when remove this resource from terraform configuration, no actions will be taken.
resource "azapi_resource_action" "test" {
type = "Microsoft.Authorization/roleEligibilityScheduleRequests@2022-04-01-preview"
resource_id = "/subscriptions/bed8cf5c-7832-4b70-a6d8-ac3e94a98b7f/providers/Microsoft.Authorization/roleEligibilityScheduleRequests/77bdd9c3-e0bc-489f-82cf-8648c522f814"
method = "PUT"
body = jsonencode({
properties = {
principalId = "xxx"
requestType = "AdminAssign"
roleDefinitionId = "xxx"
}
})
}
Hi @mariussm - Another option is using terraform state rm azapi_resource.test to remove this resource from terraform state directly.
Hi @ms-henglu - we're using the suggested azapi_resource_action approach to setup PIM eligability, and we're getting some errors on initial application:
Error: performing action of "Resource: (ResourceId "/providers/Microsoft.Subscription/subscriptions/xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx/providers/Microsoft.Authorization/roleEligibilityScheduleRequests/537aa050-eeec-b82d-5c64-ca974b8572e5" / Api Version "2022-04-01-preview")": unmarshalling type *runtime.requestError: json: cannot unmarshal string into Go value of type runtime.requestError
On running it again, the eligibility request does get created, but it's needing a 2nd sometimes 3rd run to complete. These are typically new resources being secured but its easily reproducible.
Not sure how to approach this, as the suggested PUT action does neatly avoid the terraform destroy failure, but its not a total solution.
Edit: Though having inspected further, I was using keepers for the request params (guid), and as long as you ignore that and rotate the guid each application, the API applies without error.
I'll close this issue as it's resolved but feel free to reopen it