Trigger Azure Policy on demand

In my last blog I explained about Azure Policy, concept and creating it. Next action after creating or changing an policy is to see whether is it working or not. Unlike most other azure features where change are propagated immediately, azure policy trigger does not happen immediately after SAVE.

Policy Trigger

Interval of Evaluation of policies depend upon type of policy change (new or update), effect and resource deployment.
Following is the evaluation interval

Compliance evaluation frequency
On change (New/Update policy Assignment) ~ 15 min after resource change
On periodic cadence ~ Every 24 hours
On demand ~ 3 min

Deny Policy enforcement
On creating resource ~ immediately. Policy is evaluated before deploy request is sent to resource provider
On updating resource ~ immediately. Policy is evaluated before deploy request is sent to resource provider

DeployIfNotExists Policy enforcement
On creating resource ~ immediately. Policy is enforced after deployment is succeed for resource creation.
On updating resource ~ immediately. Policy is enforced after deployment is succeed for resource update request.

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.

On-demand

As mentioned above, one way to trigger a policy is via REST API. With a call to REST API, Evaluation scan can be triggered for subscription or a resource group.
This scan is an asynchronous process. As such, the REST endpoint to start the scan doesn’t wait until the scan is complete to respond. Instead, it provides a URI to query the status of the requested evaluation.

Following are the URI to trigger policy

Subscription

POST https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.PolicyInsights/policyStates/latest/triggerEvaluation?api-version=2018-07-01-preview

Resource Group

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{YourRG}/providers/Microsoft.PolicyInsights/policyStates/latest/triggerEvaluation?api-version=2018-07-01-preview

Trigger Policy using script.

Since Triggering Policy REST API using a rest client needs token in Authorization and that two a new one quite often, I wrote a powershell script which call REST API and triggers policy

param(
    
    [Parameter(Mandatory= $false)]
    [string]$SubscriptionId,
    
    [string]$ResourceGroup
)


function Get-AccessToken {
    $context = Get-AzContext
    if ($null -eq $account.Account) {
        Write-Output("Account Context not found, please login")
        Connect-AzAccount
        $context = Get-AzContext
    }
    
    $cache = $context.TokenCache
    $cacheItemToUse = $cache.ReadItems()

    $tokenToUse = ($cacheItemToUse | where { $_.ExpiresOn -gt (Get-Date) })[0].accessToken

    return $tokenToUse
}

function Trigger-ResourceGroupPolicy {
    param (
        [string]$ResourceGroup,
        [string]$SubscriptionId,
        $Headers
    )

    $url = "https://management.azure.com/subscriptions/$SubscriptionId/resourceGroups/$ResourceGroup/providers/Microsoft.PolicyInsights/policyStates/latest/triggerEvaluation?api-version=2018-07-01-preview"
    
    $response= Invoke-WebRequest -Uri $url -Method Post -Headers $Headers

    return $response 
}

function Trigger-SubscriptionPolicy {
    param (
        [string]$SubscriptionId,
        $Headers
    )

    $context = Get-AzContext
    $cache = $context.TokenCache
    $cacheItemToUse = $cache.ReadItems()

    $tokenToUse = ($cacheItemToUse | where { $_.ExpiresOn -gt (Get-Date) })[0].accessToken

    $url = "https://management.azure.com/subscriptions/$SubscriptionId/providers/Microsoft.PolicyInsights/policyStates/latest/triggerEvaluation?api-version=2018-07-01-preview"

    $response= Invoke-WebRequest -Uri $url -Method Post -Headers $Headers
    return $response 
}

function Get-Status {
    [string]$StatusUrl,
        $Headers
    $res= Invoke-WebRequest -Uri $StatusUrl -Method Get -Headers $Headers
    return $res
}

$token = Get-AccessToken
Set-AzContext -SubscriptionId $SubscriptionId

$headers = @{
    Authorization = "Bearer $token"
}
if(($null -eq $ResourceGroup) -or ($ResourceGroup -eq '')){
    $res = Trigger-SubscriptionPolicy -SubscriptionId $SubscriptionId -Headers $headers
}
else{
    $res = Trigger-ResourceGroupPolicy -ResourceGroup $ResourceGroup -SubscriptionId $SubscriptionId -Headers $headers
}

$statusUrl = $res.Headers.Location
Write-Output "Token is: $($token)"

Write-Output "Status url is: $($res.Headers.Location)"

Get-Status -StatusUrl $statusUrl -Headers $headers

#Write-Output "Run this command: Get-Status -StatusUrl $statusUrl -Headers $headers"
#Invoke-WebRequest -Uri $statusUrl -Method Get -Headers $headers

How compliance works

In an assignment, a resource is Non-compliant if it doesn’t follow policy or initiative rules.
For Audit and Deny :It requires IF statement (in policy rule) to be TRUE then effect takes place. For Audit resource is marked as non-complaint while, and for deny, new deployment (for new or update resource) is denied while existing resource is marked as non-complaint.
For Append, DeployIfNotExists and AuditIfNotExists: It requires IF statement to be TRUE and existence condition to be FALSE to mark resource as non-complaint