How can we improve the Azure Resource Manager?

Enable using local filesystem for Linked Templates

Allow an ARM template to reference a relative file path on the local file system for accessing Linked Templates. It seems absurd that this isn't already available. We shouldn't be forced to put our templates in a publicly available resource to retrieve them and use them in other templates.

176 votes
Sign in
(thinking…)
Sign in with: Microsoft
Signed in as (Sign out)

We’ll send you updates on this idea

Alex Marshall shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

12 comments

Sign in
(thinking…)
Sign in with: Microsoft
Signed in as (Sign out)
Submitting...
  • Florian commented  ·   ·  Flag as inappropriate

    Some sort of a solution would be actually required when using templateLinks in ARM files which you have under sourcecontrol and push out via the Azure DevOps pipelines.
    Currently it is required to use a StorageAccount but if we could circumvent this need in the pipeline it would make the whole deployment much easier and less fragile, perhaps even more secure.

    One possible solution is to merge the templates before pushing it to Azure. This could even be a new specific Task so the current Resource Manager task wouldn't need any changes...

  • Anonymous commented  ·   ·  Flag as inappropriate

    Are you sure that the recommendation is to publish the nested templates on a public Git Repository ??? With all my respect, please be serious.

  • Bon Franklin commented  ·   ·  Flag as inappropriate

    I think this simply isn't possible. When the ARM API processes a linked template element it happens in the Azure datacenter. And it can't then call back to your machine and ask for another local file, because it is simply a server API, not a client/server application that prescribes behavior of the client. Each ARM template deployment is a request and a response. And the request sends the entire template. The server responds with metadata to identify that deployment, so in theory the system could be configured such that you could use that identifier and make a second call to pass the linked template so that the server execution of the ARM template is able to access it, waiting until it arrives.

    The only way to ensure that the linked template is private is to use a one time disposable URL or an Azure Storage SAS token with an expiration date in a reasonable time to ensure it is still available by the time your linked template gets called.

    Sorry everyone, but I just don't think this can happen.

  • Katrin Shechtman commented  ·   ·  Flag as inappropriate

    Please, please, please - it is one of the most important missing features along with generating passwords!

  • don commented  ·   ·  Flag as inappropriate

    Seconds that as local file support has its advantage over online repo as there maybe a need of retaining json files on a local machine due to compliance and security requirement. Have tested suggestion from Michael however it's more applicable for devtest environment not local machine. Would be delighted to see this error message go away #Azure

    The provided content link 'file:///E:/ps/arm/helloworld.json' is invalid or not supported. Content link must be an absolute URI not referencing local host or UNC path.

  • Tim commented  ·   ·  Flag as inappropriate

    Only being able to reference a URL for the templatelink means I have to check in my code (template) changes *before* I can test them, which is untenable.

    I'm sure it's difficult to achieve support for local files but it would be a significant improvement.

    Thanks

  • Jonathan commented  ·   ·  Flag as inappropriate

    Couldn't agree more with this. While it is not specifically accurate that we are forced to put them in a publicly accessible location, the process for making that location private yet accessible (SAS tokens, etc.) is another complicated layer. Generate tokens, etc. where to keep these? can't check them in, so we need code to reference a key vault to get the token to reference the private storage to reach the templates.... yuck. I have to now design/build an entire system just to read the templates.

    My templates are checked into source control, and I'm editing them right on my box. Let me run them from there. I can already run a single template from there, so there is no access/other security issue that should be blocking this.

    If I want to later go through the effort to move everything to a cloud-based storage location, that should be up to me.

    -Thanks

  • Qiang Li commented  ·   ·  Flag as inappropriate

    It will be a great feature if we can also package all required files/resources (e.g. in an archive format) so the template is self-contained.

  • Kaa commented  ·   ·  Flag as inappropriate

    Michael, that really isn't referencing a local template from a local template like Alex Marshall is suggesting though.

  • Michael commented  ·   ·  Flag as inappropriate

    This already is available. At least, I'm able to reference my linked templates locally. Or, more accurately, I utilize the _artifactslocation variable to utilize a storage acct that only I have access to to host the templates while I deploy.

Feedback and Knowledge Base