Increase Keyvault Reference Limit in Parameters from 29 to 60+
As of right now, the communicated limit for keyvault references in a parameters file is "30", but is actually in practice 29 (appears to be a bug?).
This limitation is quite low for mature systems. Take, for example, the following potential data points:
- Multiple SQL ids/passwords, storage account keys, AI instrumentation, Redis cache credentials, etc. for connection strings
- App to app communication creds/API keys
- Programmatically created dynamically named/numbered resources
- References to signing keys for different purposes
Many of the clients I work with are struggling with this issue, which seems easily fixable by increasing the limit to a larger number. Doing so will alleviate reasonable use scenarios while allowing for basic protections as there is still a reasonable limit.
Please consider doing so ASAP; many of our templates now need to be arbitrarily split into multiple deployments to work around this issue, which is working directly against the labor savings one can incur by utilizing infrastructure templates in the first place. Also, it is forcing alternative solutions not leveraging the keyvault, which can reduce overall security, and, as MSFT gets paid by the transaction in the KV product, strip MSFT of revenue that would have been generated by that resource.
The limit has been increased to 256 – which is the max number of parameters allowed in a template (of any type).
Toby Meyer commented
Brian, after some refactoring work I'm confused as to why this would be the route; it's substantially more complex than direct parameter references. I'm wondering if perhaps there is a drive to solve some problems around this in the embedded JSON template language that are better suited to customer-centric (i.e. not overly specialized) tooling like PowerShell or Python.
Is it possible to discuss why 29 references in parameters is the current limit? Will there be a limit of the # of KV references that could be in a linked template?
This model is working very well for our clients and this directon would force a major re-factor for no benefit other than to work around that reference limit. At the very least, why not support both? Perhaps I'm missing something...
Toby Meyer commented
I have a couple of gut-level concerns, but I'll re-work some templates with this methodology & post back here detailed feedback. I appreciate the response!
Brian Moore commented
I think the way we will address this is similar to the requests here: https://feedback.azure.com/forums/281804-azure-resource-manager/suggestions/35131546-improve-access-to-key-vault-from-arm-templates
Essentially allowing the use of runtime functions to retrieve secrets and remove the need for reference parameters...
If you can think of a reason why that would not work for you, lmk...