You can check out all other blog posts or videos, which can guide you with best practices, lessons learned, or help you with some of the more difficult Azure Management topics at https://www.azurespringclean.com.
You can also keep an eye on Twitter for the hashtag #AzureSpringClean so you won’t miss any of these Azure “spring” cleaning tips.
This year, Karel De Winter and my self will tell you all about how you can manage and govern your Azure Arc resources. My blog post will focus on Azure Arc-enabled Servers, and Karel will tell you all about how you can govern and manage your Azure Arc-enabled Kubernetes. So, let’s start “cleaning”🧹.
Govern and manage your Azure Arc-enabled servers
Like some of you might probably know is that Azure Arc allows you to onboard a wide variety of servers to Azure with Azure Arc-enabled servers. And that it makes it easier to increase security, governance, management, automation and compliance on all your Windows and Linux servers that are deployed outside of Azure.
But, just like with all your other Azure resources it is really important that you apply the same governance principals, processes and mechanisms, so you can maintain control over these non-Azure resources. And this in order to not only reduce complexity and the ability to scale your environment efficiently, but also to reduce or track costs and to minimize operational and reputational risks.
To optimize you governance and management of these resources, it helps that you try to focus on the following key areas:
- Identity and access management
- Resource organization and management
- Automation and control
- Cost management
I will not discuss all these parts in depth and will not cover all features, because this will definitely make this blog post to long. But by reading this blog post you will certainly be able to get started and will know what the most common used governance controls for Azure Arc-enabled servers are. And along the way you will hopefully learn some practical tips which you can use in your own Azure hybrid cloud environment.
Identity and access management
Azure role-based access control (RBAC) is an important part in your Identity and access management strategy. It will help you to keep control on who has access to your Azure resources, what they can do with them, and what areas they have access to.
At the moment there are around 70 plus built-in roles you can use, but you can also configure your own Custom roles. Just always use the least privilege access model. So, just give users the minimum access they need to fur fill their tasks.
When working with Azure Arc-enabled servers there are two built-in roles you can use:
First of all you have the Azure Connected Machine Onboarding role, which you should only assign to administrators who need to be able to onboard Azure Arc-enabled servers. With this role those administrators are only able to read or create new Azure Arc-enabled servers in Azure. They are not able to delete any servers which are already registered or manage any extensions. As a best practice, you should only assigning this role to the Azure Active Directory (Azure AD) service principal* used to onboard machines at scale.
Next to that role you also have another built-in role you can use, namely the Azure Connected Machine Onboarding role, which you should assign only to users wo need to be able to read, modify, re-onboard, and delete a hybrid machine. So, best is to only to assign this role to users who need to deliver support or management on your Azure Arc-enabled servers.
*To connect your hybrid servers to Azure Arc, you can use an Azure Active Directory service principal, which is a special limited management identity that is granted only the minimum permission necessary to connect machines to Azure. You can read more on how to create on use this service principal to onboard machines at scale on this Microsoft Docs page.
Resource organization and management
Like most of you will know it is important to use and develop a well-defined naming and tagging strategy, which can help you to quickly locate and manage your resources. But next to that it is also essential from a security perspective, because in the case of an incident, it can help you to quickly identify an affected system and help you to define what the possible impact of any downtime can mean for you business.
When working with Azure Arc-enabled servers, your server naming is already in place and will hopefully follow your described naming convention. But during the onboarding process of your servers into Azure Arc, you are able to apply the necessary tags. At the moment, you can apply two types of tags to your Azure Arc-enabled servers: physical location tags and custom tags.
I already wrote a blog post focusing on “Using tags with Azure Arc-enabled servers”. So, if you would like to know how applying tags to your hybrid servers and machines can help you to logically organize them, manage your server inventory or even can help you with tracking costs, you can do so over here.
When you are performing management tasks on your Arc-enabled servers, or when you need to create an inventory, it sometimes can also be handy to list all your Azure virtual machines (VMs), and Azure Arc-enabled servers in one view. If you want to learn how easily you can do this in the Azure Portal, you can find out in this blog post.
If you are in the process of creating a new naming convention for your Azure deployments, you can always use the Azure Naming Tool to generate a naming convection within minutes.
Automation and control
Once your hybrid servers are onboarded to Azure, you can also use Update Management in Azure Automation to manage operating system updates for all your Azure Arc-enabled servers running Windows or Linux. You just require an Azure Automation account which is linked to an existing Azure Log Analytics workspace.
As a best practice, it’s best to create an Azure Automation account immediately after you create your Log Analytics workspace(s), and to directly link them together.
Nice to know is that you can use the same Deployment schedules as those you already use for your Azure VMs. In this way it allows you to for example schedule the installation of updates within a specific maintenance window per type of environment (prd, dev, pre), and this independently of where your resource is running (Azure, on-premises or in another cloud).
You should know that there are different ways to onboard and enable Azure VMs or non-Azure machines to Azure Update management, but the best way to do this is by using automatic enablement for all available and future machines. You can read about how to set this up in this blog post.
Next to Update Management you can also use other Azure Automation features, like Change Tracking and Inventory.
By enabling Change Tracking on your Azure Arc-enabled servers, your are able to track changes in services, daemons, software, registry, and files which run on your non-Azure Linux and Windows machines. This for example can help you to diagnose unwanted changes and to raise an alert whenever this happens.
Inventory on the other hand allows you to query in-guest resources and give you more visibility into installed applications and other configuration items on your Arc-enabled servers.
Most of you will already use Microsoft Defender for Cloud for servers to protect their Azure VMs, but you can also use it to better protect your hybrid machines. And when you do this it will provide you with the same advanced defenses, security alerts, and advanced threat protection for you hybrid Windows and Linux machines.
Whenever you start using Microsoft Defender for cloud, keep in mind that during the enablement it registers the subscription to the Microsoft Defender for Cloud resource provider named Microsoft.Security. And that this action also triggers the assignment of the Azure Security Benchmark policy initiative (currently ASB v3) on that subscription. As a recommendation I would advise that you review each of the security recommendations in this default initiative to determine whether or not they are appropriate for that specific subscription and it’s resource groups.
When working with Azure Arc-enabled servers it is also important to understand it’s pricing, because like we all know, at the end of the month someone still needs to pay your Azure invoice(s).
So, important to know is what gets charged and what’s not when you start using it. Well this will be any Azure management service which is attached to a server. Good to know is that the pricing model for these services is exactly the same as they are today for any of your Azure VMs. For example, Azure Monitor* for Arc-enabled servers will be priced the same way as it would be for your Azure VMs.
*You should also think about which logs and events you want to collect for your Azure Arc-enabled servers in your Log Analytics workspace. Because to more data you collect to more it will cost you. You can always use the Azure pricing calculator to estimate your Azure Arc-enabled servers monitoring costs, for your Azure Log Analytics ingestion, alerts, and notifications.
The only exceptions are Azure Policy Guest Configuration, Azure Key Vault, Azure Private Link, and Azure Automation services such as Update Management, Desired State Configuration, Change tracking and inventory. Which are free for Azure VMs but at the time of writing charged at €5.3986 per server per month for Azure Arc enabled VMs in the West Europe region. It doesn’t matter if you just use one of these or all of them together, the price will remain the same. So, around 5 euro’s per server per month.
If you want to have a full and more detailed overview of Azure Arc pricing you can consult it over here. Just keep in mind to select your correct region and currency when you apply the filters to customize your pricing.
Before ending this blog post, I just wanted to say that we are really happy to be be part of this online event and we hope hope you learn something new from both our blog posts.
Happy reading 📖 and cleaning 🧹!