AWS S3 に接続するためのストレージ認証情報を作成する

この記事では、Unity Catalog でストレージ認証情報を作成して AWS S3 に接続する方法について説明します。

テーブルとボリュームを格納する基盤となるクラウドストレージへのアクセスを管理するために、Unity Catalogは次のオブジェクトタイプを使用します。

ストレージ資格情報 は、クラウドストレージにアクセスするための長期的なクラウド資格情報をカプセル化します。
外部ロケーション には、ストレージ資格情報とクラウドストレージパスへの参照が格納されています。

詳細については、「Unity Catalogを使用してクラウドストレージへのアクセスを管理する」を参照してください。

注記

Unity Catalog を使用して、クラウドストレージではなく外部サービスへのアクセスを制御する場合は、「サービス資格情報を使用して外部クラウドサービスへのアクセスを管理する」を参照してください。

Unity Catalog は、 Databricks on AWS用の2つのクラウドストレージオプション( AWS S3 バケットとCloudflare R2バケット)をサポートしています。 Cloudflare R2は、主にDelta Sharingのユースケースで、データエグレス料金を回避したいと考えているケースを対象としています。 S3 は、他のほとんどのユースケースに適しています。この記事では、S3 のストレージ認証情報の作成に焦点を当てています。 Cloudflare R2 については、「 Cloudflare R2 に接続するためのストレージ資格情報を作成する」を参照してください。

S3バケットにアクセスするためのストレージ認証情報を作成するには、S3バケットパスへのアクセス（読み書き、読み書き）を許可するIAMロールを作成し、ストレージ認証情報の定義でそのIAMロールを参照します。

必要条件

Databricks:

Unity Catalogが有効化されたDatabricksワークスペース
CREATE STORAGE CREDENTIAL 権限（ワークスペースにアタッチされたUnity Catalogのメタストア上の）。アカウント管理者とメタストア管理者には、デフォルトでこれらの権限があります。

AWSアカウントにおいて：

S3 バケット。エグレス料金を回避するには、データにアクセスするワークスペースと同じリージョンにする必要があります。

追加の S3 バケット要件:
- バケット名にドット表記を含めることはできません（例：incorrect.bucket.name.notation）。バケットの命名ガイドの詳細については、AWSバケットの命名規則を参照してください。
- バケットに S3 アクセスコントロールリストをアタッチすることはできません。
IAMロールを作成する権限

ステップ 1: IAMロールを作成する

AWSで、ユーザーにアクセスを許可するS3バケットへのアクセスを許可するIAMロールを作成します。このIAMロールは、S3バケットと同じアカウントで定義する必要があります。

ヒント

IAMこのアクセス権を付与するロールをすでに作成している場合は、この手順をスキップして、「ステップ 2:Databricks IAMロールの詳細をに指定」に進むことができます。

S3バケットへのアクセスを許可するIAMロールを作成します。

ロールの作成は2段階のプロセスです。このステップでは、ロールを作成し、 一時的な 信頼関係ポリシーとプレースホルダーの外部IDを追加し、Databricksでストレージ認証情報を作成した後に変更します。

ロールは自己前提型である必要がある（つまり、ロール自体を信頼するように構成する必要がある）ため、ロールの作成後に信頼ポリシーを変更する必要があります。したがって、自己前提ステートメントを追加する前に、ロールが存在している必要があります。自己前提の役割については、この「Amazonブログ記事」を参照してください。

important

2024 年 9 月 20 日以降、Databricks は新しいストレージ資格情報の自己前提要件の適用を開始します。 2025 年 1 月 20 日に、Databricks は自己仮定ではない既存のストレージ資格情報のブロックを開始します。詳細については、「自己引き受けロールの適用ポリシー」を参照してください。

ポリシーを作成するには、プレースホルダー外部IDを使用する必要があります。

カスタム信頼ポリシー を使用してIAMロールを作成します。
カスタム信頼ポリシー フィールドに、以下のポリシーJSONを貼り付けます。

このポリシーは、Databricks ユーザーに代わって Unity Catalog がバケット内のデータにアクセスするロールを引き受けることができるように、クロスアカウントの信頼関係を確立します。これは、 Principal セクションの ARN で指定されます。これは、Databricks によって作成されたロールを参照する静的な値です。注 Databricks on AWS GovCloudを使用すると、ポリシーは若干異なります。

