หมายเหตุ
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลอง ลงชื่อเข้าใช้หรือเปลี่ยนไดเรกทอรีได้
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลองเปลี่ยนไดเรกทอรีได้
To execute Storage Actions on a storage account, you must create a storage task assignment. The assignment is saved as part of the storage account resource instance. It defines, among other settings, a subset of objects to target, when and how often a task runs against those objects, and where the execution reports are stored.
To create a storage task assignment, assign the Storage Actions managed identity an Azure built-in role or a custom role with the appropriate RBAC actions. Also, enable access for trusted Azure services in the network settings of the storage account. See Azure roles required to assign tasks. To learn how to create a storage task assignment, see Create and manage a storage task assignment.
Assignment settings
The following table describes the configuration settings of a storage task assignment.
Note
The names that appear in the following table appear in the Add Assignment page of the Azure portal. If you plan to create an assignment by using REST, an SDK, PowerShell, or Azure CLI, see the appropriate reference content set to obtain the names of specific properties used to configure each setting.
| Setting | Required or optional | Description |
|---|---|---|
| Subscription | Required | The subscription of the storage account that you want to add to this assignment. |
| Storage account name | Required | The storage account that you want to add to this assignment. You must be an owner of the storage account. This field appears only if you create the assignment in the context of a storage task. |
| Storage task name | Required | The storage task to which you want to assign your storage account. This field appears only if you create the assignment in the context of a storage account. |
| Storage task assignment name | Required | The name of the assignment. Assignment names must be between 2 and 62 characters in length and might contain only letters and numbers. |
| Filter by | Required | Option to either filter objects by using a prefix or to run the task against the entire storage account. |
| Include blob prefixes | Required | The string prefix that is used to narrow the scope of blobs that the task evaluates. This field is required only if you choose to filter by using a blob prefix. |
| Exclude blob prefixes | Optional | The string prefix that is used to exclude blobs that the task evaluates. Exclude blob prefixes must not be a superset beyond the scope of the include blob prefix. |
| Run type | Required | The type of run to perform. Choose Run once to execute the task a single time, Recurrent run to run on a schedule, or Mock run to simulate the task without performing any operations. A mock run scans and evaluates blobs against the task conditions and generates a report, but doesn't modify any data. |
| Run interval | Required | Specifies the time interval between task executions for recurrent runs. |
| Start from | Required | The date and time to begin running the task. |
| End by | Required | The date and time after which tasks stop running. Applicable only for recurrent runs. |
| Report export container | Required | The container where task execution reports are stored. |
Storage task authorization
As part of the assignment process, assign a role to the managed identity associated with the storage task. By default, a system-assigned managed identity is created when you provision the storage task. However, you also have the option to use a user-assigned managed identity with the storage task instead. You can't change the type of managed identity that is associated with the storage task after you provision the storage task.
When assigning a role, choose an Azure built-in or custom role that has the permission necessary to perform the operations defined in a storage task upon the target storage account. See Permission for a task to perform operations.
After you save the assignment, the managed identity is validated to ensure that it has the correct permissions to perform the tasks defined in the storage task. If you use the Azure portal to create the assignment, this validation step also occurs after you assign the role to the managed identity.
Network access to storage accounts
Grant access to trusted Azure services in the network settings of each target storage account. To learn more, see Grant access to trusted Azure services.
Mock runs
A mock run is a special type of task assignment run that simulates task execution without performing any operations on your blobs. When a mock run executes, it scans all blobs in scope, evaluates them against the task conditions, and generates a detailed report showing which blobs matched and what operations would have been performed — all without modifying any data.
Mock runs follow the same lifecycle as run-once assignments:
- Before execution, you can edit all assignment properties.
- You can stop a specific instance of a task assignment run while it is in progress, but you must create a new task assignment to run it again.
- After completion, you can transition an existing task assignment to a run-once or recurring run, but you cannot use it for another mock run. You must create a new task assignment to repeat a mock run.
For step-by-step instructions on creating a mock run, see Create and use a mock run.
Updates to the storage task definition
When you update the conditions or operations for the Storage Actions task, the system automatically propagates the task definition to its associated task assignments. You don't need to delete and recreate assignments to apply these changes. Scheduled task assignments use the updated definition on their next run. Task assignment runs that are already queued for execution or that are in progress don't update and use the older definition.
Before updating a task, review the assignments that reference it. A change to a shared task can affect processing across multiple storage accounts. If the change adds an operation, verify that the task's managed identity has the permissions required to perform that operation on each target.
For guidance on validating changes before saving them to a shared task, see Review the impact of changes to shared tasks.