`azurerm_role_management_policy` has constant drift

[paul-hugill]

Is there an existing issue for this?

• [X] I have searched the existing issues

Community Note

• Please vote on this issue by adding a :thumbsup: reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave comments along the lines of "+1", "me too" or "any updates", 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.7

AzureRM Provider Version

3.108.1

Affected Resource(s)/Data Source(s)

azurerm_role_management_policy

Terraform Configuration Files

resource "azurerm_role_management_policy" "owner" {
  scope              = local.subscription_path
  role_definition_id = data.azurerm_role_definition.owner.id

  active_assignment_rules {
    expiration_required                = true
    expire_after                       = "P30D"
    require_justification              = true
    require_multifactor_authentication = true
    require_ticket_info                = false
  }

  eligible_assignment_rules {
    expiration_required = false
    expire_after        = null
  }

  activation_rules {
    maximum_duration                   = "PT12H"
    require_multifactor_authentication = true
    require_justification              = true
    require_ticket_info                = false
  }

  notification_rules {
    active_assignments {
      admin_notifications {
        additional_recipients = []
        default_recipients    = true
        notification_level    = "All"
      }
      assignee_notifications {
        additional_recipients = []
        default_recipients    = false
        notification_level    = "Critical"
      }
    }
    eligible_assignments {
      admin_notifications {
        additional_recipients = []
        default_recipients    = false
        notification_level    = "Critical"
      }
      assignee_notifications {
        additional_recipients = []
        default_recipients    = false
        notification_level    = "Critical"
      }
    }
    eligible_activations {
      admin_notifications {
        additional_recipients = []
        default_recipients    = false
        notification_level    = "Critical"
      }
      assignee_notifications {
        additional_recipients = []
        default_recipients    = false
        notification_level    = "Critical"
      }
    }
  }
}

Debug Output/Panic Output

Can provide if required.

Expected Behaviour

On subsequent runs there should be no changes

Actual Behaviour

Always shows changes but not what is being changed:

module.this.azurerm_role_management_policy.owner
   id : "/subscriptions/xxxxxxxxx/providers/Microsoft.Authorization/roleDefinitions/8e3af657-a8ff-443c-a75c-2fe8c4bcb635|/subscriptions/xxxxxxxxx"
   name : "6f3c8f32-3c2d-4917-a5bb-c04ee74bbb09"

   ... 3 unchanged attributes hidden
   ... 4 unchanged blocks hidden

Steps to Reproduce

1. terraform apply
2. Run terraform apply again and see it showing it will do an update but not what it is updating

Important Factoids

No response

References

This appears to be the same as the issue I am having on the azuread_group_role_management_policy resource in the AzureAD provider: https://github.com/hashicorp/terraform-provider-azuread/issues/1398

I believe this is based on the same code.

[magodo]

@paul-hugill From the azuread provider's issue, the diff indicates a change for the approval_stage. Is that the same for your case (as the plan diff you provided doesn't look like something printed directly from TF)?

[paul-hugill]

Sorry @magodo, yes exactly the same, that was a TFC UI output, this is a similar CLI version.

  # module.this.azurerm_role_management_policy.built_in["Owner"] will be updated in-place
  ~ resource "azurerm_role_management_policy" "built_in" {
        id = "/subscriptions/xxxxxxxxxx/providers/Microsoft.Authorization/roleDefinitions/8e3af657-a8ff-443c-a75c-2fe8c4bcb635|/subscriptions/xxxxxxxxxxxxx"
        name= "6f3c8f32-3c2d-4917-a5bb-c04ee74bbb09"
        # (2 unchanged attributes hidden)

      ~ activation_rules {
            # (5 unchanged attributes hidden)

          - approval_stage {
            }
        }

        # (3 unchanged blocks hidden)
    }

In the CLI for both, they show the approval_stage being removed but in the Structured UI output in TFC, there are no changes at all shown.

For anyone else trying to use this, that doesn't need the approvals, then adding ignore_changes at least stops the constant drift.

  lifecycle {
    ignore_changes = [activation_rules[0].approval_stage]
  }

Not a solution but at least makes this usable for me for now.

[magodo]

The issue probably lies in https://github.com/hashicorp/terraform-provider-azurerm/blob/9d1768c6a074a460cd059efc4285f6a7832aa14a/internal/services/authorization/role_management_policy.go#L268-L272

This happens at Create/Update that no approval_stage is specified, it ended up with an empty block, while actually it wants a null.

Ping @manicminer.

[JWilkinsonMB]

Also having this issue, but need to be able set whether approval is enabled based on configuration pulled from YAML, so ignore_changes isn't an option. A workaround in case it helps others was to create an empty placeholder group and assign that to the approval_stage.

activation_rules {
    maximum_duration                                   = "PT${each.value.maximum_duration}H"
    require_approval                                   = each.value.approval_group != null ? true : false
    require_justification                              = true
    require_multifactor_authentication                 = true
    required_conditional_access_authentication_context = null
    require_ticket_info                                = false
    # dynamic "approval_stage" {
    #   for_each = each.value.approval_group != null ? [each.value.approval_group] : []
    #   content {
    #     primary_approver {
    #       object_id = local.groups_name_id_map[approval_stage.value]
    #       type      = "Group"
    #     }
    #   }
    # }
    # FIXME: https://github.com/hashicorp/terraform-provider-azurerm/issues/26377
    # Until this bug is fixed, we can't use the dynamic block above and use a placeholder group instead 
    approval_stage {
      primary_approver {
        object_id = each.value.approval_group != null ? local.groups_name_id_map[each.value.approval_group] : azuread_group.placeholder_approval_group.object_id
        type      = "Group"
      }
    }
  }

As long as require_approval is set to false this group doesn't get used, but having it set stops the drift issue.

[christopher-pope]

Is there any update on getting this resolved in the provider?

[srjennings]

beep boop

[wenesak]

any updates on this issue??

[karts499]

hey everyone. fyi they fixed it in the azuread_group_role_management_policy resource in version 3.2.0. Unfortunately not in the azurerm...

[mateuszte]

Any update here? It's still issue :(

[georgegil]

any update...?

[github-actions[bot]]

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.