underministic privileged identity management deployments

[ErHaWi]

Bicep version Bicep CLI version 0.25.53 (c0ad57dff6)

Describe the bug We're trying to incorporate privileged identity management in deployment of subscriptions to our product teams. We want to deploy the ability for developers to activate contributor permissions at the subscription level. Changes to our access structure would mean redeployment of templates. They need to be idempotent for this to work properly (as most azure resources already are). As of now, consecutive deployments of privileged identity management assignments fails with conflict after the initial deploy.

To Reproduce deploy the bicep file twice on subscription level with az bicep deployment sub create

var contributor_role = resourceId('Microsoft.Authorization/roleDefinitions', 'b24988ac-6180-42a0-ab88-20f7382dd24c')

@description('object id of principal that should have eligibility for contributor permissions')
param ownerId string = '[REDACTED]'

param startTime string = utcNow()

resource owner_contributor_ligibility 'Microsoft.Authorization/roleEligibilityScheduleRequests@2022-04-01-preview' = {
  name: guid(contributor_role, ownerId) // note that this does not change between deployments
  properties: {
    principalId: ownerId
    requestType: 'AdminUpdate'
    roleDefinitionId: contributor_role
    scheduleInfo: {
      expiration: {
        duration: 'P365D'
        type: 'AfterDuration'
      }
      startDateTime: startTime
    }
  }
}

Additional context consecutive deployments yield the following error:

{
  "code": "Conflict",
  "message": "A role assignment request with Id: 7aede46e-bf0f-5b59-966c-48ccd70209b2 already exists",
  "target": "/subscriptions/[REDACTED]/providers/Microsoft.Authorization/roleEligibilityScheduleRequests/7aede46e-bf0f-5b59-966c-48ccd70209b2"
}

[mattias-fjellstrom]

This is indeed an annoying problem! Also reported here https://github.com/Azure/bicep-types-az/issues/1956

The workaround I use is to set this up with PowerShell in a deployment script. It is not an ideal workaround because deployment-scripts feel like a hack.

Note that this is a problem in the underlying API, so not really something Bicep will be able to fix.