I am looking to configure policy to audit resource groups that contains resources, whether have the particular tag name or not. Policy should not audit the empty resource groups. My requirement is only to perform audit for tags, if the resource group contains resources. Is it a possible scenario for creating policy?
Indeed, Azure Policy makes it possible to audit, and even enforce tagging rules and conventions on your resources.
The Audit effect can be used in your policy to create a warning event in the activity log when evaluating a non-compliant resource, but it doesn't stop the request.
Such a policy rule can look similar to the following:
"policyRule": {
"if": {
"field": "[concat('tags[', parameters('tagName'), ']')]",
"exists": "false"
},
"then": {
"effect": "audit"
}
}
Here are some more examples that demonstrate assigning policies for tag compliance.
Note: To see if your Azure resource supports tagging, see Tag support.
Related
I'm having a hard time to create a policy to deny the creation of network interfaces when the vnic is not connected to specific vnet\subnets (allowed vnets have a specific tag)
It looks like I can restrict the creation based on the network interface fields. In this case the only idea that came to my mind was to have a parameter configured with a list of allowed subnet ids, and deny based on this parameters. In this case I would need to build a separated mechanism to update this policy definition (Maybe a powershell script).
Just would like to ask if this is a good way to get it done and ask for suggestions,
Thanks
Rob
There is workaround ie built-in policy in azure “require an tag on resources” means under selected resource group when you create any resource without having any tag it will failed . Assign this policy in your resource group.
I have named tag ‘Rahul’ without Rahul Tag I won’t be able to create any resource under resource group
Here I repro and found without any specified tag I cannot able create any resources.
Was able to get it done using this:
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Network/networkInterfaces"
},
{
"count": {
"field": "Microsoft.Network/networkInterfaces/ipconfigurations[*]",
"where": {
"value": "[substring(current('Microsoft.Network/networkInterfaces/ipconfigurations[*].subnet.id'),0,lastIndexOf(current('Microsoft.Network/networkInterfaces/ipconfigurations[*].subnet.id'),'/'))]",
"notIn": "[parameters('subnetId')]"
}
},
"greater": 0
}
]
},
"then": {
"effect": "deny"
}
},
And I'll pupulate the parameter with my vnets using the Set-AzPolicyAssignment to update the parameter.
I've created a policy with the subnet as a paremeter, and will use Set-AzPolicyAssignment to update the list of allowed subnets in the policy assignment parameter – TheRob
I wish to create a policy that will prevent the creation of app services without authentication enabled (just auditing them is not enough).
The following policy can correctly identify existing resources that do not have authentication enabled:
{
"mode": "All",
"policyRule": {
"if": {
"allOf": [
{
"field": "Microsoft.Web/sites/config/siteAuthEnabled",
"equals": "false"
}
]
},
"then": {
"effect": "deny"
}
}
}
however it does not prevent them being created in the first place (either via ARM template or through the portal).
I suspect this is because the Microsoft.Web/sites/config resource isn't being explicitly created.
Does anyone know if this is possible?
Apparently, the Microsoft.Web/sites/config/* resource type (except Microsoft.Web/sites/config/web) is not supported by Azure Policy at this point.
Quoting #camillemarie from this similar GitHub issue:
authSettings cannot be managed via policy at this time. In the interest of hiding secrets from users in the default Reader role, this resource provider doesn't expose secrets via GET calls (hence the null in /config/web, and lack of GET support for /config/authSettings).
This means that the existing Microsoft.Web/sites/config/siteAuthSettings.* aliases are invalid. We'll look into removing these, but we don't have a good deprecation story at the moment.
Reference:
Microsoft.Web/sites/config/siteAuthSettings.* aliases are not valid #264
Azure Policy - Known Issues
You can try using the Microsoft.Web/sites/siteConfig alias.
I have an Azure Policy that validates the Region of 2 resource groups via 2 Assignments. The allowed Regions are South Central US and global. My problem is that there are policy violation in each resource group that I can't seem to get rid of. For example, in one resource group, the resource which violates the policy is the Assignment itself, which I cannot change the Region for (or I don't know how to) and I can't see it as an excludable resource in the Exclusions list. For the 2nd resource group, the failing items are a number of SQL database managed instance vulnerability assessments and a number of Security Assessments; the interesting part about these, when I try to view the resources Azure can't find them, just returns "Resource Not Found", so unsurprisingly I can't exclude these either. So right now I seem to be stuck with a Policy and 2 Assignments that cannot achieve 100% compliance, and I'm hoping someone can offer tips to resolve. Perhaps a way to exclude a Type of resource instead of by name, but I'm open to any ideas. Thanks.
Found the answer while digging through the pre-canned Policies. You can put a restriction on the type field in the policyRule.if section as per below. Just have to specify the types that should be excluded.
"policyRule": {
"if": {
"allOf": [
{
"field": "location",
"notIn": "[parameters('listOfAllowedLocations')]"
},
{
"field": "location",
"notEquals": "global"
},
{
"field": "type",
"notEquals": "Microsoft.AzureActiveDirectory/b2cDirectories"
}
]
},
Adding type restriction to your policy will help, but you'll need to maintain the list of excluded resource types.
If you change the mode of your policy to Indexed, then your policy will only evaluate resources which actually have a location field.
I am trying to create a custom role in Azure that would allow Subscriptions "owners" to do quite everything but cancelling/renaming their own subscriptions or moving into another management group.
I would also like them to be able to grant right access to who they want (especially built-in "Contributor" role) but without allowing them to grant "Owner" right, otherwise my custom role could be tricked easily.
I ended up with the following custom role definition which is so far nice and working, apart from the role assignment of course:
{
"Name": "MyCustomRole",
"IsCustom": true,
"Description": "Role designed for Azure subscriptions ownership limitations",
"Actions": [
"*"
],
"NotActions": [
"Microsoft.Management/managementGroups/subscriptions/write",
"Microsoft.Subscription/cancel/action",
"Microsoft.Subscription/rename/action"
],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
"/providers/Microsoft.Management/managementGroups/root.mg"
]
}
In the Azure documentation, the only operation I found for role assignment is Microsoft.Authorization/roleAssignments/write.
Is there any way to restrict that - to Contributor role assignment for instance - directly in the custom role?
Azure Policy might technically do the trick (not even sure), but since some operational/experts/whatever guys might end up as Owner, I do not want the policy engine to display "non-compliant" resources. It would lead customers to misunderstandings that I would like to avoid.
You might want to try Azure Policy, which you can apply on top of your IAM model. You can assign a policy on the Subscription or Management Group level, based on your governance structure.
Policy definition below will block EVERY request trying to assign "Owner" role with no exception. Built-in Owner role is represented by "8e3af657-a8ff-443c-a75c-2fe8c4bcb635", same GUID across all Azure tenants.
However Role assignments of other RBAC roles would still be possible. This should fullfill your use case.
https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles
{
"policyType": "Custom",
"mode": "All",
"displayName": "DenyOwnerAssisgnment",
"policyRule": {
"if": {
"allOf": [
{
"field": "Microsoft.Authorization/roleAssignments/roleDefinitionId",
"contains": "8e3af657-a8ff-443c-a75c-2fe8c4bcb635"
},
{
"field": "type",
"equals": "Microsoft.Authorization/roleAssignments"
}
]
},
"then": {
"effect": "deny"
}
},
"type": "Microsoft.Authorization/policyDefinitions"
}
To my knowledge - no, you cannot be granular. you can only restrict a specific action.
ps. technically this is correct. but the policy usage above is really clever ;)
Yes it should be possible when you assign a policy, so it's not part of the definition but assignment. You can assign policy on the subscription-level scope, and exclude resource groups. You can do that via "notScopes".
Please see Azure Policy docs for how to do this (chapter Excluded scopes)
The scope of the assignment includes all child resource containers and
child resources. If a child resource container or child resource
shouldn't have the definition applied, each can be excluded from
evaluation by setting notScopes. This property is an array to enable
excluding one or more resource containers or resources from
evaluation. notScopes can be added or updated after creation of the
initial assignment.
https://learn.microsoft.com/en-us/azure/governance/policy/concepts/assignment-structure
You can include excluded scopes in the portal when assigning Policy or through PowerShell by including -NotScope parameter.
I am trying to create an Azure policy which I can assign at the subscription level, and control the naming of the resource groups in the subscription.
Policies need to target a resource type or otherwise limit their application, else they apply globally to all resources.
What resource type (or other method) can I use to limit my validation to the resource group name only?
Here is what I am trying:
$definition = New-AzureRmPolicyDefinition -Name resourceGroupNamePatterns
-Description "Restrict resource group names to allowed prefixes only" -Policy '{
"if": {
"allOf": [
{
"not": {
"field": "name",
"like": "Pattern1-*"
}
},
{
"not": {
"field": "name",
"like": "Pattern2-*"
}
},
{
"field": "type",
"equals": "Microsoft.Resources/subscriptions/resourcegroups"
}
]
},
"then": {
"effect": "deny"
}
}'
Not sure if this question is still relevant, but at the time of posting Azure Policy did not support evaluation on resource groups.
The policy definition provided in the question is correct.
Please try updating your powershell version, and updating the policy definition. It will default to mode: all which in turn will enable policy evaluation on resource groups.
Documentation about Policy mode: https://learn.microsoft.com/en-us/azure/azure-policy/policy-definition
Mode
The mode determines which resource types will be evaluated for a policy. The supported modes are:
all: evaluate resource groups and all resource types
indexed: only evaluate resource types that support tags and location
We recommend that you set mode to all. All policy definitions created through the portal use the all mode. If you use PowerShell or Azure CLI, you need to specify the mode parameter and set it to all.
The resource groups are Microsoft.Resources/subscriptions/resourcegroups type. You can kinda infer that from the resource provider operations:
Get-AzureRmProviderOperation 'Microsoft.Resources/*'