Forum Widgets
Latest Discussions
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
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" ] }, }
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.
Wish: Add 'Customer Name' to Azure Portal Views as a Column (or 'Group By') Option
I work for a CSP and use Azure Lighthouse to manage many customer environments. All of the Azure portal views are focused on the concept of the subscription being the top level management object in Azure (I'm excluding Management Groups for policy management). I'm sure this works well for single organisations that use Azure portal, but for CSPs we need to be able to order/arrange/group lists based on customer name first and then by subscription. In other words, our administration view has to start one level above subscription compared with most organisations. I know you can change the directory filter if you want to work on a single customer's environment and limit the view to their resources, but most often we are managing at scale and operating on multiple customer estates at once and as such we need lists to be built around the customer as the topmost object rather than the subscription. When we are confronted with a long list of subscriptions (some of which being unhelpfully named 'Subscription 1' or 'Azure' by customers who have not followed CAF...) it is impossible to determine which customer that sub relates to without following each and every subscription link. It's onerous. Not all customers allow us to impress a subscription naming convention on their Azure environment (we might be contracted to only support a subset of their subscriptions and they are unwilling to change them). An example would be the Virtual Machines list. Microsoft offers no fewer than 33 'Group By' attribute options, none of which is 'Customer'. Some views allow you to add a column and Group By tag, but a surprisingly small number of views support column manipulation. I'm hoping someone from the MSFT PG sees this and hears my plea: please keep CSPs in mind when designing Azure Portal and allow us to add a column for 'Customer Name' throughout, it would be of huge benefit to us!Azure Advisor aggregate score for 2+ subscriptions - how is it calculated?
Dear all, I would like to understand how Azure Advisor calculates aggregations for the 5 pillars, for multiple subscriptions. In the example below we have values for Azure Advisor subscription 1 – (Cost = 68, Security = 47, Reliability = 86, Operational Excellence = 83, Performance = 100) And subsequently values for Azure Advisor subscription 2 - (Cost = 35, Security = 69, Reliability = 91, Operational Excellence = 79, Performance = 100) When selecting both subscriptions, we obtain the aggregate values – Naively I might have expected that the aggregate advisor scores could be the arithmetic average between the two, but that is not the case. Any help is much appreciated! ❤️ Thank you very much in advance, Best Regards, Eva
Azure Policy - Configure backup on virtual machines with a given tag
I wonder if somebody could sanity check something for me with this please in case it's something I could be missing. We have this existing policy configured in a customers tenant (https://www.azadvertizer.net/azpolicyadvertizer/345fa903-145c-4fe1-8bcd-93ec2adccde8.html After creating a VM and allocating the correct tag etc. it didn't automatically have the backup policy assigned to it. With the policy assignment itself it didn't even appear as a non-compliant resource. I went through the checks to make sure it was the same region, correct tag, correct rsv and policy, which all appeared to look fine. When remediating it still wasn't pulling the resource through. When I went into the definition detail to see what could be amiss, I noticed the list of WindowServer image SKU's that were listed (image attached here https://i.stack.imgur.com/1YPpM.png. As I was sanity checking everything, I looked at the VM to see that the SKU wasn't actually in this list (2019-datacenter-smalldisk-g2). As every SKU is listed specifically it makes me think this image has just been missed off and needs adding? Rather than it getting captured by one of the SKU's listed. I can add the VM manually to the existing RSV for now but for future ref, is there a way I can raise this if my findings are indeed correct?AWESOME Azure Policy
Azure Policy is a very powerful, but sometimes frustrating service to learn, adopt, and troubleshoot. Years ago when I first started getting into the technical nitty gritty side of Azure Policy I quickly learnt that I could save myself hours of time in trial and error simply by combining Microsoft sources of information (e.g. Microsoft Docs) with trusted community sources containing examples and how-to-guides. And so in January of 2022 the https://github.com/globalbao/awesome-azure-policy was born -- a curated list of AWESOME blogs, videos, tutorials, code, tools, scripts...anything which can help you learn Azure Policy and quickly get started with designing, planning, and implementing governance controls to your resources. There's currently over 380+ links to awesome Azure Policy content within! You're more then welcome to submit pull requests to the project as that's the only way we can keep up with the pace of new content being released globally.
Deleting an Azure Blueprint
Quoting an excerpt from https://learn.microsoft.com/en-us/azure/governance/blueprints/concepts/lifecycle "The core blueprint can also be deleted. Deleting the core blueprint also deletes any blueprint versions of that blueprint, including both Draft and Published blueprints. As with deleting a version of a blueprint, deleting the core blueprint doesn't remove the existing assignments of any of the blueprint versions." The last line in the above quoted text "deleting the core blueprint doesn't remove the existing assignments of any of the blueprint versions" doesn't make sense to me. How is this possible? Because if we have to delete the core blueprint, we'll have to unassign it, and deleting the core Blueprint will also delete all the versions, which would automatically mean exiting assignments will have to be removed.
Newly created resource and tag unavailable in Budget filter list due to cost being under $0.01
We have a Shopify app running on Azure, and it creates resources automatically when a merchant installs our app on their Shopify store. This allows us to know costs associated with a merchant's app usage by who installs our app. Our goal is to use PowerShell functions to create these merchant resources and the associated cost monitoring and alerts yet, Azure's budget logic does not show filter tags for resources whose costs are less than $0.01. This essentially means a human will need to monitor such resource costs until they are over $0.01 before creating any budgets and alerts for said resource. Computers are meant to reduce human effort, and MS Azure developers have inadvertently created the scenario for this use case to require human monitoring vs their system. Microsoft Azure developers, please remove this $0.01 threshold, so budget filters can show newly created resources and tags to create budgets automatically using PowerShell. Thanks, JohnQuery for NZ ISM versions
What are the different between NZ_ISM_Restricted_v3_5 and nz_ism.? https://github.com/Azure/azure-policy/blob/master/built-in-policies/policySetDefinitions/Regulatory%20Compliance/NZ_ISM_Restricted_v3_5.json https://github.com/Azure/azure-policy/blob/master/built-in-policies/policySetDefinitions/Regulatory%20Compliance/nz_ism.json Also, I see the latest version of NZ ISM is 3.6. Will we have the latest update for NZ ISM?
