📣

TiDB Cloud Premium はパブリックプレビュー中です。エンタープライズワークロード向けの無制限のスケーリング、即時の弾力性、高度なセキュリティを提供します。このページは自動翻訳されたものです。原文はこちらからご覧ください。

Amazon S3 からのデータインポート中に発生するアクセス拒否エラーのトラブルシューティング

このドキュメントでは、Amazon S3 からTiDB Cloudにデータをインポートするときに発生する可能性のあるアクセス拒否エラーのトラブルシューティング方法について説明します。

TiDB CloudコンソールのData ImportページでNextをクリックし、インポートプロセスを確認すると、 TiDB Cloudは指定されたバケットURI内のデータにアクセスできるかどうかの検証を開始します。キーワードAccessDeniedを含むエラーメッセージが表示された場合は、アクセス拒否エラーが発生しています。

アクセス拒否エラーのトラブルシューティングを行うには、AWS マネジメントコンソールで次のチェックを実行します。

指定された役割を引き受けることができません

このセクションでは、 TiDB Cloud が指定されたバケットにアクセスするために提供されたロールを引き受けることができない問題のトラブルシューティング方法について説明します。

信頼エンティティを確認する

TiDB Cloud Account IDとTiDB Cloud External IDは環境およびクラスターごとに異なるため、このドキュメントに記載されている値をそのままコピーしないでください。代わりに、TiDB Cloudコンソールから取得してください。

TiDB Cloudコンソールで対象のクラスターに移動し、左側のナビゲーションペインでData > Importをクリックします。
Import data from Cloud Storageをクリックします。
Import Data from Cloud Storageページで、クラウドプロバイダーとしてAmazon S3を選択します。
CredentialsセクションでClick here to create new one with AWS CloudFormationをクリックしてAdd New Role ARNダイアログを開き、 Having trouble? Create Role ARN manuallyを展開して、このクラスターのTiDB Cloud Account IDとTiDB Cloud External IDを表示します。

次に、IAMロールの信頼エンティティを確認します。

AWS マネジメントコンソールで、 IAM >Access Management>Rolesに移動します。
ロールのリストで、ターゲットTiDBクラスター用に作成したロールを見つけてクリックします。ロールの概要ページが表示されます。
ロールの概要ページで、 Trust relationshipsタブをクリックすると、信頼されたエンティティが表示されます。

以下は信頼エンティティのサンプルです。

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

サンプル信頼エンティティの場合:

380838443567はTiDB CloudアカウントIDです。信頼エンティティのこのフィールドがTiDB CloudアカウントIDと一致していることを確認してください。
696e6672612d617069a79c22fa5740944bf8bb32e4a0c4e3feはTiDB Cloud外部IDです。信頼できるエンティティのこのフィールドがTiDB Cloud外部IDと一致していることを確認してください。

IAMロールが存在するかどうかを確認する

IAMロールが存在しない場合は、 Amazon S3 アクセスを構成する手順に従ってロールを作成します。

外部IDが正しく設定されているか確認してください

指定されたロール{role_arn}を引き受けることができません。ロールの信頼関係の設定を確認してください。例えば、信頼エンティティがTiDB Cloud account IDに設定されているか、信頼条件のTiDB Cloud External IDが正しく設定されているかを確認してください。信頼エンティティを確認するを参照してください。

アクセスが拒否されました

このセクションでは、アクセスの問題をトラブルシューティングする方法について説明します。

IAMユーザーのポリシーを確認する

IAMユーザーの AWS アクセスキーを使用して Amazon S3 バケットにアクセスすると、次のエラーが発生する場合があります。

"アクセスキーID'{access_key_id}'とシークレットアクセスキー'{secret_access_key}'を使用したソース'{bucket_uri}'へのアクセスが拒否されました"

これは、権限不足のため、 TiDB Cloud がAmazon S3 バケットにアクセスできなかったことを示しています。Amazon S3 バケットにアクセスするには、以下の権限が必要です。

s3:GetObject
s3:ListBucket
s3:GetBucketLocation

IAMユーザーのポリシーを確認するには、次の手順を実行します。

