Azure Automation Accounts and Security

The previous step gave you an overview of what Azure Automation is and how it enables and accelerates DevOps.

Let’s take Azure Automation one step further. You will now learn how to create an Azure Automation Account and set up Automation Security.

Creating an Automation Account

To start using the Microsoft Azure Automation service, you must first create an Automation account from within the Azure portal. Automation accounts are like Azure Storage accounts in that they serve as a container to store the Automation artefacts.

These artefacts could be a container for all your runbooks, runbook executions (jobs), and the assets on which your runbooks depend.

An Automation account gives you access to manage all Azure resources via an application program interface (API). To safeguard this, the Automation account creation requires subscription-owner access.

To use Azure Automation, you will need at least one Azure Automation account. However, it’s recommended that you create multiple automation accounts to segregate and limit the scope of access to minimise any risk to your estate.

For example, you might use one account for development, another for production, and another for your on-premises environment. You can have up to 30 Automation accounts.

Automation Security

When you create an Automation account, it’s important that you lock down the set of people that have access to it. The benefit of having an Automation account within the Azure Portal is that you have access to Role-Based Access Control functionality.

Role-Based Access Control

Role-Based Access Control (RBAC) allows you to control access to and monitor Microsoft Azure Automation accounts to ensure that resources aren’t wasted on poorly written automation solutions. With RBAC, you can limit both the scope (resources) and the permissions (roles) that users are given. You’ll use these roles to control access to Automation resources.

Each Azure subscription is associated with one Azure Active Directory (AD). Users, groups, and applications from that directory can manage resources in the Azure subscription. You can assign access rights by using the Azure portal, Azure command-line tools, and Azure Management APIs.

You can grant access by assigning the appropriate RBAC role to users, groups, and applications at a certain scope. The scope of a role assignment can be a subscription, a resource group, or a single resource. A role assigned at a parent scope also grants access to the ‘children’ contained within it.

The RBAC role that you assign dictates what resources the user, group, or application can manage within that scope. Some typical roles include:

• Owner. An owner can do anything, such as create objects, delete objects, modify things, and assign permissions to other users.
• Contributor. A contributor can do everything except modify permissions. A contributor cannot grant someone access to something but can create runbooks, execute them, and run them.
• Reader. A reader is a view-only administrator. Readers can view everything but cannot change anything.
• Automation operator. An Automation operator can perform tasks that are involved in the operation of an Automation account such as starting and stopping runbooks, but an operator cannot add new runbooks, modify runbooks, modify credentials, or grant permissions.
• User access administrator. A user access administrator can’t do anything to the Automation objects but can grant and revoke permissions.

For more information on Azure role definitions, see RBAC Built-In Roles. For a detailed explanation of specific actions that can be performed by each role, see RBAC in Automation.

Service Principals

A service principal is a local representation of your application in Active Directory. It contains the role assignment. As part of using Azure Automation runbooks to help operationalise Azure subscriptions, runbooks need to securely authenticate to Azure with a minimum of administration overhead.

As a best practice, authentication solutions usually entail using certificates to authenticate an Azure AD service principal that has been granted the relevant RBAC permissions to manage the Azure subscription.

To configure certificate-based authentication with Azure AD service principals from within Azure Automation PowerShell Workflow runbooks, see this tutorial.