Do you have an idea or a suggestion for Azure Key Vault based on your experience?

← Azure Key Vault

ARM Template for KeyVault to have AccessPolicies non-mandatory

Hi,
It would be better for idempotency and the ability to create Keyvault first, with additional incrementally run ARM templates to have AccessPolicies as non-mandatory.

It is already possible to incrementally add AccessPolicies once you have a KeyVault, but it is not possible to create or update a Keyvault via ARM without specifying the AccessPolicies... which is a problem for update - you need to know all the existing AccessPolicies before you do the update or it will get reverted to whatever you specify.

83 votes
Sign in
(thinking…)
Sign in with: Microsoft
Forgot password?
Create a password
Signed in as (Sign out)
Close
Close

We’ll send you updates on this idea

Dan Byrne shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

12 comments

Sign in
(thinking…)
Sign in with: Microsoft
Forgot password?
Create a password
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • Peter commented  ·   ·  Flag as inappropriate

    Who can explain in details what createMode=recover does and what is the consequence of using it? What is only officially documented is: "The vault's create mode to indicate whether the vault need to be recovered or not. - recover or default".

    I tested and used this "recover" mode due to fact mentioned below. I do not want to wipe access policies which are applied grammatically out of the scope of ARM template.

    What I noticed with createMode=recover is the fact that NetworkAcl defined in the keyvault ARM resource does not have any effect. And after successful arm deployment, the network access of KeyVault is still set for every network and not just for vnet as defined in the ARM. Is that expected behaviour?

  • Lyndon Rumpel commented  ·   ·  Flag as inappropriate

    I understand the motivation on wanting the requested ability. However, from a governance and security perspective, some kind of information security and/or auditor role will always have to receive some kind of minimal access. So just implement that purpose with the initial creation, which makes it compliant from the beginning.

  • McCraw, David commented  ·   ·  Flag as inappropriate

    +1

    This makes it really hard to have zero-downtime deployments in any significant architecture where there are clients of a vault managed in separate repos/ARM templates. So far I have a fragile and elaborate powershell around this, but I really want the ARM deployment for vaults to respect 'incremental'.

  • Traber commented  ·   ·  Flag as inappropriate

    +1. I don't understand why it is a requirement to include access policies.

    It certainly complicated ARM template deployments for existing Key Vaults, since providing an empty access policies list just wipes out everything that is there.

  • Filip Scherwin Lindboe commented  ·   ·  Flag as inappropriate

    I agree. I have a fully automated deployment using Azure DevOps. Here i have some access policies that needs to be assigned more dynamically according to context, so i am setting these through a script. Other access policies are static and is set using ARM template. But the fact that the access policies are being overwritten when deploying the ARM template has caused me some grief.

  • Toby Meyer commented  ·   ·  Flag as inappropriate

    This breaks incremental deployments in a fundamental way. I use other deployment actions to manipulate KV permissions programmatically & this makes it substantially more complex.

Azure Key Vault: Other

Categories

Feedback and Knowledge Base

(thinking…)
Hosted by UserVoice