Create a Calculated Exception to a Guardrails Azure Policy

Create a Calculated Exception to a Guardrails Azure Policy

In this guide you'll learn how to make dynamic policy exceptions based on resource tags. These Calculated Policies enable you to implement business logic when designing your governance controls.

Some typical examples of how to use calculated polices are:

This guide will walk you through a simple calculated policy based on resource tags.

This is the seventh guide in the Getting started with Azure series.

Prerequisites

Step 1: Open the Policy Pack

Choose Policies from the top navigation bar. Select the Enforce Secure TLS Version for Azure Storage Accounts Policy Pack from the list on the right.

view-policy-packs

Step 2: Modify the policy setting

The TLS policy is currently Check: TLS 1.2. Use the pencil icon on the right side of the policy setting to edit the policy.

view-policy-pack

Step 3: Enable calculated mode

Select the blue Enable calculated mode link.

enable-calculated-mode

Step 4: Launch calculated policy builder

Select Launch calculated policy builder.

launch-calculated-policy-builder

Step 5: Choose test resource

Calculated policies work across all resources in scope of the policy setting. While building a calc policy it is useful to test the business logic against real resources in your environment. For this guide you will find and select one of the previously-created storage accounts by searching in the Test Resource field.

choose test resource

Step 6: Build query

In the Query Input field we will use Select Snippet to prepopulate our GraphQL query. Choose Get storage account from the dropdown.

snippet-dropdown-open

Step 7: View query result

Guardrails inserts a GraphQL query for storage account tags into the Input pane, and then runs the query against the selected test resource. The result, in the Output pane, shows there are no tags on the storage account.

snippet-active

Step 8: Add the Jinja2 template

Our business logic is created in the Template section, using Nunjucks syntax.

Copy this template code:

{% if $.storageAccount.turbot.tags.environment == "development" %}
'Skip'
{% else %}
'Check: TLS 1.2'
{% endif %}

And paste it into the template pane.

template-active

Guardrails evaluates the template in the context of the chosen Test Resource. The template output, Check: TLS, is the calculated policy value that will govern any storage account’s Azure > Storage > Storage Account > Minumum TLS Version policy if it is tagged with environment:development. Only these tagged storage accounts will be required to have TLS 1.2 enabled. Others will be skipped, whether or not they enable TLS 1.2.

The result confirms that Check: TLS 1.2 is valid for this policy type. Why? Because the test storage account does not have a tag { "environment": "development" }.

Select Update

Step 9: Save the calculated policy to the Policy Pack

Select Update.

update-policy-setting

Step 10: Observe controls for storage account TLS version

Navigate back to the Controls by State report and set the Type filter to Azure > Storage > Storage Account > Minimum TLS Version. Storage accounts with TLS 1.2 enabled will be in the OK state. Find one in the Alarm state to modify, and note its name.

revisit-controls-by-state

Step 11: Tag the storage account

Open the Azure portal in another tab, navigate to the storage account identified in the previous step, and assign the tag environment:development to it.

tag-storage-account

Step 12: Observe the effect

Return to the Controls by State report in the previous browser tab. Observe that Guardrails notices the change, reevaluates the resource, runs the calculated policy, and changes the status from Alarm to Skipped.

tagged-now-skipped

Step 13: Review

In this guide you created your first calculated policy and tested it using the control that governs the TLS version for storage accounts.

Next Steps

In the next guide we’ll see how to subscribe to these status alerts via email, Slack, or MS Teams.

Progress tracker