terraform-provider-azurerm: importing azurerm_pim_eligible_role_assignment fails with resource not existant

Is there an existing issue for this?

I have searched the existing issues

Community Note

Terraform fails while importing the azurerm_pim_eligible_role_assignment. The assignment is still present in Azure but not in the state. To manage it, I tried importing it but it cannot find the assignment in Azure. The import fails with Cannot import non-existent remote object The apply fails with A resource with the ID "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-test-001|/subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.Authorization/roleDefinitions/00482a5a-887f-4fb3-b363-3b7fe8e74483|11111111-1111-1111-1111-111111111111" already exists - to be managed via Terraform this resource needs to be imported into the State. Please see the resource documentation for "azurerm_pim_eligible_role_assignment" for more information.

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.

Terraform Version

1.5.6

AzureRM Provider Version

3.71.0

Affected Resource(s)/Data Source(s)

azurerm_pim_eligible_role_assignment

Terraform Configuration Files

resource "azurerm_pim_active_role_assignment" "pim_active" {
  scope              = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-test-001"
  role_definition_id = "/subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.Authorization/roleDefinitions/00482a5a-887f-4fb3-b363-3b7fe8e74483"
  principal_id       = "11111111-1111-1111-1111-111111111111"

  justification = "Sample Justification"

  schedule {
    start_date_time = "2023-07-13T11:40:26.0000000+02:00"
    expiration {
      duration_days = 180
    }
  }
}

import {
  to = azurerm_pim_active_role_assignment.pim_active
  id = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-test-001|/subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.Authorization/roleDefinitions/00482a5a-887f-4fb3-b363-3b7fe8e74483|11111111-1111-1111-1111-111111111111"
}

Debug Output/Panic Output

╷
│ Error: Cannot import non-existent remote object
│
│ While attempting to import an existing object to "azurerm_pim_active_role_assignment.pim_active",
│ the provider detected that no object exists with the given id. Only pre-existing objects can be imported; check that the id is correct and that it is associated with the
│ provider's configured region or endpoint, or use "terraform apply" to create a new remote object for this resource.
╵

Expected Behaviour

The allready present assignment will get imported

Actual Behaviour

The Import throws the error, that the object in Azure is not existant, while it definitly is. Even the apply fails to create it, stating that the object is allready present

Steps to Reproduce

terraform apply

Important Factoids

No response

References

No response

About this issue

Original URL
State: closed
Created 10 months ago
Reactions: 10
Comments: 22 (14 by maintainers)

Most upvoted comments

@xuzhang3 FYI I just tried this on 3.85.0 release and it still fails. If I try to do the apply, it says it already exists. I add the import and it says it doesn’t exist.

smokedlinq on Dec 15, 2023

I am using the correct resource type and having the same issue. The azurerm_pim_eligible_role_assignment has been buggy from the start in my case, a lot of times seemingly out of nowhere stating that it needs to be created, even though it has already been created via terraform

I know imports have worked previously for me, not sure where the issue comes from.

audunsolemdal on Sep 6, 2023

@xuzhang3 In my testing I have noticed it takes circa 45 days for the pim assignment to ‘fail’ in the Azure backend before the issue presents itself in terraform.

spectrum048k on Dec 19, 2023

It does not really help to resolve anyones issues but I’d like to also support the maintainers in sharing two discoveries I made over the recent weeks.

Scheduling changes

The whole eligibility setup thing does not base on pure CRUD like objects it seems. It bases on “requests” (orders) you make and the system “processing” those. The resulting resources are read-only. It can be seen in the REST Docs that you always make a request of a kind and then you wait for a result that “pops up somewhere” else.

E.g. revoking an eligibility needs a “request” of type AdminRemove and then, after some time, the change will be persisted. I had to do that like two weeks ago to clean our terraform state as back then (see next point) the Management Group scoped PIM permissions had no UI!

An example for history:

curl --location --request PUT 'https://management.azure.com/providers/Microsoft.Management/managementGroups/uqe/providers/Microsoft.Authorization/roleEligibilityScheduleRequests/<random-uuid-from-an-uuid-tool>?api-version=2020-10-01' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer <token>' \
--data '{
  "Properties": {
    "RoleDefinitionId": "/providers/Microsoft.Authorization/roleDefinitions/<role>",
    "PrincipalId": "<principal>",
    "RequestType": "AdminRemove"
    }
}'

Afterwards, you can plan and apply again as the resulting “eligibility assignment” will be revoked.

This brings me to point 2.

New Azure UI

Since some days, you can do what I did via maddening REST calls via the UI! 🔔

It does not help much for the terraform issues but at least it’s easier to clean the state 🤣

unique-dominik on Oct 25, 2023

I could reproduce this issue as well.

Terraform v1.6.2
on darwin_arm64
+ provider registry.terraform.io/hashicorp/azurerm v3.77.0

braun-daniel on Oct 20, 2023

hmmm i had that issue with both active and eligible. The thing is: i can’t reproduce it right now 😢

Seems that it was a one-time thing?

I think this issue can be closed - I will reference it, once I come upon that issue again.

tim-krehan on Sep 5, 2023