When you started building your Cloud infrastructure, you checked every pull request to make sure everything is up to code and respected best practices. Sometime along the way, you started getting new types of resources and the size of every project doubled, and consequently the number of pull requests you could check diminished.  DevOps culture wants us to deliver often, but without quality checks, it can have a real impact on your Infrastructure. Here is an article with examples of misconfiguration on Kubernetes cluster.  With that, the quality of your Cloud infrastructure could no longer be guaranteed. Fortunately, there are tools to help you ensure at all times the configuration of your resource in your Azure infrastructure. Introducing Azure policy!

What is Azure policy?

Azure policy is an Azure cloud tool to help organizations assess compliance of standards at scale.

Policy defines rules to be checked at creation or to monitor after creation. They can block the creation of the resource, or warn you when one of your rules has been violated.

These policies are defined on scopes, they can consist of:

• Subscription
• Management

If you want more detail on how to organize your resource on Azure.

At its core Azure policy offers a lot of default policies, to help you get started. They define rules, like per example:

This policy only allows resources defined in the scope to be created in France central or West Europe.

You follow these compliances with a dashboard that aggregates data from your Azure infrastructure.

Capabilities

Azure policies are used to ensure standards for a multitude of reasons: resource consistency, regulatory compliance, security, cost, and management.

You can activate rules to make sure you are compliant with official rules for certification like ISO27001, PCI DSS or HIPAA.

Custom policy

Like I said before, Azure policy offers a lot of default policies. These policies have limits because they are not tailored to your infrastructure. In fact, every company has specific needs, so not every rule can be copied and pasted between companies.

That is why Azure policy offers you to create your own sets of rules and assign them to the scope you want.

Policies are defined in JSON:

"resources": [{
    "comments": "Generalized from resource: '/subscriptions/{subscriptionId}/resourceGroups/myResourceGroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount'.",
    "type": "Microsoft.Storage/storageAccounts",
    "sku": {
        "name": "Standard_LRS",
        "tier": "Standard"
    },
    "kind": "Storage",
    "name": "[parameters('storageAccounts_mystorageaccount_name')]",
    "apiVersion": "2018-07-01",
    "location": "westus",
    "tags": {
        "ms-resource-usage": "azure-cloud-shell"
    },
    "scale": null,
    "properties": {
        "networkAcls": {
            "bypass": "AzureServices",
            "virtualNetworkRules": [],
            "ipRules": [],
            "defaultAction": "Allow"
        },
        "supportsHttpsTrafficOnly": false,
        "encryption": {
            "services": {
                "file": {
                    "enabled": true
                },
                "blob": {
                    "enabled": true
                }
            },
            "keySource": "Microsoft.Storage"
        }
    },
    "dependsOn": []
}]

It allows a very versatile configuration of your rules. You can per example define rules for:

• Default standard tags
• Allow only multi-zone resources
• Allow only GRS replication or above in production
• Allow only LRS in dev environment

Exemption

Not everything can always go by the books.

• If it’s a debug and your on-call engineers need to deploy a resource in a new region.
• If you want to try a new configuration, that is not permitted.
• If a resource needs time to be deleted because it requires a migration

You will need to temporarily break some rules to finish your work. You can create exemption:

{
    "id": "/subscriptions/{subId}/resourceGroups/ExemptRG/providers/Microsoft.Authorization/policyExemptions/resourceIsNotApplicable",
    "name": "resourceIsNotApplicable",
    "type": "Microsoft.Authorization/policyExemptions",
    "properties": {
        "displayName": "This resource is scheduled for deletion",
        "description": "This resources is planned to be deleted by end of quarter and has been granted a waiver to the policy.",
        "metadata": {
            "requestedBy": "Storage team",
            "approvedBy": "IA",
            "approvedOn": "2020-07-26T08:02:32.0000000Z",
            "ticketRef": "4baf214c-8d54-4646-be3f-eb6ec7b9bc4f"
        },
        "policyAssignmentId": "/subscriptions/{mySubscriptionID}/providers/Microsoft.Authorization/policyAssignments/resourceShouldBeCompliantInit",
        "policyDefinitionReferenceIds": [
            "requiredTags",
            "allowedLocations"
        ],
        "exemptionCategory": "waiver",
        "expiresOn": "2020-12-31T23:59:00.0000000Z"
    }
}

This policy waives the policy ‘requiredTags’ and ‘AllowLocations’ for a storage account for a given time to allow teams to work on the migration of this resource to a new location.

You can find all the resources in the Azure policy tabs of the Azure portal

With all these rules and customization, you can easily define the standards of your Azure infrastructure. Start by looking at what Azure policy defines as standards, and you can then create your own policy to increase your security posture.