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 ,
I appreciate all your help.
Can I ask just two more things, please?
- For the above JSON, can you provide the FULL script you created?
- Second, this is an example (https://github.com/Azure/Azure-Sentinel/blob/master/Workbooks/SentinelCosts.json) of an existing Workbook Template (templateData) for Sentinel Costs I am trying to deploy. Based on the Test Workbook you deployed, what is the FULL JSON structure I require?
Thanks again for your input.
Jason
Hi Jason,
What you are doing is really quite unusual. The workbook you want to deploy is already in Content Hub so anyone with the right permissions can search for it and enable it there.
What you can do if deploying this content through code is a necessity is manually enabled the workbook through content hub and then after it succeeds look at the deployments on your resource group and grab the IDs for the Content Package and Content Template.
Ultimately everything in cloud uses REST API - it doesn't matter if it's Azure, AWS or GCP. ARM just provides a template for REST and Bicep is templating for ARM. With Bic ep and ARM looking at the JSON representation of an object lets you see what the property names and values are that you need in a template.
What I posted before is the full representation of a JSON object for creating content that includes a workbook. If you want to work with REST in getting and pushing objects into Azure, I have published a https://laurierhodes.info/node/171.
Where possible I'd prefer to use Bicep now for creating templates - but you can create ARM templates from Bicep.
https://learn.microsoft.com/en-us/azure/templates/microsoft.securityinsights/contentpackages?pivots=deployment-language-bicep
Content Hub is intended to be used through the portal... I would just enable the workbook you want that way. Thats how we have to update the content when new versions come out anyway and if we must use the portal for content management, I don't see the criticality of managing that content through code.
However, if you really must use code, I've included the JSON from my deployments below (with alteration of the Id that points to my subscription). It's too much data for the chat thread to accept so https://github.com/LaurieRhodes/PUBLIC-Scripts/tree/main/Example%20Sentinel%20Content%20Package.
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.