Forum Discussion
ARM template for deploying a workbook template to Microsoft Sentinel
Hi Jason,
You are quite right. It's moving quite a long way from the original question but altering the Id string is all that is required to deploy an object to a different subscription.
In Azure, objects can clip together like Lego blocks based on the "provider" element. The Id string refences where something is deployed to and it tells Azure what type of object is being deployed (although most of the time that is also shown as the type property). You dont actually need the name property either - that's always the last element if the Id.
I'm familiar with the argument for deploying everything as code. These content templates are vesioned and are being updated constantly - it will be one headache to keep the versioning in your code templates up-to-date and if they go down the path of not allowing SOC engineers to create detection rules or update content through the portal it will be a tragedy. If your client also wants data connectors also deployed through code that becomes an almighty world of pain and also a security risk as your build pipeline has to be super-privileged with god rights in all systems.
From an Engineer's perspective, seeing Azure as REST objects is really helpful in understanding how it really works and there are still rare times when REST can get around issues with ARM. I use REST all the time as I'm troubleshooting in my sandpit but I still use Bicep (or ARM) when delivering solutions for customers as it's a standard solution that is officially supported by Microsoft. Once you have a JSON object you can find the type of object with Microsoft's https://learn.microsoft.com/en-us/azure/templates/microsoft.securityinsights/contenttemplates?pivots=deployment-language-bicep and it's almost a straight copy and paste of values against properties.
Hi Laurie_Rhodes ,
Thank you for the feedback.
I know what I asked is a bit unusual, but I have a client wishing to deploy everything that does not involve the Portal.
So, the ARM template you provided is one method. Thank you.
The AZRest PowerShell module is fantastic. I will start to look at that...
Just from the example you presented in your help documentation (and now I understand how to retrieve the ResourceID such as a Workbook) can I assume that by retrieving a single object from one Azure Tenant, I can run a cmdlet to Push that same object to different Tenant by redefining the 'ID' parameter is the PowerShell Script with the appropriate Subscription ID, Resource Group name and Workspace name?
An example ResourceID I extracted relating to a Workbook deployed in my environment was as follows:
/subscriptions/1eXXXX01-XXXX-XXXX-XXXX-dfd0XXXX274d/resourceGroups/rg-sentinel/providers/Microsoft.OperationalInsights/workspaces/ingested-data-sentinel/providers/Microsoft.SecurityInsights/contentTemplates/WorkspaceUsage
Jason
Hi Jason,
You are quite right. It's moving quite a long way from the original question but altering the Id string is all that is required to deploy an object to a different subscription.
In Azure, objects can clip together like Lego blocks based on the "provider" element. The Id string refences where something is deployed to and it tells Azure what type of object is being deployed (although most of the time that is also shown as the type property). You dont actually need the name property either - that's always the last element if the Id.
I'm familiar with the argument for deploying everything as code. These content templates are vesioned and are being updated constantly - it will be one headache to keep the versioning in your code templates up-to-date and if they go down the path of not allowing SOC engineers to create detection rules or update content through the portal it will be a tragedy. If your client also wants data connectors also deployed through code that becomes an almighty world of pain and also a security risk as your build pipeline has to be super-privileged with god rights in all systems.
From an Engineer's perspective, seeing Azure as REST objects is really helpful in understanding how it really works and there are still rare times when REST can get around issues with ARM. I use REST all the time as I'm troubleshooting in my sandpit but I still use Bicep (or ARM) when delivering solutions for customers as it's a standard solution that is officially supported by Microsoft. Once you have a JSON object you can find the type of object with Microsoft's https://learn.microsoft.com/en-us/azure/templates/microsoft.securityinsights/contenttemplates?pivots=deployment-language-bicep and it's almost a straight copy and paste of values against properties.