Keys in key vault can't be updated via Bicep

[rmurphyaxa]

Bicep version
Bicep CLI version 0.9.1 (a2950a16df)

Describe the bug
Once a key with an expiration is created in key vault, the expiration date can not be updated in Bicep when performing a deployment update.
The deployment will error with the following
{"status":"Failed","error":{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.","details":[{"code":"BadRequest","message":"{\r\n "error": {\r\n "code": "KeyCreationParametersDidNotMatchExistingKey",\r\n "message": "[KeyCreationParametersDidNotMatchExistingKey (BadRequest)] The key 'thisIsAsecret2' already exists, but the specified key creation parameters did not match that of the existing key (The existing key has an expiration date of '9/20/2022 9:26:16 AM', which doesn't match the given expiration date '9/20/2022 9:42:56 AM'.). This API can only be used for creating the first version of a new key (no subsequent versions
can be created, and existing keys cannot be updated)."\r\n }\r\n}"}]}}

To Reproduce
Steps to reproduce the behavior:

1. Create the secret in exhisting KV with BICEP. az deployment group create --resource-group "rmurphyaxa-testing" --template-file main.bicep

//~~~~~~~~~~~~~~~~~~~~ Key Vault ~~~~~~~~~~~~~~~~~//
resource keyVault 'Microsoft.KeyVault/vaults@2019-09-01' existing = {
  name: 'rmurphyaxa-test-kv2'
}
//~~~~~~~~~~~~~~~~~~~~    Key    ~~~~~~~~~~~~~~~~~//
resource keys 'Microsoft.KeyVault/vaults/keys@2021-11-01-preview' = {
  parent: keyVault
  name: 'thisIsAsecret2'
  properties: {
    attributes: {
      enabled: true
      exp: 1663666976
    }
    kty: 'RSA' // RSA

    rotationPolicy: {
      attributes: {
        expiryTime: 'P28D'
      }
      lifetimeActions: [
        {
          action: {
            type: 'rotate'
          }
          trigger: {
            timeBeforeExpiry: 'P7D'
          }
        }
      ]
    }
  }
}

2. Update the properties.attributes.exp date to a later datetime. in exhisting KV with BICEP. Rerun deployment.
   e.g.

  properties: {
    attributes: {
      enabled: true
      exp: 1663686976
    }

4. Error will be raised stating that the secret already exists and cannot be updated.

[atul-ram]

+1 following

[marunmohan]

Is there any workaround?

[mark-vw]

+1
Also running into this and actively looking for a workaround.

[rebel24]

+1
Looking for this too. I don't want to even update the expiration date, just to basically allow a skip. the only work around I've been able to do is but a if statement using a bool to disable the key creation after first deployment.

[Kaloszer]

+1 looking for the same

[NucLabs]

+1
Same here. I'm OK with the fact I cannot change any of the properties of the key through bicep. The problem I have is that my deployment fails when I rerun the deployment after the key has been rotated, making the exp dates not match.
My reason for re-running the deployment is a change in an other resource in that same deployment
So for me it would be OK if this was a warning, not an error.

[alex-frankel]

Not sure how this issue slipped through the cracks, but this is not something we can fix in the bicep side. It would be good if one of the recent commentors on this thread can open up a support ticket so that the Key Vault team can take a look. It is also related to Azure/bicep#4023

[fdmsantos]

+1
Anyone with workaround?

[rebel24]

+1 Anyone with workaround?

Only way I've done it is with a conditional if statement with a bool param to switch off key deployment after initial creation.

Really silly this hasn't being fixed yet it's such a pain.

[fdmsantos]

+1 Anyone with workaround?

Only way I've done it is with a conditional if statement with a bool param to switch off key deployment after initial creation.

Really silly this hasn't being fixed yet it's such a pain.

Thanks for workaround. I will develop that. Is not the ideal, but we need something :)

[mark-vw]

Our group created a custom deployment script to perform the existence check as a way around the input param. Required submodules and credentials passed in to do the lookup so I don't recommend that approach as it's complicated. @rebel24 approach is less messy imo, but this is still a workaround to a nearly 2-year problem.

As @alex-frankel recommendeded, someone needs to push on the key vault product group to have this fixed in the provider but apparently there are no takers bc we've all come here to discover a workaround is needed and that pain is prefferable to a MS support ticket.

[rebel24]

Our group created a custom deployment script to perform the existence check as a way around the input param. Required submodules and credentials passed in to do the lookup so I don't recommend that approach as it's complicated. @rebel24 approach is less messy imo, but this is still a workaround to a nearly 2-year problem.

As @alex-frankel recommendeded, someone needs to push on the key vault product group to have this fixed in the provider but apparently there are no takers bc we've all come here to discover a workaround is needed and that pain is prefferable to a MS support ticket.

Let's hope it's not the intune team as right now support there is absolutely ridiculous...

The other side of it is why can't this be pushed internally without us having to create a ticket. Honestly doesn't make sense.

[mennolaan]

We tried using the deployment script in bicep to create an az cli call to check if a key already exist. But the problem with this is the amount of rights needed to perform this.

I'm kind of surprised bicep doesn't support either validating if resource exist or allowing a conditional property value that doesn't try to override the existing value.

At the moment we need to do a az cli call in yaml task and push the result in env variable we read in bicep to determine if a key with exp has already been created. If this is the case, our bicep will fail even though if the values are static for exp value. To be honest this is bad practice, you want to keep your IAC as much together as possible.

Even worse, the azure verfiied modules for keyvault also have this issue. I was hoping they would be able to solve this.

@alex-frankel can you update us on the progress of this bicep bug on keyvault side.

[mennolaan]

@alex-frankel Just checking in if there is any progress on this short coming in bicep? Would love to have the ability to verify if certain component aspects are present. Especially with checking if a key already exist as this usecase has very big short comings on doing proper IaC. At our client ACR are very restricted due to the nature of security aspects of ACR's, there for using deploymentScripts isn't really possible.