AWS マネジメントコンソールで、 IAM >Access Management>Usersに移動します。
ユーザーリストで、 TiDB Cloudへのデータのインポートに使用したユーザーを見つけてクリックします。ユーザーの概要ページが表示されます。
ユーザー概要ページのPermission policies領域に、ポリシーの一覧が表示されます。各ポリシーごとに以下の手順を実行してください。
1. ポリシーをクリックすると、ポリシーの概要ページが表示されます。
2. ポリシーの概要ページで、 {}JSONタブをクリックして権限ポリシーを確認します。ポリシー内のResourceフィールドが正しく設定されていることを確認してください。

以下にサンプルポリシーを示します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject"
            ],
            "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"
        },
}

ユーザーに権限を付与してテストする方法の詳細については、ユーザーポリシーによるバケットへのアクセスの制御を参照してください。

IAMロールのポリシーを確認する

AWS マネジメントコンソールで、 IAM >Access Management>Rolesに移動します。
ロールのリストで、ターゲットTiDBクラスター用に作成したロールを見つけてクリックします。ロールの概要ページが表示されます。
ロールの概要ページのPermission policies領域に、ポリシーの一覧が表示されます。各ポリシーごとに以下の手順を実行してください。
1. ポリシーをクリックすると、ポリシーの概要ページが表示されます。
2. ポリシーの概要ページで、 {}JSONタブをクリックして権限ポリシーを確認します。ポリシー内のResourceフィールドが正しく設定されていることを確認してください。

以下はサンプルポリシーです。

{
    "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"
        }
    ]
}

このサンプルポリシーでは、次の点に注意してください。

