Hero Image

The cloud rules

Author: Menno van Tol
cloud azure

Ah yes, the cloud. So mysterious yet so simple. How do you get into it and what should be your first steps.

In this blog serries I'll give a rundown on some pitfalls you might not have thought about when getting started in the cloud.

Getting started

Cloud is simple, Right? You just create some Virtual Machines (VMs) in a Resource Group with a few clicks and you are done! While that is true there are a lot more things that you should implement before even deploying your first VM.

Let's go up a few levels from VM, out of the Resource Group and into the Subscription(s).

We will have to think about setting rules. Rules about naming, tagging, what resources we are allowed to create and where. Whether or not we want things to be publicly accessable and if we want to force HTTPS by default and the list goes on.

Policies

On Azure we can use Policies for this. Policies are a great way to put constraints and guides on your users, teams and yourself. Azure Policies are JSON formated and are known as Policy Definitions. A group of policies are called a Policy Initiative or a PolicySet. Once you have created your Definitions or Initiatives you will need to assign them, you do this to any scope Azure supports, such as management groups, subscriptions, resource groups, or individual resources. The assignment applies to all resources within the Resource Manager scope of that assignment. Subscopes can be excluded, if necessary.

In these Policies you can also define an action when the scope is not compliant. It could Deny the resource change, Log the change to the resource, Alter the resource before the change, Alter the resource after the change or Deploy related compliant resources.

As you can see this can become a very powerful tool very fast. This will keep you from making mistakes, saves you time by auditing or automating your deployments and keep everything nice and secure.

Lets take a look at a Policy Definition.

{
    "properties": {
        "displayName": "Allowed locations",
        "description": "This policy enables you to restrict the locations your organization can specify when deploying resources.",
        "mode": "Indexed",
        "metadata": {
            "version": "1.0.0",
            "category": "Locations"
        },
        "parameters": {
            "allowedLocations": {
                "type": "array",
                "metadata": {
                    "description": "The list of locations that can be specified when deploying resources",
                    "strongType": "location",
                    "displayName": "Allowed locations"
                },
                "defaultValue": [ "west-europe" ]
            }
        },
        "policyRule": {
            "if": {
                "not": {
                    "field": "location",
                    "in": "[parameters('allowedLocations')]"
                }
            },
            "then": {
                "effect": "deny"
            }
        }
    }
}

It contains the following elements:

  • display name
  • description
  • mode
  • metadata
  • parameters
  • policy rule
    • logical evaluation
    • effect

The first few elements are self explainatory. The fun begins at parameters. Parameters help simplify your policy management by reducing the number of policy definitions. Think of parameters like the fields on a form. These parameters always stay the same, however their values change based on the individual filling out the form. Parameters work the same way when building policies. By including parameters in a policy definition, you can reuse that policy for different scenarios by using different values.

In the example we created a parameter with the name of allowedLocations in the form of an array, with a default value of west-europe. So if we would apply this definition on the scope of the whole subscription without any additional values we'd only be able to deploy resources in west-europe. This is great for data privacy reasons because your data won't leave Europe or The Netherlands (Amsterdam). Another perk of this is performance. If you are based in Europe and accidentally deploy your infrastructure to westus2 the latency would be enormous.

Policy Rule

The policy rule consists of If and Then blocks. In the If block, you define one or more conditions that specify when the policy is enforced. You can apply logical operators to these conditions to precisely define the scenario for a policy.

In the Then block, you define the effect that happens when the If conditions are fulfilled.

{
    "if": {
        <condition> | <logical operator>
    },
    "then": {
        "effect": "deny | audit | modify | append | auditIfNotExists | deployIfNotExists | disabled"
    }
}

Effect

Azure Policy supports the following types of effect:

  • Append: adds the defined set of fields to the request
  • Audit: generates a warning event in activity log but doesn't fail the request
  • AuditIfNotExists: generates a warning event in activity log if a related resource doesn't exist
  • Deny: generates an event in the activity log and fails the request
  • DeployIfNotExists: deploys a related resource if it doesn't already exist
  • Disabled: doesn't evaluate resources for compliance to the policy rule
  • Modify: adds, updates, or removes the defined tags from a resource or subscription

Possibilies

With the knowledge we now have about Azure Policies we can enforce or audit a few key things when getting started in the cloud.

  • Enforce a resources location
  • Enforce the naming convention of resources
  • Enforce the tagging convention of resources
  • Audit virtual machines without disaster recovery configured
  • Audit VMs that do not use managed disks
  • Enforce HTTPS access to Storage Accounts
  • et cetera...

Now armed with the power of Policies we can make the cloud a safer and more efficient place. But you'll soon notice that when you start growing your policies might not scale or become hard to manage. The same goes for your infrastructure. Deploying a few VMs manually is easy. But managing them and everything around it will become a daunting task. This is where Infrastructure as Code will come into play. We'll use it to manage and deploy our policies, network, VMs, resource groups and all of the different envoirments (Development, Test, Acceptance, Production) with slight variants in them.

But that chapter is for the next blog, see you there!

Back to home