ポリシーは、プレースホルダーとして外部IDを0000に設定します。後の手順でストレージ資格情報の外部IDに更新します。

Databricks on AWS
Databricks on AWS GovCloud
Databricks on AWS GovCloud DoD

JSON
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": ["arn:aws:iam::414351767826:role/unity-catalog-prod-UCMasterRole-14S5ZJVKOTYTL"]
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "0000"
        }
      }
    }
  ]
}

JSON
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": ["arn:aws-us-gov:iam::044793339203:role/unity-catalog-prod-UCMasterRole-1QRFA8SGY15OJ"]
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "0000"
        }
      }
    }
  ]
}

JSON
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": ["arn:aws-us-gov:iam::170661010020:role/unity-catalog-prod-UCMasterRole-1DI6DL6ZP26A"]
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "0000"
        }
      }
    }
  ]
}

アクセス許可ポリシーの構成をスキップします。この構成は、後のステップで追加します。
IAMロールを保存します。
S3バケットと同じアカウントに次のIAMポリシーを作成し、次の値を置き換えます：
- <BUCKET>：S3バケットの名前。
- <KMS-KEY>：随意。暗号化が有効になっている場合は、S3バケットの内容を暗号化するKMSキーの名前を指定します。 暗号化が無効になっている場合は、IAMポリシーのKMSセクション全体を削除します。
- <AWS-ACCOUNT-ID>：AWSアカウントのアカウントID（Databricksアカウントではありません）。
- <AWS-IAM-ROLE-NAME>：前のステップで作成したAWS IAMロールの名前。
このIAMポリシーは、読み取りおよび書き込みアクセスを許可します。読み取りアクセスのみを許可するポリシーを作成することもできます。ただし、ストレージ認証情報は読み取り専用としてマークすることが可能であり、このIAMロールによって付与された書き込みアクセスはすべて無視されるため、これは不要な場合があります。
JSON
```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:ListBucket",
        "s3:GetBucketLocation",
        "s3:ListBucketMultipartUploads",
        "s3:ListMultipartUploadParts",
        "s3:AbortMultipartUpload"
      ],
      "Resource": ["arn:aws:s3:::<BUCKET>/*", "arn:aws:s3:::<BUCKET>"],
      "Effect": "Allow"
    },
    {
      "Action": ["kms:Decrypt", "kms:Encrypt", "kms:GenerateDataKey*"],
      "Resource": ["arn:aws:kms:<KMS-KEY>"],
      "Effect": "Allow"
    },
    {
      "Action": ["sts:AssumeRole"],
      "Resource": ["arn:aws:iam::<AWS-ACCOUNT-ID>:role/<AWS-IAM-ROLE-NAME>"],
      "Effect": "Allow"
    }
  ]
}
```

注記

Unity Catalogに対してより制限の厳しいIAMポリシーが必要な場合は、Databricksの担当者にお問い合わせください。

S3 バケットと同じアカウントのファイルイベントの IAM ポリシーを作成します。

注記

この手順はオプションですが、強くお勧めします。ユーザーに代わってファイルイベントを構成するための Databricks アクセス権を付与しない場合は、場所ごとにファイルイベントを手動で構成する必要があります。そうしないと、Databricks が将来リリースする可能性のある重要な機能へのアクセスが制限されます。

IAM ポリシーは、バケットのイベント通知設定の更新、SNS トピックの作成、SQS キューの作成、および SQS キューの SNS トピックへのサブスクライブを行う権限を Databricks に付与します。これらは、ファイルイベントを使用する機能に必要なリソースです。 <BUCKET> を S3 バケットの名前に置き換えます。

