Is it possible to overwrite Azure resource values with Azure policy values? I am trying to fix the VM size/sku. I created the below Policy with an append effect which fails VM creation as it cannot overwrite the default/given VM size/sku.
{
"if": {
"field": "type",
"equals": "Microsoft.Compute/virtualMachines"
},
"then": {
"effect": "append",
"details": [{
"field": "Microsoft.Compute/virtualMachines/sku.name",
"value": "Standard_D4_v3"
}
]
}
}
No, it is not possible to overwrite a resource value using an ARM policy append effect. The behavior you are experiencing is by design as described here.
Since a VM's SKU is a single value vs. a collection/array of values, the only action you could hope to take is to overwrite the original value. But, as you are seeing, an ARM policy will revert to the deny effect instead in this case.
Related
I am deploying the Azure policy for the Recommended Tags that need to be applied when anyone creates the new VM.
I found one in-built policy: Require a tag on resources
But when I deployed, it will be applied to all the resources and I need a policy for only VM resources.
Also how I can use more than one tag in a single policy?
In your policy rule, you must indicate that the policy is just for VMs
For example:
...
"policyRule": {
"if": {
"field": "type",
"in": [
"Microsoft.Compute/virtualMachines",
"Microsoft.ClassicCompute/virtualMachines"
]
},
"then": {
...
}
}
...
Hope this helps!
Sorry for this basic topic but I am pretty confused about azure Management Groups and policy.
I have a production subscription, on which I would like to deny all the manual creation of resource and allow only the creation the resource as code.
Which mean, if I try to create or change a resource from the portal, to get an error, but if I want to create the resource with terraform or bicep, to be able to do so with the terminal.
So what I did, in my Management Groups I added a child group and assigned the subscription. On the child group, I created the policy to deny all the Microsoft.* as follow:
{
"mode": "All",
"policyRule": {
"if": {
"field": "type",
"like": "Microsoft.*"
},
"then": {
"effect": "deny"
}
}
}
This works just fine, but how can I still be able to create resource with terraform or bicep using the terminal?
Or maybe somebody can advice me on a better approach on how to solve this problem please?
Thank you very much
If you apply this policy, it will be valid for service principals as well.
A better approach would be to restrict the RBACs of users(like Reader) and use only a Service Principal to deploy resource to Azure. That's a more simple approach.
I am creating a policy to check if the Blob container access level is set to "Anonymous" in Azure Storage accounts.
This is the policy that i have created.
{
"properties": {
"displayName": "check if Blob container access level is set to Anonymous",
"description": "check the container access level",
"mode": "all",
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts/blobServices/containers"
},
{
"not": {
"field": "Microsoft.Storage/storageAccounts/containers/publicAccess",
"equals": "False"
}
}
]
},
"then": {
"effect": "Audit"
}
}
}
}
Its not able to detect the container access level.
As the issue said, Storage team is releasing public access setting on storage account towards Jun 30 2020. Customers can use it to control the public access on all containers in the storage account.
After it's released on storage, we will work with Azure Policy team to integrate the setting with Azure Policy so customers can us Azure Policy to audit and govern public access across storage accounts.
We work the best to ship above features and capabilities as early as possible.
I'm in the middle of writing an Azure Policy to check if hybrid use benefits are enabled. Microsoft provides a built-in policy that will target all virtual machines based on image offerings that are available from the Azure platform. However, some VM's in my subscription are based on migrated VM's and therefor have no link to existing image offerings.
I've found a blog post (https://artisticcheese.wordpress.com/2019/07/04/proper-azure-policy-to-verify-azure-hybrid-benefit-enabled/) that explains how to target virtual machines based on configured OS type rather then image offering.
I've started out small and created the following policy setting:
"if": {
"allOf":[
{
"field": "type",
"equals": "Microsoft.Compute/virtualMachines"
},
{
"field": "Microsoft.Compute/virtualMachines/storageProfile.osDisk.osType",
"equals": "Windows"
}
]
},
"then": {
"effect": "audit"
}
These settings however show all my Windows VM's as non-compliant with the following result:
Reason for non-compliance:
Current value must not be equal to the target value.
Field
Microsoft.Compute/virtualMachines/storageProfile.osDisk.osType
Path
properties.storageProfile.osDisk.osType
Current value
"Windows"
Target value
"Windows"
Am I interpreting the "equals" operator wrong here? I would have expected this to turn out as compliant for all Windows-based virtual machines.
If you want to mark resources that are not Windows as noncompliant, you have to change your equals to a not equals. So it would be if it does not equal Windows then it should be non-compliant hence audit.
I want to stop creation of Log Analytics workspaces, what is the best way to achieve this? can you do this via azure policies, if so how?
thank you in advance,
Kelly
AFAIK, the best possible way to restrict creating any resources is using azure policies. Below azure policy will help you in stopping the creation of log analytics workspace in your subscription.
{
"properties": {
"displayName": "Deny creating Log analytics",
"description": "This policy denies creation of log analytics workspace.",
"parameters": {
},
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.OperationalInsights/workspaces"
}
]
},
"then": {
"effect": "deny"
}
}
}
}
It is also interesting to note that with the introduction of the new access control mode "Require Workspace Permissions", users can only see logs for resources that they have the correct privileges to. Therefore allowing teams to utilize a centralized Log Analytics workspace for all their logging needs