New-AzTemplateSpec should support destinations other than ResourceGroups

[ChristopherGLewis]

New-AzTemplateSpec should support destinations such as Subscription and ManagementGroup.

[alex-frankel]

Hey Chris,

Can you give me some more clarity on the scenario? Why do you need to store the templateSpecs at these scopes?

[azMantas]

Hey, We have a scenario where we have to simplify RG creation (a lot of tags) and it could be nice to use templateSpecs for it.

[slavizh]

@azMantas the resource group is where your template specs are stored. Your template specs could be for example subscription level deployments that include creation of resource group. So you could do New-AzDeployment -TemplateSpecId instead of New-AzResourceGroupDeployment -TemplateSpecId if your template spec is subscription level deployment.

[azMantas]

@slavizh I have no issues with powershell. The limitation I am facing is in the portal, where RG is a mandatory. I've also tried a preview portal, but no luck. I do believe that is another issue I am talking about. My bad :)

[slavizh]

@azMantas sounds to me that you are mixing deployment of template spec as resource and deployment that uses template spec. Template spec as resource is at resource group level but you can have template spec that deploys at any level. The portal does not expose any template spec specific feature so from portal you cannot make ARM Template deployment that references template spec resource.

[alex-frankel]

@slavizh - is correct. The template spec can be used to kick off a deployment to any scope, even though the template spec itself is stored at a resource group. preview.portal.azure.com has been updated to allow for portal-based deployments to any scope, but it is not yet tied up to template specs.

[ChristopherGLewis]

My thoughts were that TemplateSpec's were going to be implemented somewhat similar to BluePrints, which are available at the MG or SUB level.

If I walk through the current model MS proposes (hub and spoke networking, multiple subscriptions based off prod vs Dev/Test) I would end up with an RG called "TemplateLibrary" in the production Hub subscription. In order to provision a TemplateSpec in that RG, I'd need at least read access to the RG and if I'm changing the TemplateSpec I'd need (I believe) contributor.

My challenge is that anyone who uses the TemplateSpec would have to have access to this shared RG. By having its home at the MG or Sub level I can use the hierarchy and deploy to anything below the MG/Sub. Placing the TemplateSpec in a RG puts the burden of usage/security on RBAC rights, not inheritance from the MG/Sub - like BluePrints do currently.

Another issue would be how do TemplateSpec's work with BluePrints? If a BluePrint is at a MG level, how is it referencing a TemplateSpec in a RG? Do you then have all the added issues with not being able to move a Sub in the MG tree if there's a reference to a MG level resource that would break a link? (Like what happens with custom RBAC at the MG level)?

I understand that this is a major change from what you've implemented, but I've always envisioned the TemplateLibrary/TemplateSpec being a resource at the MG/Sub level like a BluePrint.

[alex-frankel]

@ChristopherGLewis - your analysis is all correct. We made a tough choice to store this at the RG. It keeps it in line with other "central" resources like User-assigned managed identities or shared image galleries. Being an RG-scoped resource comes with a lot of other benefits, so we decided it was worth the trade-off.

For blueprints, the principal doing the deployment would need read access to the TemplateSpec (or parent RG), so if the TemplateLibrary is in a different sub, you would need to use a user-assigned managed identity with read access to the TemplateSpec(s).

We get there is now some more friction, but our hope is that this does not create a blocking issue. If you feel it's blocking, let us know.

[lunar87]

@alex-frankel I would encourage you to look at https://github.com/Azure/Enterprise-Scale/blob/main/docs/reference/adventureworks/README.md as an example of what the field is communicating to our customers. Template Specs needs to be able to snap into this framework as this is the enterprise guidance we are giving customers. My first instinct is that template specs needs to be in its own subscription or maybe the management subscriptions.

[alex-frankel]

To be clear, any template can be deployed to any scope via Template Specs. Template Specs really just changes where the source of the template is. The template could come from the local file system, or an external URI, or now via this TemplateSpec resource in the resource group.

@lunar97 -- Can you clarify what you are seeing in the enterprise scale templates that can't be deployed via template spec?

The template spec resource does need to exist in a resource group in a subscription, but from there it can be deployed to any scope in the tenant.

[EldertGrootenboer]

@alex-frankel I'm jumping in here, to make sure I understand correctly and maybe also help on the question @lunar87 has. As I understand it, the Template Spec could be stored in my tenant under subscription A. Now if I want to create a resource in subscription D, I would still use the Template Spec stored in subscription A by using a resourceId with subscriptionId parameter set? And similar for a Management Group scoped deployment, where we would still reference the Template Spec in subscription A, but use it on a MG level.

