I built an open-source tool for running ARG governance checks on a schedule and tracking findings
Most of the Azure governance work I have done over the last ten years ended the same way. Someone writes a sharp Resource Graph query, it finds something real, it gets pasted into a chat, and then it lives in that person's terminal history until they move on. The failure that costs more is quieter. A check that stops running does not turn red. It stays green, and the estate keeps drifting behind a number that nobody has any reason to distrust. Disclosure before I name anything: I built the tool below and I maintain it. RuleBeat runs the governance checks your team writes for Azure on a schedule, tracks every finding over time, and never holds write access. A check is a rule you author against Azure Resource Graph or Microsoft Graph, in a visual builder or as raw KQL. It ships 158 checks out of the box, 15 built-in rules plus the 143-rule APRL pack. Findings keep their lifecycle across scans, so they move through new, active and fixed and reopen on their own, and a suppression needs a reason and can carry an expiry date. The trade-offs, so nobody has to discover them after installing: - Read-only, permanently. It never holds write credentials and never creates its own service principal. You create the credential, so you can see in Azure RBAC exactly what it was granted. The cost is real: there is no one-click fix. Remediation stays your action under your own identity. - Self-hosted, one container, SQLite inside. Nothing about your tenant leaves your deployment and there is no telemetry. The cost is that you run it. Demo mode runs the real UI over a generated database with no Azure credential, if you would rather look before wiring anything up. - Honest numbers. A rule that has never run, or whose last run failed, is reported as unknown rather than passing. The posture number is uglier for it, and that is the point. On where this does and does not belong next to the native stack: Azure Policy is for enforcing a standard, and it does that better than anything I would write. Defender for Cloud covers its own scope well. If your assignments are enforcing, your Workbook answers the question you actually ask, and one person owns the whole loop, you do not need this. Where I kept running out of road was the organization-specific check that no built-in standard covers, and the question of who owns a flagged row once more than one person has to care about it. It is open source under Apache-2.0 and free, and it is v0.2, early on purpose. I build it with AI assistance from Claude, which the public commit history shows in the co-author trailers, and every change is human-reviewed and gated by the test suite in CI before it ships. Repo: https://github.com/rulebeat/rulebeat Docs: https://docs.rulebeat.com The question I would rather ask than answer: for those of you running recurring governance checks today, what do you do with a finding that is accepted on purpose? Every version of this I have seen was a tag, a wiki page, or a spreadsheet, and all three drift away from the query that produced them. I would like to know what has actually held up for you.
Misplacement of schema in AllowedHostPathVolumesInKubernetesClusterList Policy Parameter?
In the Microsoft Cloud Security Benchmark, the policy parameter `AllowedHostPathVolumesInKubernetesClusterList` defines a `schema` object nested under metadata. Is this placement intentional, or should the schema be defined at the top level of the parameter https://github.com/Azure/azure-policy/blob/303a0000a3b9d1aed7361c69edaafd4340d37df7/built-in-policies/policySetDefinitions/Azure%20Government/Security%20Center/AzureSecurityCenter.json#L4132
Script or Query for Management Group Compliance Statistics
I've been trying to reproduce the Azure Portal Compliance statistics for a Management Group in a PowerShell script or Resource Graph query without much luck. What I'd like to do is reproduce the numbers like compliance percentage, number of compliant / non-compliant resources, in the portal display. And run a daily script or query to track the numbers over time. (Without doing screen shots every day.) Just to be clear, I've attached a screenshot of a compliance screen for management group TEST1. I want to automate calculation of the Overall Resource Compliance (46%, 317 out of 692), and the policies/initiatives compliance state and resource compliance percentages at the bottom of the screen. I'm only interested in the resource compliance percentages below a threshold like 90% in order to help guide our remediation efforts. I've found several scripts and resource graph queries online but none seem to address management group scope. And even the ones that produce numbers for subscription scope don't seem to match the portal numbers. Has anyone successfully reproduced the portal MG compliance numbers with a script or quiery? Or, is it possible to obtain the logic behind the portals' MG scope compliance code? Seems like we should be able to reproduce the numbers shown by the console. Thanks.
Restrict Cost Consumption by using Azure Automation, Budget and Policy
Video See the demo video by using below link Demonstration Video Automation Runbook Logic Logic which set tag value once threshold exceeds # Authenticate using Managed Identity (recommended for Automation Accounts) Connect-AzAccount -Identity # Define Subscription ID and Reset Tag $subscriptionId = (Get-AzContext).Subscription.Id $tags = @{ "cost exceeded" = "yes" } # Resetting the tag value # Update the tag Update-AzTag -ResourceId "/subscriptions/$subscriptionId" -Tag $tags -Operation Merge Write-Output "Tag 'cost exceeded' reset to 'yes' for subscription $subscriptionId" Logic which reset tag value every month # Authenticate using Managed Identity (recommended for Automation Accounts) Connect-AzAccount -Identity # Define Subscription ID and Reset Tag $subscriptionId = (Get-AzContext).Subscription.Id $tags = @{ "cost exceeded" = "no" } # Resetting the tag value # Update the tag Update-AzTag -ResourceId "/subscriptions/$subscriptionId" -Tag $tags -Operation Merge Write-Output "Tag 'cost exceeded' reset to 'no' for subscription $subscriptionId" Azure Policy Logic { "properties": { "displayName": "budget", "policyType": "Custom", "mode": "All", "metadata": { "version": "1.0.0", "createdBy": "f6bb4303-e52d-4cba-9790-01f0798164b7", "createdOn": "2025-03-13T05:08:05.8483517Z", "updatedBy": "f6bb4303-e52d-4cba-9790-01f0798164b7", "updatedOn": "2025-03-13T06:32:35.1740944Z" }, "version": "1.0.0", "parameters": {}, "policyRule": { "if": { "allOf": [ { "field": "type", "notEquals": "Microsoft.Resources/subscriptions" }, { "value": "[subscription().tags['cost exceeded']]", "equals": "yes" } ] }, "then": { "effect": "Deny" } }, "versions": [ "1.0.0" ] }, }
Azure Policy require multiple tags with values
I have a policy that requires specific tag with specific values (json below), but I want to require more tags within the same policy also with specific value and not sure how to do it... Is there a way to add more tags with specific values to the same policy? For example, I want to require two tags: environment with prod/non-prod and department with Infra/Finance Is it possible? Thank you! { "properties": { "displayName": "Require tag environment and its values on resources ", "policyType": "Custom", "mode": "Indexed", "description": "Enforces a required tag environment and its value. Does not apply to resource groups.", "metadata": { "category": "Tags", "createdBy": "" "createdOn": "" "updatedBy": "" "updatedOn": "" }, "version": "1.0.0", "parameters": { "tagName": { "type": "String", "metadata": { "displayName": "Tag Name1", "description": "Name of the tag, such as 'environment'" }, "allowedValues": [ "environment" ] }, "tagValue": { "type": "Array", "metadata": { "displayName": "Tag Value1", "description": "Value of the tag, such as 'production'" }, "allowedValues": [ "prod", "non-prod" ] } }, "policyRule": { "if": { "not": { "field": "[concat('tags[', parameters('tagName'), ']')]", "in": "[parameters('tagValue')]" } }, "then": { "effect": "deny" } }, "versions": [ "1.0.0" ] }, } }Azure Inherited roles, but still access denied
Hi, In e.g. Key Vault, when looking for the Access Control I can see that user account have custom contributor role inherited from the subscription level. When looking for the role more deeply it shows: "Showing 500 of 15937 permissions View all (will take a moment to load)" E.g. having the following permissions: Read Secret Properties and Write Secret. So all should be kind of okay..? 🙂 But when I'm looking for the e.g. secrets in the key vault, it gives me back "The operation is not allowed by RBAC." and "You are unauthorized to view these contents.". I thought there could be a "deny" rules, but nothing in there either. What could be the trick on here? What might be blocking or missing the access to the resources. Btw, I just tested, I was able to create the Key Vault by myself.How to get Policy "Windows VMs should enable ADE or EncryptionAtHost." to be compliant?
Advisor noticed that Azure Disk Encryption is missing on my VMs and gave me the following recommendation: "Windows virtual machines should enable Azure Disk Encryption or EncryptionAtHost." A couple of weeks ago I installed the AzurePolicyforWindows extension on one of the machines. Its status changed to compliant. Two days ago, I did the same for all other VMs but their statuses haven't changed. Am I missing something or are the policies messing with me?
Microsoft Cloud Security Benchmark policies not reporting in Defender for Cloud
We enable the MCSB security policy at our tenant level and manage compliance via Defender for Cloud. However, I have found that some of the policies are listed are not showing in the Defender for Cloud recommendations. For example, the policy "Azure SQL Managed Instance should have Microsoft Entra-only authentication enabled" is visible via Defender for Cloud>Environment Settings>Security Policies>MCSB and is linked to Policy Id 0c28c3fb-c244-42d5-a9bf-f35f2999577b. Within Azure Policy Compliance, I can find the policy in the assignment for MCSB and it reports both compliant and non-compliant resources in my tenant. However, there is nothing reported in Defender for Cloud for the policy under the Recommendations>All Recommendations. I have checked the filters applied and know it should be there - the similar policy is showing correctly (named "Azure SQL Managed Instance authentication mode should be Azure Active Directory Only" in the recommendation and security policies, and named "Azure SQL Managed Instances should have Microsoft Entra-only authentication enabled during creation" in Azure Policy - 78215662-041e-49ed-a9dd-5385911b3a1f). Any suggestions on what could be causing this behaviour ? Regards Dominic
Microsoft's inconsistent implementation of tagging in Azure
We revamped our Azure resource tagging strategy several years ago and rely on them heavily for #Governance and #FinOps. We not only enforce #tags via #AzurePolicy, we also enforce tag values based on a set of permissible values for each tag. Even with that in place we experience some drift due to exclusions required in the policy definition or exemptions in the policy assignments. I won't get into why this flexibility is needed here, that's a whole separate discussion. Establishing a sound tag hygiene process becomes a vital component of your overall governance and FinOps strategies. One method we employ for tag hygiene is to surface the non-compliant resources in a #PowerBi report using an #AzureResourceGraph (ARG) query. Yes, you can do this in the Compliance section of Azure Policy as well however it lacks ease of use. For example, flipping back and forth between policies, filtering by subscriptions, surfacing other linked metadata is a cumbersome experience in the Azure Policy blade. Now onto my frustrations with how Microsoft has implemented tagging across Azure. 1. Inconsistent application of Tag case-sensitivity across tools - In Azure Policy and in the Azure portal, tag names are case-insensitive whereas tag values are case-sensitive. - In Azure Resource Graph Explorer, both tag names and tag values are case-sensitive. - Why is there inconsistency with case-sensitivity of tag names? 2. Inconsistent Tag validation across Resource Types - When deploying a Storage Account, Azure validates my tag policy before I am able to hit the create button (before it's submitted to ARM) whereas when deploying a resource like a Public IP Address, that validation only occurs after you hit the create button. This likely happens with other resource types as well. By the way, my tagging policy specifies "Indexed" for mode, so in effect it should apply to any and all resources that support tagging in Azure. - Why is does the evaluation of the tag policy differ based on the resource being deployed? 3. Inconsistent Tag UX across Resource Types - When deploying a Storage Account, the tags input is a drop-down list. However, when deploying an Azure Virtual Machine, the tags input is a textbox. Although the latter makes use of predictive text, it's still clearly a different experience. This inconsistency is found across multiple Azure resources. - Why is the tag UX different between resource types? I realize some of this is addressed or is less of a concern when using IaC but that may not be for everyone, or work in all scenarios. It would be great if Microsoft could standardize their implementation of tagging resources uniformly across the entire Azure estate. In my opinion I don't think that's a huge ask.
