all Technical posts

Key Vault Deployment Removes Access Policies

Azure Key Vault is one of those services that must be included in every Azure solution. Having the devops and infrastructure-as-code principles in mind, Key Vault must be automatically provisioned during releases. This is where Key Vault comes with a caveat - in this blog post I'll talk about a workaround.

The caveat

Key Vault can be easily provisoned through an ARM template.  This is an example of an ARM template for Key Vault:

The caveat is all about the accessPolicies property.  Currently, this behaviour is observed:

  • Although accessPolicies is considered an optional property, the exception “An invalid value was provided for ‘accessPolicies’” is thrown in case this property is missing.
  • In case an empty array is provided for the accessPolicies property, all existing access policies get removed.

This means that one needs already to be able to provide all access policies at the creation time of the Key Vault, which is impossible, especially if you’re leveraging Managed Service Identities.

The workaround

My first aim was to come up with a solution, purely within the ARM template, but this seemed impossible.  Mostly because the reference function is not supported within ARM parameters and variables.  My second – successful – attempt was to have a solution based on the ARM template, combined with some PowerShell within an Azure DevOps release pipeline.

Azure PowerShell script

Add to your release pipeline an Azure PowerShell task, which executes the following script.  This script takes the Key Vault Name as a parameter.  It looks up any existing access policies on the Key Vault and transforms these access policies into their ARM JSON notation.  The result is outputted to the Azure DevOps variable Infra.KeyVault.AccessPolicies.

Key Vault ARM deployment

Ater the previous release task, deploy the Key Vault via an ARM deployment, using the following template:

Remark that the access policies is feeded through an ARM parameter.  This parameter can be set on the ARM deployment task, using the previously created Infra.KeyVault.AccessPolicies variable:

This ensures that all existing access policies are preserved in case the Key Vault gets redeployed.

Conclusion

With some plumbing, we managed to find a workaround for the undesired behaviour of Key Vault deployments.  I hope the product group will address this issue in later releases and will make access policies a child resource of the Key Vault resource.

Cheers,
Toon

Subscribe to our RSS feed

Hi there,
how can we help?

Got a project in mind?

Connect with us

Let's talk

Let's talk

Thanks, we'll be in touch soon!

Call us

Thanks, we've sent the link to your inbox

Invalid email address

Submit

Your download should start shortly!

Stay in Touch - Subscribe to Our Newsletter

Keep up to date with industry trends, events and the latest customer stories

Invalid email address

Submit

Great you’re on the list!