Generally, governance is an act or process of governing or overseeing the control and direction of something (such as a country or an organization). With ever-growing cloud consumption, cloud governance is essential to oversee the control and usage of cloud environments.
For Microsoft Azure, several governance constructs can be utilized, including Azure Management Groups, Subscriptions, Azure Policies, Azure role-based access control, and Azure Cost Management.
Azure Resource Manager (ARM)
Azure Resource Manager or ARM provides a declarative template-based repeatable deployment model. It offers a familiar JSON-based deployment model to provision the instances of Azure resource types like virtual machines, SQL databases, or app services.
Under ARM, all the Azure resources can be grouped, deployed, and managed together to share the same life cycle as a resource group. ARM uses a declarative model, and JSON-based ARM templates can be reused any number of times to deploy the same set of resources. Two ARM templates can also be linked or nested with each other to make a composite ARM template.
One advantage of using ARM is that you can define the dependencies between the resources in ARM – meaning if resource A depends upon resource B to exist before it can be created, we can manage that dependency in ARM.
There are different ways to manage Azure resources through ARM, including Azure Portal, Azure PowerShell, Azure CLI, Bicep, and REST APIs.
Here is a glimpse of how Azure Resource Manager works:
Image source – https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/media/overview/consistent-management-layer.png
Scopes/resource hierarchy
Different Azure resources are grouped into a logical construct called a resource group. The resource group sits under an Azure subscription, a logical container for all your Azure resources. Each subscription acts as a billing boundary and is linked to an Azure offer that defines the pricing and the other benefits. An Azure subscription is tied to a single Azure AD tenant, which is used for authentication and authorization purposes. If there are multiple subscriptions, they can be grouped under management groups that offer a higher scope than the subscriptions.
Here is a depiction of how Azure Resource Hierarchy appears –
The purpose of this resource hierarchy is to provide a clean way to manage and govern your Azure environment. You can apply different compliance policies at any scope, and the underlying scopes inherit the policies. For example – if a policy is applied at a subscription level, it is inherited by all the resource groups and the resources within those resource groups. If a policy is applied at a management group level, it is inherited by all the subscriptions under that management group and the corresponding resource groups and resources.
By default, a root management group is created automatically, under which all the subscriptions are placed by default. New management groups can be placed under the root management group, or there can be nested management groups too. Each Azure resource can be part of one resource group, and each resource group can be part of only one subscription. Each subscription can be placed under one management group only. Once a management group is created, you can move subscriptions under it or create a child management group inside it.
Azure Billing Accounts
Though the Azure subscription acts as a billing boundary for your Azure resources, all the subscriptions roll under a single billing account. As depicted in the following figure, a centralized billing account includes one or more billing profiles. You can configure payment methods for each billing profile, and an invoice is generated for each. Inside the invoice are separate sections for each Azure subscription, highlighting the cost of all the resources under that subscription.
Image Source – https://learn.microsoft.com/en-us/azure/cost-management-billing/manage/media/view-all-accounts/mca-hierarchy.png
The billing account can be of one of the following three types:
- Microsoft Online Services Program: An individual billing account for a Microsoft Online Services Program is created when you sign up for Azure through the Azure website.
- Enterprise agreement: A billing account for an enterprise agreement is created when your organization signs an enterprise agreement (EA) to use Azure.
- Microsoft customer agreement: A billing account for a Microsoft customer agreement is created when your organization works with a Microsoft representative to sign a Microsoft customer agreement.
Azure Policies
Azure Policies are a set of rules that you can define to enforce organizational standards and assess compliance with those standards. Azure Policies continuously scan the Azure resources and provide compliance reports in a dashboard. Azure Policies also offers remediation steps to fix the non-compliant resources in your Azure environment. A few examples of an Azure Policy could be:
- allowed resource types – which allow provisioning of specific resource types.
- allowed locations – which allow users to provision resources only in specific Azure locations.
- allowed virtual machine SKUs – which controls the virtual machine SKUs your users can choose for their virtual machines, etc.
You can either create custom policies for your specific use case or choose from built-in policies offered by Azure. There are a bunch of built-in policies that Azure comes with, including the examples mentioned above. Here is an up-to-date and complete list of the built-in policies
When you are assigning policies to your Azure resources, you have two different options:
- You can create individual policies and assign them to different scopes, like management groups or subscriptions.
- Alternatively, if you have several policies that need to be applied at the same scope, you can create an initiative, a collection of individual policies. All the policies within an initiative behave as a group and are applied together on the assigned scope.
When you create an Azure policy, you must configure the following settings:
Policy definition – defines the condition on which the policy will report – like the allowed SKUs for the virtual machines or the allowed locations. A policy definition is a JSON-based template.
Inside the policy definition, you define the different properties for the policy, like name, type, if it is custom or built-in, etc.
Next, you define the parameters whose values you can specify during the assignment. Parameters allow you to use the same policy definition across different scopes. Parameters promote reusability by allowing you to use the same definition for multiple assignment scopes.
The next section defines the policy rule that defines the evaluated condition. Once the policy is evaluated, an effect defines the outcome. Each policy definition must have an effect. Seven different effects are currently supported for Azure policies:
- Append is used to add additional fields to the requested resource during creation or an update.
- Audit creates a warning event in the activity log when evaluating a non-compliant resource, but it doesn’t stop the request.
- AuditIfNotExists audits when no related resources exist based on an existence condition that you define in the policy definition.
- Deny is used to prevent a resource request that doesn’t match defined standards through a policy definition and fails the request.
- Like AuditIfNotExists, DeployNotAuditExists deploys a resource when the existence condition is evaluated as false.
- Disabled is used for disabling a single assignment instead of all the assignments.
Here is an example of a policy definition for allowed virtual machine SKUs:
Policy assignment is where we assign the policy to a scope. I will touch upon it shortly, but at this moment, as I have mentioned before, the policy is inherited in the scope. Depending on the scope of the policy assignment, all the resource groups and resources inherit the policy. For example – if a policy is applied at the root management group, it is inherited by all the subscriptions, resource groups, and resources, as depicted below:
Policy parameters are the values in your policy that you can parameterize to reduce duplicate policies.
Azure role-based access control
Under Azure Resource Manager, Azure offers a role-based access control mechanism that helps you manage who has access to your Azure resources and what they can do with those resources. There are some built-in roles like Owner, Reader, and Contributor – and you can have your own custom roles defined.
Image Source – https://learn.microsoft.com/en-us/azure/role-based-access-control/media/rbac-and-directory-admin-roles/rbac-admin-roles.png
RBAC is applied to any security principal, including a user, a group, and a service principal. Azure RBAC roles differ from Azure AD roles as these roles apply to Azure resources. Under Azure AD, we have roles like Global Administrator, Application Administrator, etc., which have a scope at the tenant level. On the other hand, RBAC roles apply to the Azure Resource Manager scopes, like subscriptions, resource groups, and resources.
* Before Azure Resource Manager was introduced, a different deployment model called Azure Service Management was used. It is now called the classic model. Under the classic model, roles like service administrators and co-administrators were created to manage Azure services. Along with the RBAC roles, for each of your subscriptions, you will notice that there is a tab for classic administrators. Classic administrators will be discontinued in the future.
Similar to policies, the roles are inherited in the assigned scope. In this example, if a user is assigned a role in the root management group, the underlying scopes inherit the permissions.
Azure Blueprints
Azure Blueprints allow you to define a repeatable set of Azure resources that implement and adhere to an organization’s standards, patterns, and requirements. Azure Blueprints enable development teams to rapidly provision new environments with the trust that they’re building within organizational compliance with built-in components, such as networking, to speed up development and delivery. Blueprints offer a declarative way to orchestrate the deployment of:
- Role assignments (RBAC)
- Policy assignments (Azure Policies)
- ARM templates
- Resource groups
The lifecycle of an Azure Blueprint includes two steps –
- Create and Edit Blueprint
- Publish Blueprint
* Azure Blueprint has been a preview feature for a few years, and it might be discontinued in the future.
Azure Resource Graph
Azure Resource Graph is a great construct for governance. It offers a resource exploration platform where you can query your resources and filter, sort, and group them based on their properties. It uses a query language based on the Kusto Query language.
Azure Cost Management
Azure Cost Management is a one-stop dashboard within the Azure portal that gives you a clear snapshot of your current and forecasted costs. In the cost management dashboard, you can easily see the current actual cost, forecasted cost, cost by each resource, cost by location, and so on.
Tags
In Azure, you can organize your Azure resources into a taxonomy by using tags. For example, you can tag all your resources belonging to your HR application with a tag indicating the resources belong to HR. Tags can be applied to subscriptions or resource groups, or resources. Tags are case-insensitive.
Some examples of commonly used tags include “cost center,” “environment,” “owner,” “project,” and “application.” Microsoft publishes a tagging decision guide which can be helpful when planning a tagging scheme for the Azure resources in your environment.
Resource locks
Azure Resource locks prevent accidental deletion or modification of your resources. There are two lock levels that you can apply on your resources:
- CanNotDelete – Authorized users can read and modify but cannot delete the resource.
- ReadOnly – Authorized users can read a resource but cannot delete or update it.
Only an Owner or User Access Administrator can create or delete resource locks.
Azure Advisor
Azure Advisor is a free service offered by Microsoft that provides recommendations for making your Azure environments more cost-effective, secure, highly available, and performant. It continuously analyzes your Azure Resources configuration and usage telemetry to make proactive and actionable recommendations covering the well-architected framework’s five pillars.
Image Source – https://learn.microsoft.com/en-us/azure/advisor/media/advisor-overview/advisor-dashboard.png
Azure Advisor groups different recommendations based on their impact – High, Medium, or Low. Based on the impact, the recommendations can be acted upon. Though Azure Advisor makes recommendations to improve your cloud posture, the execution of actions remains the responsibility of the consumer.
Image Source – https://learn.microsoft.com/en-us/azure/advisor/media/advisor-overview/advisor-ha-category-example.png
Conclusion
Azure offers hundreds of services today, and as your Azure environment evolves, these governance constructs play a critical role in keeping your Azure environment safe, secure, and compliant with different regulations. They are easy to configure, and the benefits they bring are numerous. Using these governance constructs, you get visibility into what’s happening in your Azure environments and how you can be in control.