terraform-provider-azapi icon indicating copy to clipboard operation
terraform-provider-azapi copied to clipboard

Failed to delete PIM's roleEligibleScheduleRequest with 403 error.

Open msjunyao opened this issue 3 years ago • 3 comments
trafficstars

Hello Developers,

We use the AzAPI provider (1.0.0) to delete a PIM roleEligibileScheduleRequest. The template is as follows: image 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: image

Without state file: image

Would you please check whether this is the problem in AZAPI provider? and how can we fix the issue accordingly?

Best Regards

msjunyao avatar Oct 10 '22 14:10 msjunyao

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.

mariussm avatar Oct 11 '22 07:10 mariussm

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"
    }
  })
}

ms-henglu avatar Oct 12 '22 07:10 ms-henglu

Hi @mariussm - Another option is using terraform state rm azapi_resource.test to remove this resource from terraform state directly.

ms-henglu avatar Oct 12 '22 07:10 ms-henglu

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.

ihclark49 avatar Nov 23 '22 07:11 ihclark49

I'll close this issue as it's resolved but feel free to reopen it

ms-henglu avatar Jan 10 '24 07:01 ms-henglu