And to make this work, we would need to have the right RBAC set on the resource group in subscription A, to allow whoever / whatever is doing the deployment (in my case probably the Azure DevOps agent) to have access to the Template Spec in subscription A?

[J0F3]

@EldertGrootenboer Yes, I think you understand that correctly or at least it is as I understand it also.

As Alex described it also in #30 the creation of the Template Spec it self is like to publish a package/a module to a "repository" like NPM, PowerShell Gallery, Terraform Registry, etc. from which others can consume it. In the terms of Template Specs the Repository would be a Resource Group in a Subscription and everyone who has (read?) access to it can consume it/use it in their deployments. So yes mostly these would be Identities used in CI/CD Pipeline like Azure DevOps Agents which would have access to the Resource Group with the Template Specs. Either to publish new Versions or to use the Temple Spec during a Deployment happening in the Pipeline.

At least that's my understanding of the Template Specs, so far.

@alex-frankel Please correct if wrong or inaccurate. 😊

[alex-frankel]

Yes - @EldertGrootenboer and @J0F3 you are both understanding things correctly. Let us know if you see any issues with how it works.

[lunar87]

@alex-frankel I was concerned before, but based on comments/additional info it looks good. I just wanted to emphasize that cross subscription deployment will be the norm for any CAF based customers. Based on above then there are plans to add templatespecID param support for New-AzDeployment, New-AzTenantDeployment and New-AzManagementGroupDeployment?

[alex-frankel]

Planned and executed ;) The -TemplateSpecId parameter should be on all of the New-Az*Deployment cmdlet after installing the Az.Resources module from this repo.

@ChristopherGLewis -- any other thoughts you would like to add to this one? Otherwise, I will plan to close this tomorrow and mark it as "Won't Fix" for others that come across the issue.

[J0F3]

@alex-frankel : I see absolutely no issues with that. In contrary, I like the ability to "publish" verified and tested templates as an "artifact" to central location, form where other can use it in their deployments, very much. Furthermore I like how it makes the sharing and re-use of linked templates much easier. Simple sharing and reuse of code was, in my experience, always an argument for using Terraform when it camas to the question of using ARM or Terraform. But now with Template Specs ARM has a similar, if not even a better, ability. 👍

[ChristopherGLewis]

@alex-frankel I would still like to pursue a generic TemplateLibrary at the Sub/MG level.

We currently have a template library in "Templates" from the portal ( I believe its the Microsoft.Gallery resource ) - I'm assuming this is going to be deprecated going forward or is this resource going to support TemplateSpecs (my initial hopes) ?

I would have imagined it would have been harder to support TemplateSpecs in the TemplateGallery rather than the stand-alone TemplateSpec object.

My challenge with how TemplateSpec's are implemented is that there's going to be a lot of confusion when a template deployment breaks - was it the TemplateSpec itself or was it a permissions issue. I can tell you right away that most of the time it's going to be a permissions issue.

[alex-frankel]

We are planning to support migrating the template gallery into TemplateSpecs. Today the templates in that gallery are tenant level resources and user's must be given explicit permission right? I don't think there is a way to give user's permission to "everything in the gallery" today unless they have explicit Tenant level rights.

@ChristopherGLewis, I'm happy to leave the issue open and we can see if there are more requests for this change/enhancement. We will also keep our eye on telemetry/support cases to see if permissions errors become a significant problem.

[ChristopherGLewis]

We are planning to support migrating the template gallery into TemplateSpecs. Today the templates in that gallery are tenant level resources and user's must be given explicit permission right? I don't think there is a way to give user's permission to "everything in the gallery" today unless they have explicit Tenant level rights.

I believe Templates require explicit "Shares" - even if you're owner of the sub they are in (!).

@ChristopherGLewis, I'm happy to leave the issue open and we can see if there are more requests for this change/enhancement. We will also keep our eye on telemetry/support cases to see if permissions errors become a significant problem. @alex-frankel - Thanks. Definitely reasonable to keep this open and explore permissioning issues.

[alex-frankel]

I believe Templates require explicit "Shares" - even if you're owner of the sub they are in (!).

Right, they are not subscription scoped resources. They exist at Tenant scope. So at the very least, sharing TemplateSpecs should be much easier than sharing Templates from the gallery.