One of my areas of expertise within Cloud environments has always been what I call the “Ops side of DevOps”. I am referring to the area of the Cloud where someone is no longer developing or deploying, but instead is maintaining and operating the resources that are already within your Cloud environment. This covers topics like Monitoring, Logging, Alerting as well as Automation which encompasses both Scripting as well as Configuration Management. In this blog post, I want to focus on the Scripting and Configuration Management side of this topic by taking a look at the Azure Automation service and the features and functions that it provides in this area.
Automation Accounts
To get things started we need to understand what is actually deployed within Azure and that is called an Azure Automation Account. The Account is a combination of a container for PowerShell or Python scripts along with the features and functions to run those scripts as a Service inside of Azure.
The creation process is very easy, but there is one piece of the creation wizard that is important to understand and that is the possible requirement for a RunAsAccount. The official definition from the Azure documentation is the following:
This account is used to manage Resource Manager deployment model resources. Creates an Azure AD application with a self-signed certificate, creates a service principal account for the application in Azure AD, and assigns the Contributor role for the account in your current subscription.
In layman’s terms, this is an Azure Service Principal user that is created within AAD for the sole purpose of performing tasks inside of Azure in a programmatic fashion. The big problem with the above is the fact that Azure assigns the “Contributor” role to this user which automatically gives them access to all resources within your Azure subscription.
BEST PRACTICE: Do not let Azure create the RunAs Account for you. If you need to perform tasks inside of Azure using Azure Automation, then create your own RunAs Account and only give it the permissions required to perform its tasks through RBAC.
To see a walk-through of the creation process, please see the video below:
Automation Runbooks
Azure Automation as a service has been around for quite some time and new features and functions have been added over time. However, it got started with the idea of Automation Runbooks which provides for the ability to create PowerShell and now Python based scripts that can share Libraries/Modules, Variables, and Secrets and actually be run within the confines of Azure rather than you having to manage your own Application servers to run them. In addition, the scripts can be configured to run on a Timer or be triggered through a custom Webhook/URL.
The last major feature of this service to mention is that the scripts do not have to be specific Azure resources. If you have been a PowerShell guy for some time and you have a lot of scripts that work well against your Linux or Windows VMs that you have On-Prem, then that is possible as well using Azure Automation through a feature called Hybrid Worker Groups. I will not be going into any depth with that feature, but I did want to mention it in case you wanted to learn more about it.
Not only does Azure Automation Accounts give you a way to run your scripts, but it also gives you the ability to manage the scripts, version them within source code control, test them in a live environment as well as develop them directly within the Azure Portal using the Azure Automation IDE. One of the really cool things about this is that even if you are not a code jockey like me, there is a Graphical Editor for PowerShell that you can use to piece together scripts.
As this is a pretty deep topic, rather than walking all of the features and functions for working with Automation Runbooks, let’s take a look at both the PowerShell Code IDE as well as the Graphical Editor to understand how this is all brought together with the videos below:
For a different perspective on the Graphical Editor especially if you are trying to decide which Editor to use if you are creating a brand new Runbook, then you can take a look at my blog post where I talk about Graphical Editor, but from the perspective of a Coder which I definitely am. https://briancharrison.ghost.io/azure-automation-graphical-editor-coders-perspective/
Watcher Tasks
One additional area of functionality that is very tightly tied to Runbooks is a new feature called Watcher Tasks. This feature allows for you to watch for events within one or more VMs which will then perform some kind of action when these events occur. This is done through the combination of two Runbooks, one to watch and determine when an event occurs and the second will actually perform the triggering action.
In addition to the two Runbooks, there is also the additional Azure resource called the Watcher Task which ties the two Runbooks together. It defines which Runbook is the Watcher and which one is the Action, you will specify any variables that are used and then you will specify how often the Watcher Runbook should run with a frequency in minutes. At the end, this is just another way to leverage Automation Runbooks no matter which kind of Runbook you have available to you.
Desired State Configuration
The next area of functionality that Azure Automation provides is around configuration management of both Linux and Windows VMs that are deployed anywhere. This is accomplished through the use of PowerShell Desired State Configuration (DSC) which has been around for Windows servers for a long time. For those that might not be familiar with it, if you have heard of Ansible, Chef, or Puppet, then you can equate either of those to PowerShell DSC.
To implement DSC in a standard Data Center environment requires the Admins or Operational staff to implement a “Pull” server where the DSC scripts would be deployed and configured. Then you would have to configure each Windows server to know which Pull server to use, which script to use and then the frequencies for how often it should check for a new version of the script and how often it should validate its configuration against the script.
With Azure Automation DSC, this is all possible as a Service where Azure is providing the Pull servers. All you have to do is upload and compile a script and then setup the necessary configurations. Once that is done, Azure will deploy an Agent to each VM with those configurations and you now have Configuration Management as a Service.
It may sound like this is only something that you would want to use for Windows, but in reality PowerShell is now supported for both Linux and Windows VMs. To understand what is possible within Azure Automation, please take a look at the following video for a walk-through:
Inventory, Update & Change Management
The last area of functionality that is available within Azure Automation is actually not really Automation oriented, but more tied to the Configuration Management side of the Service. Specifically I am referring to the Inventory, Update & Change Management features. These features are very tightly tied into Azure Log Analytics.
What I mean by that is that these services are completely based on Log Queries and configurations tied to those particular queries. Each of them leverage the out of the box logging that is available from a VMs operating system, Event Logs and Syslog. Then using that logging they provide reporting and the ability to build alerts based on each category of log data.
For example, in the case of Change Tracking, the solution tracks changes to Windows and Linux software, Windows and Linux files, Windows registry keys, Windows services, and Linux daemons. By using the information on the Change Tracking dashboard, you can easily see the changes that were made in your VMs.
Once you have your VMs onboarded to the service, you can configure the service to track specific files within the OS, even changes to the content of the files, which can be very powerful for specific config files, such as the httpd.conf file for Apache Web Services. After the configuration has been defined, you can setup the necessary Log Queries within Log Analytics and corresponding Alerts to make sure that you are made aware when something changes that shouldn’t.
This same process can the be used for for the tracking of Updates for specific VMs with the additional capability of being able to schedule and deploy updates to the onboarded VMs automatically. With respect to the Inventory, you can collect and view inventory for software, files, Linux daemons, Windows Services, and Windows Registry keys of your onboarded VMs.
Conclusion
Hopefully this has given you a good indication of the feature set that is available within the Azure Automation service. There are great capabilities for automating scripts, both PowerShell and Python within Azure. This can be done as Watcher Tasks or scheduled and Webhook based triggers. There is also a great capability for Configuration Management as a service as well as tie-ins with Log Analytics to provide Change Tracking and Inventory & Update Management. If you are leveraging a lot of IaaS based services within your Azure environment, then I highly recommend you checking it out and see what features you can take advantage of.