JSON
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ManagedFileEventsSetupStatement",
      "Effect": "Allow",
      "Action": [
        "s3:GetBucketNotification",
        "s3:PutBucketNotification",
        "sns:ListSubscriptionsByTopic",
        "sns:GetTopicAttributes",
        "sns:SetTopicAttributes",
        "sns:CreateTopic",
        "sns:TagResource",
        "sns:Publish",
        "sns:Subscribe",
        "sqs:CreateQueue",
        "sqs:DeleteMessage",
        "sqs:ReceiveMessage",
        "sqs:SendMessage",
        "sqs:GetQueueUrl",
        "sqs:GetQueueAttributes",
        "sqs:SetQueueAttributes",
        "sqs:TagQueue",
        "sqs:ChangeMessageVisibility",
        "sqs:PurgeQueue"
      ],
      "Resource": ["arn:aws:s3:::<BUCKET>", "arn:aws:sqs:*:*:csms-*", "arn:aws:sns:*:*:csms-*"]
    },
    {
      "Sid": "ManagedFileEventsListStatement",
      "Effect": "Allow",
      "Action": ["sqs:ListQueues", "sqs:ListQueueTags", "sns:ListTopics"],
      "Resource": ["arn:aws:sqs:*:*:csms-*", "arn:aws:sns:*:*:csms-*"]
    },
    {
      "Sid": "ManagedFileEventsTeardownStatement",
      "Effect": "Allow",
      "Action": ["sns:Unsubscribe", "sns:DeleteTopic", "sqs:DeleteQueue"],
      "Resource": ["arn:aws:sqs:*:*:csms-*", "arn:aws:sns:*:*:csms-*"]
    }
  ]
}

IAM ポリシーをIAMロールにアタッチします。

ロールの [Permission ] タブで、作成した IAM ポリシーをアタッチします。

ステップ 2:Databricks IAMロールの詳細をに伝える

Databricksで、メタストアにリンクされているワークスペースにログインします。

CREATE STORAGE CREDENTIAL権限が必要です。この権限はメタストア管理者ロールとアカウント管理者ロールの両方に含まれています。
[カタログ] をクリックします。
[クイックアクセス ] ページで、[ 外部データ] > ボタンをクリックし、[ 資格情報 ] タブに移動して、[ 資格情報の作成 ] を選択します。
AWS IAMロール の 認証情報の種類 を選択します。
資格情報の名前、クラウドテナント上のストレージの場所へのアクセスをUnity Catalogに承認するIAMロールARN、およびコメント（オプション）を入力します。

ヒント

でインスタンスプロファイル Databricksをすでに定義している場合は、[ インスタンスプロファイルのコピー] をクリックして、そのインスタンスプロファイルのIAM ロールをコピーできます。ARNインスタンスプロファイルのIAMロールには、DatabricksDatabricksユーザーに代わってバケットにアクセスするためにロールを引き受けることができる、アカウント間の信頼関係が必要です。IAMロールポリシーと信頼関係の要件の詳細については、「ステップ 1: IAMロールを作成する」を参照してください。

(オプション)このストレージ認証情報を使用する外部ロケーションへの読み取り専用アクセスをユーザーに許可する場合は、 [詳細オプション ] で [ 読み取り専用 ] を選択します。詳細については、「ストレージ認証情報を読み取り専用としてマークする」を参照してください。
作成をクリックします。
[ ストレージ資格情報が作成されました ]ダイアログで、[ 外部ID ]をコピーします。
[ 完了 ] をクリックします。
（オプション）ストレージ資格情報を特定のワークスペースにバインドします。

デフォルトにより、特権ユーザーは、メタストアに接続されている任意のワークスペースでストレージ資格情報を使用できます。特定のワークスペースからのアクセスのみを許可する場合は、 ワークスペース タブに移動してワークスペースを割り当てます。「(省略可能) 特定のワークスペースにストレージ資格情報を割り当てる」を参照してください。

Databricks Terraform プロバイダーと databricks_storage_credential を使用して、ストレージ資格情報を作成することもできます。

ステップ 3: IAMロールの信頼関係ポリシーを更新する

AWSで、信頼関係ポリシーを変更して、ストレージ認証情報の外部IDを追加し、自己前提にします。

保存したIAMロールに戻り、[ 信頼関係 ]タブに移動します。

信頼関係ポリシーを次のように編集します：

以下のARNを「Allow」ステートメントに追加してください。<YOUR-AWS-ACCOUNT-ID>と<THIS-ROLE-NAME>を実際のアカウントIDとIAMロール値に置き換えます。

"arn:aws:iam::<YOUR-AWS-ACCOUNT-ID>:role/<THIS-ROLE-NAME>"

"sts:AssumeRole"ステートメントで、プレースホルダーの外部IDを、前のステップでコピーしたストレージ認証情報の外部IDに更新してください。

"sts:ExternalId": "<STORAGE-CREDENTIAL-EXTERNAL-ID>"

これで、ポリシーは以下ようになり、ストレージ認証情報の外部ID、アカウントID、IAMロールの値を使用するように置換テキストが更新されました。

