Azure Policy: Your Enterprise Azure Resource Guardrails!

Introduction:

There are numerous conversations surrounding Azure Policy. This post will provide information to accompany those conversations. This post will be a living and constantly modified document throughout the product development.

Post Purpose:

The purpose of this document is to explain the following:

  1. What is Azure Policy

Intended Audience:

The intended audience will be Azure Cloud Engineers and Azure Cloud Security Engineers as well as any other related parties who need information and overview of Azure Policies as part of the overall security governance process of your organization.

What is Azure Policy

Azure Policy is a service in Azure that you use to create, assign, and manage policies. These policies enforce different rules and effects over your resources, so those resources stay compliant with your corporate standards and service level agreements. Azure Policy meets this need by evaluating your resources for non-compliance with assigned policies. For example, you can have a policy to allow only a certain inbound and outbound rule within a Network Security Group (NSG). Once this policy is implemented, new and existing resources are evaluated for compliance. With the right type of policy, existing resources can be brought into compliance. Later in this documentation, we'll go over more details on how to create and implement policies with Azure Policy as well as different Effect Types.

  • Effect Types - Azure Policy

This section will contain information on the different Effect Types that are associated with Azure Policy. Effect Types are exactly what is sounds like, a determined effect that will occur on a resource based on conditions of the Azure Policy. For example, you could have an Effect Type of ‘Deny’ that will disallow resources from being created based on conditions present in your Policy Definition (e.g. Resources are deployed in the improper Azure Region).

The subsections below will dive into a bit more detail, with practical use cases for each Effect Type.

  • Deny

Whenever a Policy has an Effect Type of ‘Deny’ any new resource that gets created that goes against the conditions defined within the Policy Definition, that deployment of such resources will be denied from creation.

Deny evaluation

When creating or updating a matched resource, deny prevents the request before being sent to the Resource Provider. The request is returned as a 403 (Forbidden). In the portal, the Forbidden can be viewed as a status on the deployment that was prevented by the policy assignment.

During evaluation of existing resources, resources that match a deny policy definition are marked as non-compliant.

Example: If a AZURE Cloud Engineer spins up a new Virtual Network, and attaches an NSG that have default Internet outbound rules, the Engineer will be denied resource creation due to Policy disallowing such actions.

  • Append

Append is used to add additional fields to the requested resource during creation or update.

Append evaluation

Append evaluates before the request gets processed by a Resource Provider during the creation or updating of a resource. Append adds fields to the resource when the if condition of the policy rule is met. If the append effect would override a value in the original request with a different value, then it acts as a deny effect and rejects the request. To append a new value to an existing array, use the [*] version of the alias.

When a policy definition using the append effect is run as part of an evaluation cycle, it doesn't make changes to resources that already exist. Instead, it marks any resource that meets the if condition as non-compliant.

Example: If an AZURE Cloud Engineer forgets to add a required Tag to a resource, upon creation and evaluation, that Tag will be added to the resource automatically.

  • Audit

Audit is used to create a warning event in the activity log when evaluating a non-compliant resource, but it doesn't stop the request.

Audit evaluation

Audit is the last effect checked by Azure Policy during the creation or update of a resource. Azure Policy then sends the resource to the Resource Provider. Audit works the same for a resource request and an evaluation cycle. Azure Policy adds a Microsoft.Authorization/policies/audit/action operation to the activity log and marks the resource as non-compliant.

Example:

If AZURE Cloud Engineer wanted to see how many resources are non-compliant against a condition within a Policy Definition, the engineer can use ‘Audit’ to get a gauge of compliance, evaluate, review, and plan for compliance remediation.

  • AuditIfNotExist

AuditIfNotExist enables auditing on resources that match the if condition, but doesn't have the components specified in the details of the then condition.

AuditIfNotExist evaluation

AuditIfNotExist runs after a Resource Provider has handled a create or update resource request and has returned a success status code. The audit occurs if there are no related resources or if the resources defined by ExistenceCondition don't evaluate to true. Azure Policy adds a Microsoft.Authorization/policies/audit/action operation to the activity log the same way as the audit effect. When triggered, the resource that satisfied the if condition is the resource that is marked as non-compliant.

AuditIfNotExists properties

The details property of the AuditIfNotExists effects has all the subproperties that define the related resources to match.

  • Type [required]
    • Specifies the type of the related resource to match.
    • If details.type is a resource type underneath the if condition resource, the policy queries for resources of this type within the scope of the evaluated resource. Otherwise, policy queries within the same resource group as the evaluated resource.
  • Name (optional)
    • Specifies the exact name of the resource to match and causes the policy to fetch one specific resource instead of all resources of the specified type.
    • When the condition values for if.field.type and then.details.type match, then Name becomes required and must be [field('name')]. However, an audit effect should be considered instead.
  • ResourceGroupName (optional)
    • Allows the matching of the related resource to come from a different resource group.
    • Doesn't apply if type is a resource that would be underneath the if condition resource.
    • Default is the if condition resource's resource group.
  • ExistenceScope (optional)
    • Allowed values are Subscription and ResourceGroup.
    • Sets the scope of where to fetch the related resource to match from.
    • Doesn't apply if type is a resource that would be underneath the if condition resource.
    • For ResourceGroup, would limit to the if condition resource's resource group or the resource group specified in ResourceGroupName.
    • For Subscription, queries the entire subscription for the related resource.
    • Default is ResourceGroup.
  • ExistenceCondition (optional)
    • If not specified, any related resource of type satisfies the effect and doesn't trigger the audit.
    • Uses the same language as the policy rule for the if condition, but is evaluated against each related resource individually.
    • If any matching related resource evaluates to true, the effect is satisfied and doesn't trigger the audit.
    • Can use [field()] to check equivalence with values in the if condition.
    • For example, could be used to validate that the parent resource (in the if condition) is in the same resource location as the matching related resource.

