NSG Flow Logs Governance
1 part Built In Azure Policy, 1 part Custom Azure Policy
*Microsoft recently released BuiltIn Policies for NSG Flow Logs on July 22 2021
Microsoft recently released additional Built In Azure Policies. One of these policies “Deploy a flow log resource with target network security group“ will scan the Network Security Group (NSG) resources to see if the NSG has Flow Logs turned on. If not the Azure policy will utilize DeployIfNotExists (DINE) to turn on Network Watcher and send the flow logs to a storage account.
While this is great, a lot of organizations I work with enjoy leveraging Traffic Analytics which uses the NSG flow logs but needs the flow logs sent to Log Analytics workspace to visualize top talking pairs inbound \ outbound flagged by Microsoft Threat Intelligence. You can also leverage Azure Sentinel and your Threat intelligence feeds with NSG Flow logs and detect matches.
Unfortunately the Azure policy did not have a setting to DINE and set the Flow logs to a Log Analytics workspace. I just created a Custom Azure Policy Here that will do this.
While looking at this it brought back some work I did earlier for a customer in July 2020 around a custom Azure policy that did this but would DINE and update the diagnostic settings . However this policy did not go through the Network Watcher alias like this new Built In policy does.
So… I figured why not export the Azure Built In policy and modify it as a new custom Azure policy.
After downloading the JSON export and cranking up Visual Studio Code I started investigating the additional objects and fields needed to configure the NSG to use Traffic Analytics and send the flow logs to Log Analytics workspace. I used the ARM Template Reference for Network Watcher - Flow Logs to aide in expanding the capability.
Seemed simple enough, scroll to ARM template portion of the policy that uses Deployment Resource. then add the extra objects format{ } and flowAnalyticsConfiguration { }.
Then start filling out the values, in many cases creating a new parameter so that at assignment you could fill in the answer to the value.
Now that I created some new parameters here I needed to add these three more times so that they could be defined in assignment of policy and pass into the ARM Template that would leverage DINE.
With the updated custom Azure policy json code, I created a new Azure policy definition.
After I got the custom policy uploaded I applied an assignment to a test Resource Group that has a few NSGs and filled out the new parameters pointing the Log Analytics Resource ID, Log Analytics Workspace ID, and the location of the Log Analytics workspace.
And…
The remediation task failed. Sigh… Troubleshooting time.
The first problem was when I went to assign the policy it created a Managed Identity (MSI) for the remediation tasks but placed the RBAC Contributor rights of the MSI at the Resource Group (RG) level. Well the ARM template portion calls the Deployment Resource which is at a subscription level so it immediately failed as the MSI had no permissions to use the Deployments resource to remediate the NSGs.
Ok where is the MSI’s SPN or Identity so I can manually grant it rights to the Subscription ? Keep in mind if the policy was assigned at the Sub level or higher this would not have been an issue. However we always want to test policies at RG level first before deploying to the Subscription to make sure it does what it needs to do and does not create problems or errors out.
To find the identity of the MSI so you can apply a role at a different scope or different roles you can use this Azure Docs article.
Basically the Azure Policy Assignment ID contains the MSI you can plug into Identity and Access management blade.
/subscriptions/{subscriptionId}/resourceGroups/PolicyTarget/providers/Microsoft.Authorization/policyAssignments/2802056bfc094dfb95d4d7a5
Now with the Azure policy assignment id I was able to at the subscription level assign Contributor role to the MSI.
Afterwards I went to the Policy Assignment and Remediation Task and create a new one. and...
Failed, when clicking the error it was very basic telling me to go to the deployment logs to get details.
hmmmmmmm. where are the Network Watcher alias deployment logs to further troubleshoot ? They are not stored in any Resource Groups I could find. Thankfully these can be found on the same screen by clicking the ... ellipses and choosing deployment.
{\r\n \"error\": {\r\n \"code\": \"InvalidRequestContent\",\r\n \"message\": \"The request content was invalid and could not be deserialized: 'Could not find member 'format' on object of type 'TemplateResource'. Path 'properties.template.resources[0].format', line 1, position 781.'.\"\r\n }\r\n}
This took awhile I had to stare in VS Code but then finally figured out what I did. While Copying and pasting the format and flowAnalyticsConfiguration objects { } I placed them outside the properties of the Network Watcher flow logs resource.
Nice to note here, even with the Azure policy in an assignment you can edit the definition and correct the mistake without having to decouple or reapply the policy assignment.
Finally with another remediation task running correctly this time the NSG flow log settings were updated properly to collect and send them to the Log Analytics workspace so that you can use Traffic Analytics.
The nice thing about this Custom policy is you can set it at Subscription or Management Group level and ensure you are collecting all traffic flows where NSGs are applied in your environment.
The finished Custom Azure Policy is here: with it your organization will be configuring any NSGs to collect the flow logs and send them to a Log Analytics workspace where you analyze and troubleshoot further and visualize using Traffic Analytics.
Alright Synthwave Saturday is almost over and I am logging off for the night. See you out there in the Azureverse.