JSON
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::414351767826:role/unity-catalog-prod-UCMasterRole-14S5ZJVKOTYTL",
          "arn:aws:iam::<YOUR-AWS-ACCOUNT-ID>:role/<THIS-ROLE-NAME>"
        ]
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "<STORAGE-CREDENTIAL-EXTERNAL-ID>"
        }
      }
    }
  ]
}

手順 4: ストレージ資格情報を検証する

IAM「ステップ 3: ロールの信頼関係ポリシーを更新するIAM 」でロールの信頼ポリシーに変更を加えた後、IAM ロールがストレージ認証情報として適切に設定されていることを確認します。

注記

構成を検証するには、ストレージ認証情報の所有者、メタストア管理者であるか、ストレージ認証情報に対するCREATE EXTERNAL LOCATION権限を持っている必要があります。

Databricksで、メタストアにリンクされているワークスペースにログインします。
[カタログ] をクリックします。
[クイックアクセス ] ページで、[ 外部データ] > ボタンをクリックし、[ 資格情報 ] タブに移動します。

別の方法として、[カタログ] ウィンドウの上部にある歯車アイコンをクリックし、[ 認証情報 ] を選択することもできます。
検証するストレージ資格情報を選択します。
[ ] をクリックします。
いずれかのチェックが失敗した場合は、「ステップ 3: IAMロールの信頼関係ポリシーを更新する」に戻り、 IAMロールの信頼ポリシーを確認して正しく構成します。

ストレージ資格情報が検証されたら、それを使用して外部ロケーションを作成できます。

自己引き継ぎロールの強制ポリシー

2023 年 6 月 30 日、AWS は IAMロール信頼ポリシーを更新し、STS:AssumeRole 呼び出しに対してロールIAM明示的に自己信頼することを要求しました。その結果、Databricksは、ストレージ認証情報のAWS IAMロールを自己仮定型にすることを要求しており、まもなく非自己想定型ストレージ資格情報を禁止します。詳細については、このコミュニティのブログ記事を参照してください。

2024年9月20日 より、Databricksは自己引き受け型ではないAWS IAMロールのストレージ資格情報の作成を禁止します。自己引き受け型ではないIAMロールの既存のストレージ資格情報は引き続き機能しますが、それらのロールを使用して新しいストレージ認証情報を作成することはできません。

2025年1月20日 、Databricksは、既存のストレージ資格情報と自己引き受け型ではないIAMロールの使用のブロックを開始します。 これにより、自己引き受け型ではない資格情報を使用して実行されるワークロードやジョブが中断される可能性があります。

ストレージ認証情報の AWS IAMロールが自己仮定であるかどうかを確認するには、「ステップ 4: ストレージ認証情報を検証する」の手順に従います。 [Self Assume Role ] チェックが失敗した場合は、「ステップ 3: IAMロールの信頼関係ポリシーを更新する」に再度アクセスし、IAMロールの信頼ポリシーを自身を信頼するように再設定します。

メタストアに複数のストレージ資格情報があり、それを確認したい場合は、次のノートブックを使用して、メタストア内のすべてのストレージ資格情報が自主的に機能することを確認してください。

自己想定ストレージ資格情報検証ノートブック

Open notebook in new tab

(オプション)ストレージ資格情報を特定のワークスペースに割り当てる

デフォルトでは、ストレージ資格情報はメタストア内のすべてのワークスペースからアクセスできます。つまり、ユーザーがそのストレージ認証情報に対する権限（CREATE EXTERNAL LOCATIONなど）を与えられていれば、メタストアに接続されているどのワークスペースからでもその権限を行使できます。ワークスペースを使用してユーザーデータアクセスを分離する場合は、ストレージ資格情報へのアクセスを特定のワークスペースからのみ許可することをお勧めします。この機能は、ワークスペースのバインドまたはストレージ資格情報の分離と呼ばれます。

ストレージ資格情報を特定のワークスペースにバインドする一般的なユースケースには、クラウド管理者が運用クラウドアカウント資格情報を使用してストレージ資格情報を構成し、Databricksユーザーがこの資格情報を使用して運用ワークスペースでのみ外部の場所を作成できるようにする場合などが考えられます。

ワークスペースのバインドの詳細については、「 (オプション) 特定のワークスペースに外部ロケーションを割り当てる」および「特定のワークスペースへのカタログアクセスを制限する」を参照してください。

注記

