Troubleshoot Access Denied Errors during Data Import from Amazon S3

This document describes how to troubleshoot access denied errors that might occur when you import data from Amazon S3 into TiDB Cloud.

After you click Import on the Data Import page of the TiDB Cloud console and confirm the import process, TiDB Cloud starts validating whether it can access your data in your specified bucket URL. If you see an error message with the keyword AccessDenied, an access denied error has occurred.

To troubleshoot the access denied errors, perform the following checks in the AWS Management Console.

Check the policy of the IAM role

1. In the AWS Management Console, go to IAM > Access Management > Roles.
2. In the list of roles, find and click the role you have created for the target TiDB cluster. The role summary page is displayed.
3. In the Permission policies area of the role summary page, a list of policies is displayed. Take the following steps for each policy:
   1. Click the policy to enter the policy summary page.
   2. On the policy summary page, click the {}JSON tab to check the permission policy. Make sure that the Resource fields in the policy are correctly configured.

The following is a sample policy.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:GetObjectVersion"
            ],
            "Resource": "arn:aws:s3:::tidb-cloud-source-data/mydata/*"
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketLocation"
            ],
            "Resource": "arn:aws:s3:::tidb-cloud-source-data"
        },
        {
            "Sid": "AllowKMSkey",
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt"
            ],
            "Resource": "arn:aws:kms:ap-northeast-1:105880447796:key/c3046e91-fdfc-4f3a-acff-00597dd3801f"
        }
    ]
}

In this sample policy, pay attention to the following:

• In "arn:aws:s3:::tidb-cloud-source-data/mydata/*", "arn:aws:s3:::tidb-cloud-source-data" is a sample S3 bucket ARN, and /mydata/* is a directory that you can customize in your S3 bucket root level for data storage. The directory needs to end with /*, for example, "<Your S3 bucket ARN>/<Directory of your source data>/*". If /* is not added, the AccessDenied error occurs.

• If you have enabled AWS Key Management Service key (SSE-KMS) with customer-managed key encryption, make sure the following configuration is included in the policy. "arn:aws:kms:ap-northeast-1:105880447796:key/c3046e91-fdfc-4f3a-acff-00597dd3801f" is a sample KMS key of the bucket.

      {
          "Sid": "AllowKMSkey",
          "Effect": "Allow",
          "Action": [
              "kms:Decrypt"
          ],
          "Resource": "arn:aws:kms:ap-northeast-1:105880447796:key/c3046e91-fdfc-4f3a-acff-00597dd3801f"
      }
  

  If the objects in your bucket have been copied from another encrypted bucket, the KMS key value needs to include the keys of both buckets. For example, "Resource": ["arn:aws:kms:ap-northeast-1:105880447796:key/c3046e91-fdfc-4f3a-acff-00597dd3801f","arn:aws:kms:ap-northeast-1:495580073302:key/0d7926a7-6ecc-4bf7-a9c1-a38f0faec0cd"].

If your policy is not correctly configured as the preceding example shows, correct the Resource fields in your policy and try importing data again.

Check the bucket policy

1. In the AWS Management Console, open the Amazon S3 console, and then go to the Buckets page. A list of buckets is displayed.
2. In the list, find and click the target bucket. The bucket information page is displayed.
3. Click the Permissions tab, and then scroll down to the Bucket policy area. By default, this area has no policy value. If any denied policy is displayed in this area, the AccessDenied error might occur during data import.

If you see a denied policy, check whether the policy relates to the current data import. If yes, delete it from the area and retry the data import.

Check the trust entity

1. In the AWS Management Console, go to IAM > Access Management > Roles.
2. In the list of roles, find and click the role you have created for the target TiDB cluster. The role summary page is displayed.
3. On the role summary page, click the Trust relationships tab, and you will see the trusted entities.

The following is a sample trust entity:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::380838443567:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "sts:ExternalId": "696e6672612d617069a79c22fa5740944bf8bb32e4a0c4e3fe"
                }
            }
        }
    ]
}

In the sample trust entity:

• 380838443567 is the TiDB Cloud Account ID. Make sure that this field in your trust entity matches your TiDB Cloud Account ID.
• 696e6672612d617069a79c22fa5740944bf8bb32e4a0c4e3fe is the TiDB Cloud External ID. Make sure that this field in your trusted entity matches your TiDB Cloud External ID.

Check the Object Ownership

1. In the AWS Management Console, open the Amazon S3 console, and then go to the Buckets page. A list of buckets is displayed.

2. In the list of buckets, find and click the target bucket. The bucket information page is displayed.

3. On the bucket information page, click the Permissions tab, and then scroll down to the Object Ownership area. Make sure that the "Object Ownership" configuration is "Bucket owner enforced".

   If the configuration is not "Bucket owner enforced", the AccessDenied error occurs, because your account does not have enough permissions for all objects in this bucket.

To handle the error, click Edit in the upper-right corner of the Object Ownership area and change the ownership to "Bucket owner enforced". Note that this might affect your other applications that are using this bucket.

Check your bucket encryption type

There are more than one way to encrypt an S3 bucket. When you try to access the objects in a bucket, the role you have created must have the permission to access the encryption key for data decryption. Otherwise, the AccessDenied error occurs.

To check the encryption type of your bucket, take the following steps:

1. In the AWS Management Console, open the Amazon S3 console, and then go to the Buckets page. A list of buckets is displayed.
2. In the list of buckets, find and click the target bucket. The bucket information page is displayed.
3. On the bucket information page, click the Properties tab, scroll down to the Default encryption area, and then check the configurations in this area.

There are two types of server-side encryption: Amazon S3-managed key (SSE-S3) and AWS Key Management Service (SSE-KMS). For SSE-S3, further check is not needed because this encryption type does not cause access denied errors. For SSE-KMS, you need to check the following:

• If the AWS KMS key ARN in the area is displayed in black without an underline, the AWS KMS key is an AWS-managed key (aws/s3).
• If the AWS KMS key ARN in the area is displayed in blue with a link, click the key ARN to open the key information page. Check the left navigation bar to see the specific encryption type. It might be an AWS managed key (aws/s3) or a customer managed key.

Check the AWS article for instruction

If you have performed all the checks above and still get the AccessDenied error, you can check the AWS article How do I troubleshoot 403 Access Denied errors from Amazon S3 for more instruction.