# Identity and access management in AWS DataSync AWS uses security credentials to identify you and to grant you access to your AWS resources. You can use features of AWS Identity and Access Management (IAM) to allow other users, services, and applications to use your AWS resources fully or in a limited way, without sharing your security credentials. By default, IAM identities (users, groups, and roles) don't have permission to create, view, or modify AWS resources. To allow users, groups, and roles to access AWS DataSync resources and interact with the DataSync console and API, we recommend that you use an IAM policy that grants them permission to use the specific resources and API actions that they will need. You then attach the policy to the IAM identity that requires access. For an overview of the basic elements for a policy, see [Access management for AWS DataSync](managing-access-overview.md). **Topics** + [ # Access management for AWS DataSync ](managing-access-overview.md) + [ # AWS managed policies for AWS DataSync ](security-iam-awsmanpol.md) + [ # IAM customer managed policies for AWS DataSync ](using-identity-based-policies.md) + [ # Using service-linked roles for DataSync ](using-service-linked-roles.md) + [ # Permissions for tagging DataSync resources during creation ](supported-iam-actions-tagging.md) + [ # Cross-service confused deputy prevention ](cross-service-confused-deputy-prevention.md) # Access management for AWS DataSync Every AWS resource is owned by an AWS account. Permissions to create or access a resource are governed by permissions policies. An account administrator can attach permissions policies to AWS Identity and Access Management (IAM) identities. Some services (such as AWS Lambda) also support attaching permissions policies to resources. **Note** An *account administrator* is a user with administrator privileges in an AWS account. For more information, see [IAM best practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) in the *IAM User Guide*. **Topics** + [ ## DataSync resources and operations ](#access-control-specify-datasync-actions) + [ ## Understanding resource ownership ](#access-control-owner) + [ ## Managing access to resources ](#access-control-managing-permissions) + [ ## Specifying policy elements: Actions, effects, resources, and principals ](#policy-elements) + [ ## Specifying conditions in a policy ](#specifying-conditions) + [ ## Creating an VPC endpoint policy ](#endpoint-policy-example) ## DataSync resources and operations In DataSync, the primary resources are agent, location, task, and task execution. These resources have unique Amazon Resource Names (ARNs) associated with them, as shown in the following table. | Resource type | ARN format | | --- | --- | | Agent ARN | `arn:aws:datasync:region:account-id:agent/agent-id` | | Location ARN | `arn:aws:datasync:region:account-id:location/location-id` | | Task ARN | `arn:aws:datasync:region:account-id:task/task-id ` | | Task execution ARN | `arn:aws:datasync:region:account-id:task/task-id/execution/exec-id` | To grant permissions for specific API operations, such as creating a task, DataSync defines a set of actions that you can specify in a permissions policy. An API operation can require permissions for more than one action. ## Understanding resource ownership A *resource owner* is the AWS account that created the resource. That is, the resource owner is the AWS account of the *principal entity* (for example, an IAM role) which authenticates the request that creates the resource. The following examples illustrate how this behavior works: + If you use the root account credentials of your AWS account to create a task, your AWS account is the owner of the resource (in DataSync, the resource is the task). + If you create an IAM roles in your AWS account and grant permissions to the `CreateTask` action to that user, the user can create a task. However, your AWS account, to which the user belongs, owns the task resource. + If you create an IAM role in your AWS account with permissions to create a task, anyone who can assume the role can create a task. Your AWS account, to which the role belongs, owns the task resource. ## Managing access to resources A permissions policy describes who has access to what. The following section explains the available options for creating permissions policies. **Note** This section discusses using IAM in the context of DataSync. It doesn't provide detailed information about the IAM service. For complete IAM documentation, see [What is IAM?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) in the *IAM User Guide.* For information about IAM policy syntax and descriptions, see [AWS Identity and Access Management policy reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) in the *IAM User Guide.* Policies attached to an IAM identity are referred to as *identity-based* policies (IAM policies) and policies attached to a resource are referred to as *resource-based* policies. DataSync supports only identity-based policies (IAM policies). **Topics** + [ ### Identity-based policies ](#identity-based-policies) + [ ### Resource-based policies ](#resource-based-policies) ### Identity-based policies You can manage DataSync resource access with IAM policies. These policies can help an AWS account administrator do the following with DataSync: + **Grant permissions to create and manage DataSync resources** – Create an IAM policy that allows an IAM role in your AWS account to create and manage DataSync resources, such as agents, locations, and tasks. + **Grant permissions to a role in another AWS account or an AWS service** – Create an IAM policy that grants permissions to an IAM role in a different AWS account or an AWS service. For example: 1. The Account A administrator creates an IAM role and attaches a permissions policy to the role that grants permissions on resources in Account A. 1. The Account A administrator attaches a trust policy to the role that identifies Account B as the principal who can assume the role. To grant an AWS service permissions to assume the role, the Account A administrator can specify an AWS service as the principal in the trust policy. 1. The Account B administrator can then delegate permissions to assume the role to any users in Account B. This allows anyone using the role in Account B to create or access resources in Account A. For more information about using IAM to delegate permissions, see [Access management](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) in the *IAM User Guide*. The following example policy grants permissions to all `List*` actions on all resources. This action is a read-only action and doesn't allow resource modification. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowAllListActionsOnAllResources", "Effect": "Allow", "Action": [ "datasync:List*" ], "Resource": "*" } ] } ``` ------ For more information about using identity-based policies with DataSync, see [AWS managed policies](security-iam-awsmanpol.md) and [customer managed policies](using-identity-based-policies.md). For more information about IAM identities, see the [https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) . ### Resource-based policies Other services, such as Amazon S3, support resource-based permissions policies. For example, you can attach a policy to an Amazon S3 bucket to manage access permissions to that bucket. However, DataSync doesn't support resource-based policies. ## Specifying policy elements: Actions, effects, resources, and principals For each DataSync resource, the service defines a set of API operations (see [Actions](https://docs.aws.amazon.com/datasync/latest/userguide/API_Operations.html)). To grant permissions for these API operations, DataSync defines a set of actions that you can specify in a policy. For example, for the DataSync resource, the following actions are defined: `CreateTask`, `DeleteTask`, and `DescribeTask`. Performing an API operation can require permissions for more than one action. The following are the most basic policy elements: + **Resource** – In a policy, you use an Amazon Resource Name (ARN) to identify the resource to which the policy applies. For DataSync resources, you can use the wildcard character `(*)` in IAM policies. For more information, see [DataSync resources and operations](#access-control-specify-datasync-actions). + **Action** – You use action keywords to identify resource operations that you want to allow or deny. For example, depending on the specified `Effect` element, the `datasync:CreateTask` permission allows or denies the user permissions to perform the DataSync `CreateTask` operation. + **Effect** – You specify the effect when the user requests the specific action—this effect can be either `Allow` or `Deny`. If you don't explicitly grant access to (`Allow`) a resource, access is implicitly denied. You can also explicitly deny access to a resource, which you might do to make sure that a user cannot access it, even if a different policy grants that user access. For more information, see [ Authorization](https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html#intro-structure-authorization) in the *IAM User Guide*. + **Principal** – In identity-based policies (IAM policies), the user that the policy is attached to is the implicit principal. For resource-based policies, you specify the user, account, service, or other entity that you want to receive permissions (applies to resource-based policies only). DataSync doesn't support resource-based policies. To learn more about IAM policy syntax and descriptions, see [AWS Identity and Access Management policy reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) in the *IAM User Guide*. ## Specifying conditions in a policy When you grant permissions, you can use the IAM policy language to specify the conditions when a policy should take effect when granting permissions. For example, you might want a policy to be applied only after a specific date. For more information about specifying conditions in policy language, see [Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition) in the *IAM User Guide*. To express conditions, you use predefined condition keys. There are no condition keys specific to DataSync. However, there are AWS wide condition keys that you can use as appropriate. For a complete list of AWS wide keys, see [Available keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#AvailableKeys) in the *IAM User Guide*. ## Creating an VPC endpoint policy VPC endpoint policies help control access to DataSync API operations through DataSync VPC service endpoints and FIPS-enabled VPC service endpoints. VPC endpoint policies allow you to restrict specific DataSync API actions accessed through your VPC service endpoints, such as `CreateTask` or `StartTaskExecution`. An endpoint policy specifies the following information: + The principals that can perform actions. + The actions that can be performed. + The resources on which actions can be performed. For more information, see [Control access to VPC endpoints using endpoint policies](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html). **Example policy** The following is an example of a endpoint policy. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": [ "datasync:CreateTask", "datasync:StartTaskExecution", "datasync:DescribeTask" ], "Resource": "arn:aws:datasync:us-east-1:123456789012:task/*" } ] } ``` # AWS managed policies for AWS DataSync To add permissions to users, groups, and roles, it's easier to use AWS managed policies than to write policies yourself. It takes time and expertise to [create IAM customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) that provide your team with only the permissions they need. To get started quickly, you can use our AWS managed policies. These policies cover common use cases and are available in your AWS account. For more information about AWS managed policies, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*. AWS services maintain and update AWS managed policies. You can't change the permissions in AWS managed policies. Services occasionally add additional permissions to an AWS managed policy to support new features. This type of update affects all identities (users, groups, and roles) where the policy is attached. Services are most likely to update an AWS managed policy when a new feature is launched or when new operations become available. Services do not remove permissions from an AWS managed policy, so policy updates won't break your existing permissions. Additionally, AWS supports managed policies for job functions that span multiple services. For example, the `ReadOnlyAccess` AWS managed policy provides read-only access to all AWS services and resources. When a service launches a new feature, AWS adds read-only permissions for new operations and resources. For a list and descriptions of job function policies, see [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) in the *IAM User Guide*. ## AWS managed policy: AWSDataSyncReadOnlyAccess You can attach the `AWSDataSyncReadOnlyAccess` policy to your IAM identities. This policy grants read-only permissions for DataSync. To view the permissions for this policy, see [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDataSyncReadOnlyAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDataSyncReadOnlyAccess.html) in the *AWS Managed Policy Reference* . ## AWS managed policy: AWSDataSyncFullAccess You can attach the `AWSDataSyncFullAccess` policy to your IAM identities. This policy grants administrative permissions for DataSync and is required for AWS Management Console access to the service. `AWSDataSyncFullAccess` provides full access to DataSync API operations and the operations that interact with related resources (such as Amazon S3 buckets, Amazon EFS file systems, AWS KMS keys, and Secrets Manager secrets). The policy also grants permissions for Amazon CloudWatch, including creating log groups and creating or updating a resource policy. To view the permissions for this policy, see [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDataSyncFullAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDataSyncFullAccess.html) in the *AWS Managed Policy Reference* . ## AWS managed policy: AWSDataSyncServiceRolePolicy You can't attach the `AWSDataSyncServiceRolePolicy` policy to your IAM identities. This policy is attached to a service-linked role that allows DataSync to perform actions on your behalf. For more information, see [Using service-linked roles for DataSync](using-service-linked-roles.md). This policy grants administrative permissions that allow the service-linked role to create Amazon CloudWatch logs for DataSync tasks using Enhanced mode. ## Policy updates | Change | Description | Date | | --- | --- | --- | | [AWSDataSyncFullAccess](#security-iam-awsmanpol-awsdatasyncfullaccess) – Change | DataSync modified permission statements for `AWSDataSyncFullAccess`: The updated statements remove tagging conditions from the permissions DataSync uses to create Secrets Manager secrets. | May 13, 2025 | | [AWSDataSyncFullAccess](#security-iam-awsmanpol-awsdatasyncfullaccess) – Change | DataSync added new permissions to `AWSDataSyncFullAccess`: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/datasync/latest/userguide/security-iam-awsmanpol.html) These permissions let DataSync create, edit, and delete AWS Secrets Manager secrets. | May 7, 2025 | | [AWSDataSyncFullAccess](#security-iam-awsmanpol-awsdatasyncfullaccess) – Change | DataSync added new permissions to `AWSDataSyncFullAccess`: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/datasync/latest/userguide/security-iam-awsmanpol.html) These permissions let DataSync retrieve metadata about your AWS Secrets Manager secrets and AWS KMS keys, including any aliases associated with your keys. | April 23, 2025 | | [AWSDataSyncServiceRolePolicy](#security-iam-awsmanpol-awsdatasyncservicerolepolicy) – Change | DataSync added new permissions to the `AWSDataSyncServiceRolePolicy` policy that's used by the DataSync service-linked role `AWSServiceRoleForDataSync`: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/datasync/latest/userguide/security-iam-awsmanpol.html) These permissions let DataSync read metadata and values for secrets managed by AWS Secrets Manager. | April 15, 2025 | | [AWSDataSyncServiceRolePolicy](#security-iam-awsmanpol-awsdatasyncservicerolepolicy) – New policy | DataSync added a policy that's used by the DataSync service-linked role `AWSServiceRoleForDataSync`. This new managed policy automatically creates Amazon CloudWatch logs for your DataSync tasks that use Enhanced mode. | October 30, 2024 | | [AWSDataSyncFullAccess](#security-iam-awsmanpol-awsdatasyncfullaccess) – Change | DataSync added new a permission to `AWSDataSyncFullAccess`: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/datasync/latest/userguide/security-iam-awsmanpol.html) This permission lets DataSync create service-linked roles for you. | October 30, 2024 | | [AWSDataSyncFullAccess](#security-iam-awsmanpol-awsdatasyncfullaccess) – Change | DataSync added new a permission to `AWSDataSyncFullAccess`: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/datasync/latest/userguide/security-iam-awsmanpol.html) This permission lets you choose opt-in Regions when creating a DataSync task for transfers between AWS Regions. | July 22, 2024 | | [AWSDataSyncFullAccess](#security-iam-awsmanpol-awsdatasyncfullaccess) – Change | DataSync added new a permission to `AWSDataSyncFullAccess`: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/datasync/latest/userguide/security-iam-awsmanpol.html) This permission lets you choose a specific version of your [DataSync manifest](transferring-with-manifest.md). | February 16, 2024 | | [AWSDataSyncFullAccess](#security-iam-awsmanpol-awsdatasyncfullaccess) – Change | DataSync added new permissions to `AWSDataSyncFullAccess`: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/datasync/latest/userguide/security-iam-awsmanpol.html) These permissions help you create DataSync agents and locations for Amazon EFS, Amazon FSx for NetApp ONTAP, Amazon S3, and S3 on Outposts. | May 2, 2023 | | DataSync started tracking changes | DataSync started tracking changes for its AWS managed policies. | March 1, 2021 | # IAM customer managed policies for AWS DataSync In addition to AWS managed policies, you also can create your own identity-based policies for AWS DataSync and attach them to the AWS Identity and Access Management (IAM) identities that require those permissions. These are known as *customer managed policies*, which are standalone policies that you administer in your own AWS account. **Important** Before you begin, we recommend that you learn about the basic concepts and options for managing access to your DataSync resources. For more information, see [Access management for AWS DataSync](managing-access-overview.md). When creating a customer managed policy, you include statements about DataSync operations that can be used on certain AWS resources. The following example policy has two statements (note the `Action` and `Resource` elements in each statement): ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowsSpecifiedActionsOnAllTasks", "Effect": "Allow", "Action": "datasync:DescribeTask", "Resource": "arn:aws:datasync:us-east-1:111122223333:task/*" }, { "Sid": "ListAllTasks", "Effect": "Allow", "Action": "datasync:ListTasks", "Resource": "*" } ] } ``` ------ The policy's statements do the following: + The first statement grants permissions to perform the `datasync:DescribeTask` action on certain transfer task resources by specifying an Amazon Resource Name (ARN) with a wildcard character (`*`). + The second statement grants permissions to perform the `datasync:ListTasks` action on all tasks by specifying just a wildcard character (`*`) . ## Examples of customer managed policies The following example customer managed policies grant permissions for various DataSync operations. The policies work if you're using the AWS Command Line Interface (AWS CLI) or an AWS SDK. To use these policies in the console, you must also use the managed policy `AWSDataSyncFullAccess`. **Topics** + [ ### Example 1: Create a trust relationship that allows DataSync to access your Amazon S3 bucket ](#datasync-example1) + [ ### Example 2: Allow DataSync to read and write to your Amazon S3 bucket ](#datasync-example2) + [ ### Example 3: Allow DataSync to upload logs to CloudWatch log groups ](#datasync-example4) ### Example 1: Create a trust relationship that allows DataSync to access your Amazon S3 bucket The following is an example of a trust policy that allows DataSync to assume an IAM role. This role allows DataSync to access an Amazon S3 bucket. To prevent the [cross-service confused deputy problem](cross-service-confused-deputy-prevention.md), we recommend using the [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) and [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) global condition context keys in the policy. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "datasync.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "111111111111" }, "ArnLike": { "aws:SourceArn": "arn:aws:datasync:us-east-1:111111111111:*" } } } ] } ``` ------ ### Example 2: Allow DataSync to read and write to your Amazon S3 bucket The following example policy grants DataSync the minimum permissions to read and write data to an S3 bucket that's used as a destination location. **Note** The value for `aws:ResourceAccount` should be the account ID that owns the Amazon S3 bucket specified in the policy. ``` { "Version": "2012-10-17", "Statement": [ { "Action": [ "s3:GetBucketLocation", "s3:ListBucket", "s3:ListBucketMultipartUploads" ], "Effect": "Allow", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket", "Condition": { "StringEquals": { "aws:ResourceAccount": "123456789012" } } }, { "Action": [ "s3:AbortMultipartUpload", "s3:DeleteObject", "s3:GetObject", "s3:GetObjectTagging", "s3:GetObjectVersion", "s3:GetObjectVersionTagging", "s3:ListMultipartUploadParts", "s3:PutObject", "s3:PutObjectTagging" ], "Effect": "Allow", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*", "Condition": { "StringEquals": { "aws:ResourceAccount": "123456789012" } } } ] } ``` ### Example 3: Allow DataSync to upload logs to CloudWatch log groups DataSync requires permissions to be able to upload logs to your Amazon CloudWatch log groups. You can use CloudWatch log groups to monitor and debug your tasks. For an example of an IAM policy that grants such permissions, see [Allowing DataSync to upload logs to a CloudWatch log group](configure-logging.md#cloudwatchlogs). # Using service-linked roles for DataSync AWS DataSync uses AWS Identity and Access Management (IAM) [ service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to DataSync. Service-linked roles are predefined by DataSync and include all the permissions that the service requires to call other AWS services on your behalf. **Topics** + [ # Using roles for DataSync ](using-service-linked-roles-service-action-2.md) # Using roles for DataSync AWS DataSync uses AWS Identity and Access Management (IAM) [service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to DataSync. Service-linked roles are predefined by DataSync and include all the permissions that the service requires to call other AWS services on your behalf. A service-linked role makes setting up DataSync easier because you don’t have to manually add the necessary permissions. DataSync defines the permissions of its service-linked roles, and unless defined otherwise, only DataSync can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity. You can delete a service-linked role only after first deleting their related resources. This protects your DataSync resources because you can't inadvertently remove permission to access the resources. For information about other services that support service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes** in the **Service-linked roles** column. Choose a **Yes** with a link to view the service-linked role documentation for that service. ## Service-linked role permissions for DataSync DataSync uses the service-linked role named **AWSServiceRoleForDataSync** – Allows DataSync to perform essential operations for transfer task execution, including reading secrets from AWS Secrets Manager, and creating CloudWatch log groups and events. The AWSServiceRoleForDataSync service-linked role trusts the following services to assume the role: + `datasync.amazonaws.com` The service-linked role uses the AWS managed policy named [AWSDataSyncServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-awsdatasyncservicerolepolicy), which allows DataSync to complete the following actions on the specified resources: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Sid": "DataSyncCloudWatchLogCreateAccess", "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream" ], "Resource": [ "arn:*:logs:*:*:log-group:/aws/datasync*" ] }, { "Sid": "DataSyncCloudWatchLogStreamUpdateAccess", "Effect": "Allow", "Action": [ "logs:PutLogEvents" ], "Resource": [ "arn:*:logs:*:*:log-group:/aws/datasync*:log-stream:*" ] }, { "Sid": "DataSyncSecretsManagerReadAccess", "Effect": "Allow", "Action": [ "secretsmanager:DescribeSecret", "secretsmanager:GetSecretValue" ], "Resource": [ "arn:*:secretsmanager:*:*:secret:aws-datasync!*" ], "Condition": { "StringEquals": { "secretsmanager:ResourceTag/aws:secretsmanager:owningService": "aws-datasync", "aws:ResourceAccount": "${aws:PrincipalAccount}" } } } ] } ``` ------ You must configure permissions to allow your users, groups, or roles to create, edit, or delete a service-linked role. For more information, see [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*. ## Creating a service-linked role for DataSync You don't need to manually create a service-linked role. When you create a DataSync task in the AWS Management Console, the AWS CLI, or the AWS API, DataSync creates the service-linked role for you. In the AWS CLI or the AWS API, you can create a service-linked role with the `datasync.amazonaws.com` service name. For more information, see [Creating a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) in the *IAM User Guide*. If you delete this service-linked role, you can use this same process to create the role again. If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you create a DataSync task, DataSync creates the service-linked role for you again. If you delete this service-linked role, you can use the same IAM process to create the role again. ## Editing a service-linked role for DataSync DataSync does not allow you to edit the AWSServiceRoleForDataSync service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*. ## Deleting a service-linked role for DataSync If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up your service-linked role before you can manually delete it. ### Cleaning up a service-linked role Before you can use IAM to delete a service-linked role, you must first delete any resources used by the role. **Note** If the DataSync service is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes and try the operation again. **To delete DataSync resources used by the AWSServiceRoleForDataSync** 1. [Delete the DataSync agents](clean-up.md#deleting-agent) used by the task (if there are any). 1. [Delete the task's locations](clean-up.md#deleting-location). 1. [Delete the task](clean-up.md#delete-task). ### Manually delete the service-linked role Use the IAM console, the AWS CLI, or the AWS API to delete the AWSServiceRoleForDataSync service-linked role. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*. ## Supported Regions for DataSync service-linked roles DataSync supports using service-linked roles in all of the Regions where the service is available. For more information, see [AWS Regions and endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html). # Permissions for tagging DataSync resources during creation Some resource-creating AWS DataSync API actions enable you to specify tags when you create the resource. You can use resource tags to implement attribute-based access control (ABAC). For more information, see [ What is ABAC for AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) in the *IAM User Guide*. To enable users to tag resources on creation, they must have permissions to use the action that creates the resource (such as `datasync:CreateAgent` or `datasync:CreateTask`). If tags are specified in the resource-creating action, users must also have explicit permissions to use the `datasync:TagResource` action. The `datasync:TagResource` action is only evaluated if tags are applied during the resource-creating action. Therefore, a user that has permissions to create a resource (assuming there are no tagging conditions) doesn't require permissions to use the `datasync:TagResource` action if no tags are specified in the request. However, if the user attempts to create a resource with tags, the request fails if the user doesn't have permissions to use the `datasync:TagResource` action. ## Example IAM policy statements Use the following example IAM policy statements to grant `TagResource` permissions to users creating DataSync resources. The following statement allows users to tag a DataSync agent when they create the agent. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "datasync:TagResource", "Resource": "arn:aws:datasync:us-east-1:444455556666:agent/*" } ] } ``` ------ The following statement allows users to tag a DataSync location when they create the location. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "datasync:TagResource", "Resource": "arn:aws:datasync:us-east-1:111122223333:location/*" } ] } ``` ------ The following statement allows users to tag a DataSync task when they create the task. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "datasync:TagResource", "Resource": "arn:aws:datasync:us-east-1:444455556666:task/*" } ] } ``` ------ # Cross-service confused deputy prevention The confused deputy problem is a security issue where an entity that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action. In AWS, cross-service impersonation can result in the confused deputy problem. Cross-service impersonation can occur when one service (the *calling service*) calls another service (the *called service*). The calling service can be manipulated to use its permissions to act on another customer's resources in a way it should not otherwise have permission to access. To prevent this, AWS provides tools that help you protect your data for all services with service principals that have been given access to resources in your account. We recommend using the [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) and [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) global condition context keys in resource policies to limit the permissions that AWS DataSync gives another service to the resource. If you use both global condition context keys and the `aws:SourceArn` value contains the account ID, the `aws:SourceAccount` value and the account in the `aws:SourceArn` value must use the same account ID when used in the same policy statement. Use `aws:SourceArn` if you want only one resource to be associated with the cross-service access. Use `aws:SourceAccount` if you want any resource in that account to be associated with the cross-service use. The value of `aws:SourceArn` must include the DataSync location ARN with which DataSync is allowed to assume the IAM role. The most effective way to protect against the confused deputy problem is to use the `aws:SourceArn` key with the full ARN of the resource. If you don't know the full ARN or if you're specifying multiple resources, use wildcard characters (`*`) for the unknown portions. Here are some examples of how to do this for DataSync: + To limit the trust policy to an existing DataSync location, include the full location ARN in the policy. DataSync will assume the IAM role only when dealing with that particular location. + When creating an Amazon S3 location for DataSync, you don't know the location's ARN. In these scenarios, use the following format for the `aws:SourceArn` key: `arn:aws:datasync:us-east-2:123456789012:*`. This format validates the partition (`aws`), account ID, and Region. The following full example shows how you can use the `aws:SourceArn` and `aws:SourceAccount` global condition context keys in a trust policy to prevent the confused deputy problem with DataSync. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "datasync.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" }, "ArnLike": { "aws:SourceArn": "arn:aws:datasync:us-east-2:123456789012:*" } } } ] } ``` ------ For more example policies that show how you can use the `aws:SourceArn` and `aws:SourceAccount` global condition context keys with DataSync, see the following topics: + [Create a trust relationship that allows DataSync to access your Amazon S3 bucket](using-identity-based-policies.md#datasync-example1) + [Configure an IAM role to access your Amazon S3 bucket](create-s3-location.md#create-role-manually)