ワークスペースバインディングは、ストレージ資格情報に対する権限が行使されるときに参照されます。たとえば、ユーザーがストレージ資格情報を使用して外部ロケーションを作成する場合、ストレージ資格情報のワークスペースバインディングは、外部ロケーションが作成されたときにのみチェックされます。作成された後、外部ロケーションはストレージ資格情報に設定されているワークスペースバインディングとは独立して機能します。

ストレージ資格情報を 1 つ以上のワークスペースにバインドする

ストレージ認証情報を特定のワークスペースに割り当てるには、カタログエクスプローラーまたはDatabricks CLIを使用できます。

必要なアクセス許可 : メタストア管理者、ストレージ資格情報の所有者、またはストレージ資格情報の MANAGE 。

注記

メタストア管理者は、カタログエクスプローラーを使用してメタストア内のすべてのストレージ資格情報を確認できます。ストレージ資格情報の所有者は、ストレージ資格情報が現在のワークスペースに割り当てられているかどうかに関係なく、メタストアで所有しているすべてのストレージ資格情報を確認できます。ワークスペースに割り当てられていないストレージ資格情報は、灰色で表示されます。

Catalog Explorer
CLI

Log in to a workspace that is linked to the metastore.
In the sidebar, click Catalog.
On the Quick access page, click the External data > button and go to the Credentials tab.
Select the storage credential and go to the Workspaces tab.
On the Workspaces tab, clear the All workspaces have access checkbox.

If your storage credential is already bound to one or more workspaces, this checkbox is already cleared.
Click Assign to workspaces and enter or find the workspaces you want to assign.

To revoke access, go to the Workspaces tab, select the workspace, and click Revoke. To allow access from all workspaces, select the All workspaces have access checkbox.

There are two Databricks CLI command groups and two steps required to assign a storage credential to a workspace.

In the following examples, replace <profile-name> with the name of your Databricks authentication configuration profile. It should include the value of a personal access token, in addition to the workspace instance name and workspace ID of the workspace where you generated the personal access token. See Databricks personal access token authentication.

Use the storage-credentials command group’s update command to set the storage credential’s isolation mode to ISOLATED:
Bash
```
databricks storage-credentials update <my-storage-credential> \
--isolation-mode ISOLATED \
--profile <profile-name>
```
The default isolation-mode is OPEN to all workspaces attached to the metastore.

Use the workspace-bindings command group’s update-bindings command to assign the workspaces to the storage credential:

Bash
databricks workspace-bindings update-bindings storage-credential <my-storage-credential> \
--json '{
  "add": [{"workspace_id": <workspace-id>}...],
  "remove": [{"workspace_id": <workspace-id>}...]
}' --profile <profile-name>

Use the "add" and "remove" properties to add or remove workspace bindings.

注記

Read-only binding (BINDING_TYPE_READ_ONLY) is not available for storage credentials. Therefore there is no reason to set binding_type for the storage credentials binding.

To list all workspace assignments for a storage credential, use the workspace-bindings command group’s get-bindings command:

Bash
databricks workspace-bindings get-bindings storage-credential <my-storage-credential> \
--profile <profile-name>

ワークスペースからのストレージ資格情報のバインド解除

Catalog Explorer または workspace-bindings CLI コマンドグループを使用してストレージ認証情報へのワークスペースのアクセスを取り消す手順については、「ストレージ認証情報を 1 つ以上のワークスペースにバインドする」を参照してください。

次のステップ

ストレージ認証情報を表示、更新、削除したり、他のユーザーにストレージ認証情報を使用する権限を付与したりできます。「ストレージ資格情報の管理」を参照してください。

ストレージの認証情報を使用して外部ロケーションを定義できます。クラウドストレージをDatabricksに接続するための外部ロケーションの作成を参照してください。

必要条件​

ステップ 1: IAMロールを作成する​

ステップ 2:Databricks IAMロールの詳細を に伝える​

ステップ 3: IAMロールの信頼関係ポリシーを更新する​

手順 4: ストレージ資格情報を検証する​

自己引き継ぎロールの強制ポリシー​

自己想定ストレージ資格情報検証ノートブック

(オプション)ストレージ資格情報を特定のワークスペースに割り当てる​

ストレージ資格情報を 1 つ以上のワークスペースにバインドする​

ワークスペースからのストレージ資格情報のバインド解除​

次のステップ​