In our recent webinar “Controlling Your Azure Environment: Governance for the Modern Enterprise” we touched on the five disciplines of cloud governance from Microsoft’s Cloud Adoption Framework. This blog post is the second in the “The Five Disciplines of Cloud Governance” five-part series expanding on those concepts. If you missed the first post in the series around Deployment Acceleration, check it out here.
In this post we are going to dig a little deeper into the discipline of “Resource Consistency” and will explore the paradoxical relationship of policies and tags.
In the Five Disciplines of Cloud Governance Microsoft explains that: “Cloud operations depends on consistency in resource configuration. Through governance tooling, resources can consistently be configured to manage risks related to on-boarding, drift, discoverability, and recovery.”
Why is it important?
By configuring, deploying and managing Azure resources in a consistent manner you limit your cloud deployment’s exposure to risk. When resources are deployed in a predictable manner, they are discoverable by IT operations preventing shadow IT, as well as sprawl.
Without such controls in place the agility of the cloud becomes a liability as resources come in and out of existence without the operations team involvement and they may go unsupported which results in finger-pointing when something goes wrong or worse yet they create a security hole which exposes the whole organization to bad actors.
The Policy and the Tag
In considering which of the several tools available to address resource consistency in Azure to discuss I decided to dig deeper into the examples provided in the recent Controlling Your Azure Environment: Governance for the Modern Enterprise.
In the webinar I touched on the following:
Azure tags allow you to attributed key/value pairs to resources as an organizational tool.
- Tags work in conjunction with policy where they can refine the scope of a policy. Likewise, policies can be used to enforce the use of tags.
Resource Tags
Tagging resources provides a way to describe what a resource is for, who is responsible for it, where it fits in a larger solution and other useful information about the resource. Tags provide a handle against which you can filter resources in queries used for monitoring as well as billing and to target resources through policy.
Because tags are an open name/value format they offer great flexibility however, this flexibility does not bode well for maintaining consistency. When configuring tags from the portal you will see listed all of the names and associated values which have been applied in a subscription and should you add your own unique name/value pair it too will be listed for future consumption. There is nothing to stop someone from adding “CreatedBy” when “Created by” already exists in the list. However, there are two mechanisms which can better shape the use of tags in Azure.
The first mechanism for mitigating eventual tags chaos is to outline of use of tags including a working taxonomy in your cloud governance documentation. Then to affect the management of that taxonomy and employ the terms defined therein you would use the next item in our tool chain, policies.
Policy
Azure policy is one of the most powerful governance tools because it is the embodiment of governance itself. When you a define a policy in real world you are stating how something should be done and expecting a person to abide by it. In Azure, a policy is a technical configuration which controls resources and their existence by allowing or preventing parameters.
Tag Enforcement Policy
Implementing policies in Azure is a two-part process.
- Definition- First, the desired behavior must be written in javascript object notation (JSON) so that the Azure resource manager can understand it. This singular artifact is the policy, a collection of policies is called an initiative.
- Assignment- Second, the policy or initiative must be assigned to a scope to be used. The scope is defined at the subscription and resource group levels with the ability to further refine the scope through exclusion at the individual resource level.
Definitions
To create our policy, we must navigate to the “Policy” resource in the Azure Portal by searching for “policy” and selecting the associated service. From the Policy overview section, we are going to select “Definitions” under the Authoring section.
Here we see listed all of the Built-in policies available out of the box. By using the Search box located to the far-right of the toolbar we can filter the list to just those policies for tags.
To achieve our goal of defining tags through policy, we’re going to work with the “Enforce tag and its value” policy.
After clicking on the definition name, click “Duplication definition” to create a copy of this definition that we can modify. (Note: these built in definitions should be viewed as templates and not modified directly)
BASICS
In the first section of the form we will need to assign the following:
- Definition location: the subscription to which the policy applies
- Name: make sure this clearly and concisely explains the intent of the policy
- Description: while not mandatory it is useful to provide details on the policies objective
- Category: while not mandatory this will help make your policy discoverable for use by others
POLICY RULE
The policy rule section is the JSON code which the Azure resource manager will interpret to enforce the application of tags.
The code block consists of the following:
PolicyRule: this is where the condition of the policy is defined dictating the IF/Then
- If– here the policy is looking for the presence in tag defined in Parameters in resources of type [virtual machines]
- Then– here the “effect” of the condition not being met is to add or “append” the tag to the resources
(Note: Here we are using the resource type to identify what resources this should be applied to, instead we could identify the resource by tag thus meeting the other scenario outlined in the webinar where policy is applied to resources based on tag.)
In the example below I have modified the default code to reflect the logic outlined above.
Parameters: In this section the criteria to be applied by the policy is defined. In our use case it is the tag and value.
To constrain the “tagname” and “tagvalue” to specific terms, I have added the “allowedValues” property to limit the term(s) used.
The only modifications that need to be made to the code are to the defaultValue, allowedValues, displayname and description for both the tagName and tagValue.
Assignment
Once the definition of a policy has been articulated we can assign it. From the Definitions section we need to navigate to the Assignments area by selecting “Assignments” under the Authoring section.
Because we are only concerned with an individual policy and not a collection we are going to click “Assign policy” from the top navigation of the Assignments page.
SCOPE
In this first section we need to define the scope of the assignment. By default, the scope is an entire subscription, clicking on the ellipsis in the scope field gives the opportunity to refine the scope by resource group(s).
Scope can be further refined by selecting resources for exclusion from the policy assignment by clicking the ellipsis in the Exclusions field.
BASICS
With the scope defined all that remains is to select the Policy definition you want associated to this assignment and give the assignment a name and description.
Conclusion
To further our understanding of resource consistency in Azure we have created a policy which enforces the use of a specific tag and value for a specific type of resource. In so doing we have seen how that tags can also be used to determine what resources would have a policy applied to them thus illustrating the recursive relationship between the two ideas.
The next in our series on Cloud Adoption will be on Cost Management. If you’re interested in implementing Azure services, reach out to us here.