Microsoft.Authorization/roleEligibilityScheduleRequests API not idempotent?

[MPowellFDB]

The process for manually adding/updating multiple PIM eligibility assignments is incredibly tedious. We're trying to programmatically create these using Bicep templates. However, the Bicep API doesn't seem to be idempotent. This isn't ideal for redeploying template to update existing assignments' properties.

Here's the template we're using for a single Bicep PIM assignment deployment:

targetScope = 'subscription'
resource pimAssignment 'Microsoft.Authorization/roleEligibilityScheduleRequests@2022-04-01-preview' = {
  name: guid('testpim2') //variable (unique guid per assignment)
  scope: subscription() //variable (sub or rg)
  properties: {
    principalId: '{ADGroupID}' //variable 
    requestType: 'AdminUpdate'
    roleDefinitionId: 'subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c' // variable. Contributor
    scheduleInfo: {
      expiration: {
        duration: 'P365D'
        type: 'NoExpiration'
      }
      startDateTime: '2022-08-16T00:00:00.000000'
    }
  }
}

We're deploying at Subscription scope with az deployment sub create --location uksouth --template-file <templatePath> which works fine.

When re-deploying this template we recieve an "Assignment already exists" error. It seems that we'd need to find and delete the existing assignment before we can update it.

Is this an API limitation, or will we be able to update existing assignments by redeploying via Bicep in future?

[brwilkinson]

@MPowellFDB You are correct, this API is not idempotent.

You have to provide a new guid each time you change or even delete the scheduleRequest.

I simply use the following and it works fine.

param name string = newGuid()

Also note that when I roleElegibilitySchedule is activated, you are unable to modify them and the deployment will fail.

[azMantas]

I believe that when requestType set to AdminUpdate the deployment will success. But the active role assignment will be removed and a user has to elevate the role once again. I just recently find out that AdminRenew works best in my scenario, active role is not de-activated, existing role is extended and deployments are not failing.

resource pim 'Microsoft.Authorization/roleEligibilityScheduleRequests@2020-10-01-preview' =  {
  name: roleGUID
  properties: {
    roleDefinitionId: roleDefinitionId
    principalId: AzureADGroupId
    requestType: 'AdminRenew'
    scheduleInfo: {
      startDateTime: utc
      expiration: {
        type: 'AfterDuration'
        duration: 'P90D'
      }
    }
  }
}

the last thing that I need is to find out what to do with all that email spam...

[MPowellFDB]

@azMantas good catch, I'll this again with different requestTypes

[brwilkinson]

Thanks for the tip on "adminrenew" @azMantas will have to test this setting out, I had landed on AdminUpdate previously...