AuditIfNotExists Example:

Azure Policy evaluates Customer’s Azure Virtual Machines to determine if the Antimalware extension exists then audits when missing.

  • DeployIfNotExist

Similar to AuditIfNotExists, DeployIfNotExists executes a template deployment when the condition is met. This will trigger essentially ‘remediation’ upon the Azure resource to bring it into compliance based upon the Policy conditions.

DeployIfNotExists evaluation

DeployIfNotExists runs after a Resource Provider has handled a create or update resource request and has returned a success status code. A template deployment occurs if there are no related resources or if the resources defined by ExistenceCondition don't evaluate to true.

During an evaluation cycle, policy definitions with a DeployIfNotExists effect that match resources are marked as non-compliant, but no action is taken on that resource.

DeployIfNotExists properties

The details property of the DeployIfNotExists effects has all the subproperties that define the related resources to match and the template deployment to execute.

  • Type [required]
    • Specifies the type of the related resource to match.
    • Starts by trying to fetch a resource underneath the if condition resource, then queries within the same resource group as the if condition resource.
  • Name (optional)
    • Specifies the exact name of the resource to match and causes the policy to fetch one specific resource instead of all resources of the specified type.
    • When the condition values for if.field.type and then.details.type match, then Name becomes required and must be [field('name')].
  • ResourceGroupName (optional)
    • Allows the matching of the related resource to come from a different resource group.
    • Doesn't apply if type is a resource that would be underneath the if condition resource.
    • Default is the if condition resource's resource group.
    • If a template deployment is executed, it's deployed in the resource group of this value.
  • ExistenceScope (optional)
    • Allowed values are Subscription and ResourceGroup.
    • Sets the scope of where to fetch the related resource to match from.
    • Doesn't apply if type is a resource that would be underneath the if condition resource.
    • For ResourceGroup, would limit to the if condition resource's resource group or the resource group specified in ResourceGroupName.
    • For Subscription, queries the entire subscription for the related resource.
    • Default is ResourceGroup.
  • ExistenceCondition (optional)
    • If not specified, any related resource of type satisfies the effect and doesn't trigger the deployment.
    • Uses the same language as the policy rule for the if condition, but is evaluated against each related resource individually.
    • If any matching related resource evaluates to true, the effect is satisfied and doesn't trigger the deployment.
    • Can use [field()] to check equivalence with values in the if condition.
    • For example, could be used to validate that the parent resource (in the if condition) is in the same resource location as the matching related resource.
  • roleDefinitionIds [required]
    • This property must include an array of strings that match role-based access control role ID accessible by the subscription. You can consider this part of the ‘remediation’ part of Azure Policy.
  • DeploymentScope (optional)
    • Allowed values are Subscription and ResourceGroup.
    • Sets the type of deployment to be triggered. Subscriptionindicates a deployment at the subscription level, ResourceGroupindicates a deployment to a resource group.
    • A location property must be specified in the Deploymentwhen using subscription level deployments.
    • Default is ResourceGroup.
  • Deployment [required]
    • This property should include the full template deployment as it would be passed to the Microsoft.Resources/deploymentsPUT API.

DeployIfNotExists example

Azure Policy evaluates SQL Server databases within Customer’s Azure subscriptions to determine if transparentDataEncryption (TDE) is enabled. If not, then a deployment to enable is executed.

  • Order of Evaluation

Requests to create or update a resource through Azure Resource Manager are evaluated by Azure Policy first. Azure Policy creates a list of all assignments that apply to the resource and then evaluates the resource against each definition. Azure Policy processes several of the effects before handing the request to the appropriate Resource Provider. Doing so prevents unnecessary processing by a Resource Provider when a resource doesn't meet the designed governance controls of Azure Policy.

 

Disabled is checked first to determine if the policy rule should be evaluated.

Append is then evaluated. Since append could alter the request, a change made by append may prevent an audit or deny effect from triggering.

Deny is then evaluated. By evaluating deny before audit, double logging of an undesired resource is prevented.

Audit is then evaluated before the request going to the Resource Provider.

After the Resource Provider returns a success code, AuditIfNotExists and DeployIfNotExists evaluate to determine if additional compliance logging or action is required.

 

  • Mode Types – Azure Policy

Mode Types are available for Azure Policy. There are two modes, ‘All’ and ‘Indexed’. We recommend you set the mode to ‘All’ in most cases. You should use ‘Indexed’ when creating Policies that enforce Tags or Resource Location.

  • Indexed

Indexed Mode only evaluates resource types that support Tags and Location. Indexed should be used when creating policies that enforce tags or locations. While not required, it prevents resources that don't support tags and locations from showing up as non-compliant in the compliance results. The exception is resource groups. Policies that enforce location or tags on a resource group should set mode to all.

  • All

All Mode evaluates resource groups and all resource types. All policy definitions created through the portal use the all mode. If you use PowerShell or Azure CLI, you can specify the mode parameter manually. If the policy definition doesn't include a mode value, it defaults to all in Azure PowerShell and to null in Azure CLI.