Уреди

Делите путем

Azure Automation account authentication overview

  • Чланак

Important

Azure Automation Run as accounts, including Classic Run as accounts have retired on 30 September 2023 and replaced with Managed Identities. You would no longer be able to create or renew Run as accounts through the Azure portal. For more information, see migrating from an existing Run As accounts to managed identity.

Azure Automation allows you to automate tasks against resources in Azure, on-premises, and with other cloud providers such as Amazon Web Services (AWS). You can use runbooks to automate your tasks, or a Hybrid Runbook Worker if you have business or operational processes to manage outside of Azure. Working in any one of these environments require permissions to securely access the resources with the minimal rights required.

This article covers authentication scenarios supported by Azure Automation and tells how to get started based on the environment or environments that you need to manage.

Automation account

When you start Azure Automation for the first time, you must create at least one Automation account. Automation accounts allow you to isolate your Automation resources, runbooks, assets, and configurations from the resources of other accounts. You can use Automation accounts to separate resources into separate logical environments or delegated responsibilities. For example, you might use one account for development, another for production, and another for your on-premises environment. Or you might dedicate an Automation account to manage operating system updates across all of your machines with Update Management.

An Azure Automation account is different from your Microsoft account or accounts created in your Azure subscription. For an introduction to creating an Automation account, see Create an Automation account.

Automation resources

The Automation resources for each Automation account are associated with a single Azure region, but the account can manage all the resources in your Azure subscription. The main reason to create Automation accounts in different regions is if you have policies that require data and resources to be isolated to a specific region.

All tasks that you create against resources using Azure Resource Manager and the PowerShell cmdlets in Azure Automation must authenticate to Azure using Microsoft Entra organizational identity credential-based authentication.

Managed identities

A managed identity from Microsoft Entra ID allows your runbook to easily access other Microsoft Entra protected resources. The identity is managed by the Azure platform and doesn't require you to provision or rotate any secrets. For more information about managed identities in Microsoft Entra ID, see Managed identities for Azure resources.

Managed identities are the recommended way to authenticate in your runbooks, and is the default authentication method for your Automation account.

Here are some of the benefits of using managed identities:

  • Using a managed identity instead of the Automation Run As account simplifies management.

  • Managed identities can be used without any additional cost.

  • You don't have to specify the Run As connection object in your runbook code. You can access resources using your Automation account's managed identity from a runbook without creating certificates, connections, etc.

An Automation account can authenticate using two types of managed identities:

  • A system-assigned identity is tied to your application and is deleted if your app is deleted. An app can only have one system-assigned identity.

  • A user-assigned identity is a standalone Azure resource that can be assigned to your app. An app can have multiple user-assigned identities.

Note

User-assigned identities are supported for cloud jobs only. To learn more about the different managed identities, see Manage identity types.

For details on using managed identities, see Enable managed identity for Azure Automation.

Subscription permissions

You need the Microsoft.Authorization/*/Write permission. This permission is obtained through membership of one of the following Azure built-in roles:

To learn more about classic subscription permissions, see Azure classic subscription administrators.

Microsoft Entra permissions

To renew the service principal, you need to be a member of one of the following Microsoft Entra built-in roles:

Membership can be assigned to ALL users in the tenant at the directory level, which is the default behavior. You can grant membership to either role at the directory level. For more information, see Who has permission to add applications to my Microsoft Entra instance?.

Automation account permissions

To update the Automation account, you need to be a member of one of the following Automation account roles:

To learn more about the Azure Resource Manager and Classic deployment models, see Resource Manager and classic deployment.

Note

Azure Cloud Solution Provider (CSP) subscriptions support only the Azure Resource Manager model. Non-Azure Resource Manager services are not available in the program. When you are using a CSP subscription, the Azure Classic Run As account is not created, but the Azure Run As account is created. To learn more about CSP subscriptions, see Available services in CSP subscriptions.

Role-based access control

Role-based access control is available with Azure Resource Manager to grant permitted actions to a Microsoft Entra user account and Run As account, and authenticate the service principal. Read Role-based access control in Azure Automation article for further information to help develop your model for managing Automation permissions.

If you have strict security controls for permission assignment in resource groups, you need to assign the Run As account membership to the Contributor role in the resource group.

Note

We recommend you don't use the Log Analytics Contributor role to execute Automation jobs. Instead, create the Azure Automation Contributor custom role and use it for actions related to the Automation account.

Runbook authentication with Hybrid Runbook Worker

Runbooks running on a Hybrid Runbook Worker in your datacenter or against computing services in other cloud environments like AWS, can't use the same method that is typically used for runbooks authenticating to Azure resources. This is because those resources are running outside of Azure and therefore, requires their own security credentials defined in Automation to authenticate to resources that they access locally. For more information about runbook authentication with runbook workers, see Run runbooks on a Hybrid Runbook Worker.

For runbooks that use Hybrid Runbook Workers on Azure VMs, you can use runbook authentication with managed identities instead of Run As accounts to authenticate to your Azure resources.

Next steps