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.
Dan Byrne
shared this idea
20 comments
-
Marcus Nätteldal
commented
This is a roadblock for our team. We have multiple function apps that are deployed separately and their AccessPolicies are added when deployed and can therefore also be changed with a new deployment.
When adding a new function app we just take the same deployment logic and just change the name. However if we need to change something in the KeyVault resource it will remove all those AccessPolicies and we have to redeploy everything.
I've tried the createMode workaround mentioned in comments but it doesn't seem to work anymore. "code": "SoftDeletedVaultDoesNotExist"
-
Janne Kujanpää
commented
This is now fourth popular feedback of the keyvault and soon three years old.
Is there any plans of getting this fixed or not?
-
Greg Lloyd
commented
Just ran into this today. We do everything as linked templates with other resources defining their access to the Key Vault. So when the shared pipeline re-runs the permissions being wiped is a problem. Thankfully we have the work around of using createMode. However it would still be better if it was not required.
-
Anonymous
commented
+1 This is a fundamental issue when using for instance databricks with keyvault backed secret scopes. Everytime we incrementally redeploy the infrastructure the secret scope will break.
(and yes this is also a limitation of databricks) -
Sergey Kostrukov
commented
+1 As mentioned below, without incremental updates it's fundamentally broken.
-
Peter Bertok
commented
Is there any ETA on this being resolved? It seems to be fundamentally broken and there's no word from any Azure techs about a planned resolution...
-
Romain
commented
Agree to.
"CreateMode" is given as a workaround in comments, but it isn't a good one : its behavior is not well documented, but it seems to be used to restore a soft-deleted KeyVault, and not to create one without access policies defined.
Because when creating a KV with "createMode=recover" with last apiVersion at date, I've this error : "A soft deleted vault with the given name does not exist."
-
Andre Bossard commented
I created a nested ARM Template that:
- deploys a KV
- sets a tag
- if the tag is there, the next deployment will first get the existing access policies -
Peter
commented
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?
-
KjB
commented
ARM deployments is possible when using CreateMode (Recovery) and separate access policies.
CreateMode
https://docs.microsoft.com/en-us/azure/templates/microsoft.keyvault/2018-02-14/vaultsAccess policy - Add , replace and move
https://docs.microsoft.com/en-us/azure/templates/microsoft.keyvault/2018-02-14/vaults/accesspolicies -
Lyndon Rumpel
commented
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
+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 Campbell
commented
+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.
-
Anonymous
commented
Support
-
Chris Neale
commented
Support
-
Salford
commented
Support this suggestion vehemently!
-
Henry
commented
Totally agree
-
Filip Scherwin Lindboe
commented
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
This breaks incremental deployments in a fundamental way. I use other deployment actions to manipulate KV permissions programmatically & this makes it substantially more complex.
-
Anonymous
commented
Agreed.