"arn:aws:s3:::tidb-cloud-source-data/mydata/*"の"arn:aws:s3:::tidb-cloud-source-data"はサンプルの S3 バケット ARN で、 /mydata/*はデータストレージ用に S3 バケットのルートレベルでカスタマイズできるディレクトリです。ディレクトリの末尾は/* （例： "<Your S3 bucket ARN>/<Directory of your source data>/*" ）でなければなりません。 /*が追加されていない場合、 AccessDeniedエラーが発生します。
カスタマー管理のキー暗号化で AWS Key Management Service キー (SSE-KMS) を有効にしている場合は、次の設定がポリシーに含まれていることを確認してください。"arn:aws:kms:ap-northeast-1:105880447796:key/c3046e91-fdfc-4f3a-acff-00597dd3801f"はバケットのサンプル KMS キーです。
```
    {
        "Sid": "AllowKMSkey",
        "Effect": "Allow",
        "Action": [
            "kms:Decrypt"
        ],
        "Resource": "arn:aws:kms:ap-northeast-1:105880447796:key/c3046e91-fdfc-4f3a-acff-00597dd3801f"
    }
```
バケット内のオブジェクトが別の暗号化バケットからコピーされた場合、KMSキーの値には両方のバケットのキーを含める必要があります。例： "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"] 。

前の例のようにポリシーが正しく構成されていない場合は、ポリシー内のResourceフィールドを修正して、再度データのインポートを試みてください。

ヒント

権限ポリシーを複数回更新してもデータのインポート中にエラーAccessDeniedが発生する場合は、アクティブなセッションを取り消してみてください。 IAM > Access Management > Rolesに移動し、対象のロールをクリックしてロールの概要ページに進みます。ロールの概要ページでRevoke active sessionsを見つけ、ボタンをクリックしてアクティブなセッションを取り消します。その後、データのインポートを再試行してください。

他のアプリケーションに影響する可能性があることに注意してください。

バケットポリシーを確認する

AWS マネジメントコンソールで Amazon S3 コンソールを開き、 Bucketsページに移動します。バケットのリストが表示されます。
リストで対象のバケットを見つけてクリックします。バケット情報ページが表示されます。
Permissionsタブをクリックし、 Bucket policy領域までスクロールダウンします。デフォルトでは、この領域にはポリシー値がありません。この領域に拒否されたポリシーが表示されている場合、データのインポート中にエラーAccessDeniedが発生する可能性があります。

拒否されたポリシーが表示された場合は、そのポリシーが現在のデータインポートに関連しているかどうかを確認してください。関連している場合は、そのポリシーをエリアから削除し、データインポートを再試行してください。

オブジェクトの所有権を確認する

AWS マネジメントコンソールで Amazon S3 コンソールを開き、 Bucketsページに移動します。バケットのリストが表示されます。
バケットのリストで、対象のバケットを見つけてクリックします。バケット情報ページが表示されます。
バケット情報ページでPermissionsタブをクリックし、 Object Ownership領域までスクロールダウンします。"Object Ownership"設定が"Bucket owner enforced"になっていることを確認してください。
設定が"Bucket owner enforced"ではない場合、アカウントにこのバケット内のすべてのオブジェクトに対する十分な権限がないため、エラーAccessDeniedが発生します。

このエラーに対処するには、Object Ownership領域の右上にあるEditをクリックし、所有権を"Bucket owner enforced"に変更してください。ただし、このバケットを使用している他のアプリケーションに影響する可能性がありますのでご注意ください。

バケットの暗号化タイプを確認してください

S3バケットを暗号化する方法は複数あります。バケット内のオブジェクトにアクセスするには、作成したロールに、データの復号に必要な暗号化キーへのアクセス権限が付与されている必要があります。権限がない場合、エラーAccessDeniedが発生します。

バケットの暗号化タイプを確認するには、次の手順を実行します。

AWS マネジメントコンソールで Amazon S3 コンソールを開き、 Bucketsページに移動します。バケットのリストが表示されます。
バケットのリストで、対象のバケットを見つけてクリックします。バケット情報ページが表示されます。
バケット情報ページで、 Propertiesタブをクリックし、 Default encryption領域まで下にスクロールして、この領域の設定を確認します。

サーバー側暗号化には、Amazon S3 マネージドキー (SSE-S3) と AWS Key Management Service (SSE-KMS) の 2種類があります。SSE-S3 の場合、アクセス拒否エラーが発生しないため、これ以上の確認は不要です。SSE-KMS の場合は、以下の点を確認する必要があります。

当該エリア内の AWS KMS キー ARN が下線なしの黒色で表示されている場合、その AWS KMS キーは AWS 管理キー (aws/s3) です。
該当エリアのAWS KMSキーARNが青色でリンク付きで表示されている場合は、そのキーARNをクリックしてキー情報ページを開きます。左側のナビゲーションバーで具体的な暗号化タイプを確認してください。AWS管理キー（aws/s3）またはカスタマー管理キーのいずれかです。

SSE-KMSのAWS管理キー（aws/s3）の場合

この状況でエラーAccessDeniedが発生した場合、キーが読み取り専用であり、アカウント間の権限付与が許可されていないことが原因である可能性があります。詳細については、AWSの記事クロスアカウントユーザーがカスタム AWS KMS キーで暗号化された S3 オブジェクトにアクセスしようとすると、アクセス拒否エラーが発生するのはなぜですか?をご覧ください。

アクセス拒否エラーを解決するには、 Default encryption領域の右上隅にあるEditをクリックし、AWS KMS キーを「Choose from your AWS KMS keys」または「Enter AWS KMS key ARN」に変更するか、サーバー側の暗号化タイプを「AWS S3 Managed Key (SSE-S3)」に変更します。この方法に加えて、新しいバケットを作成し、カスタムマネージドキーまたは SSE-S3 暗号化方式を使用することもできます。

SSE-KMSの顧客管理キーの場合

この状況でエラーAccessDeniedを解決するには、キーのARNをクリックするか、KMSでキーを手動で検索してください。Key usersページが表示されます。ページの右上隅にあるAddをクリックして、 TiDB Cloudへのデータインポートに使用したロールを追加します。その後、データのインポートを再度お試しください。

ノート

バケット内のオブジェクトが既存の暗号化バケットからコピーされた場合は、AWS KMS キー ARN にソースバケットのキーも含める必要があります。これは、バケット内のオブジェクトがソースオブジェクトの暗号化と同じ暗号化方式を使用しているためです。詳細については、AWS ドキュメントレプリケーションでのデフォルトの暗号化の使用をご覧ください。

手順についてはAWSの記事を確認してください

上記のすべてのチェックを実行してもエラーAccessDeniedが発生する場合は、詳細な手順については AWS の記事Amazon S3 からの 403 アクセス拒否エラーをトラブルシューティングするにはどうすればいいですか?を確認してください。