サービス資格情報を使用して外部クラウド サービスへのアクセスを管理する
プレビュー
この機能はパブリックプレビュー段階です。
この記事では、Unity Catalog Databricksから 外部クラウド サービス (AWS Glue やAWS Secrets Manager など) へのアクセスを制御できるサービス認証情報オブジェクトを で作成する方法について説明します。Unity Catalog のサービス資格情報は、そのようなサービスへのアクセスを許可する長期的なクラウド資格情報をカプセル化します。
サービスの資格情報は、Unity Catalog のマネージドストレージロケーションまたは外部ストレージの場所として使用されるクラウド ストレージへのアクセスを管理するためのものではありません。 これらのユースケースでは、ストレージ認証情報を使用します。 「Unity Catalog を使用してクラウド ストレージへのアクセスを管理する」を参照してください。
注:
サービスの資格情報はUnity Catalog 、インスタンスプロファイル の 代替手段であり、アクセスが特定のコンピュートリソースに関連付けられるのではなく、ユーザー、グループ、またはサービスプリンシパルに関連付けられるという利点があります。
AWSサービスにアクセスするためのサービス認証情報を作成するには、サービスへのアクセスを許可するIAMロールを作成し、そのIAMロールをサービス認証情報定義で参照します。
始める前に
サービス資格情報を作成する前に、次の要件を満たす必要があります。
Databricks:
Unity Catalogが有効化されたDatabricksワークスペース
CREATE SERVICE CREDENTIAL
ワークスペースにアタッチされた Unity Catalog メタストアに対する特権。 アカウント admins と metastore admins は、デフォルトによってこの特権を持っています。 ワークスペースで Unity Catalog が自動的に有効になっている場合、ワークスペース管理者にもこの特権があります。
AWSアカウントにおいて:
データにアクセスするワークスペースと同じリージョンにある AWS のサービス。
IAMロールを作成する権限
AWS IAMロールを参照するサービス資格情報を作成する
このセクションでは、次の方法について説明します。
サービスにアクセスするための 要件を満たす IAMロールを作成します。DatabricksAWS
Databricks から AWS サービスにアクセスするために使用できるサービス資格情報のセキュリティ保護可能なオブジェクトを Unity Catalog で作成する方法。
ステップ1:IAMロールを作成する
AWSで、ユーザーがアクセスできるようにするサービスへのアクセス権を付与するIAMロールを作成します。この IAMロールは、サービスと同じアカウントで定義されている必要があります。
ヒント
このアクセスを許可するIAMロールを既に作成している場合は、このステップをスキップして、「ステップ2:DatabricksにIAMロールの詳細を付与する」に進んでください。
サービスへのアクセスを許可する IAMロールを作成します。
ロールの作成は 2 段階のプロセスです。 このステップでは、ロールを作成し、 一時的な 信頼関係ポリシーとプレースホルダー外部 ID を追加します。この ID は、 Databricksでサービス資格情報を作成した後で変更します。
ロールの作成 後に 信頼ポリシーを変更する必要があるのは、ロールが自己仮定である必要がある (つまり、それ自体を信頼するように構成する必要がある) ためです。 したがって、ロールは、自己仮定ステートメントを追加する前に存在している必要があります。 自己引き受けロールに関する情報については、この Amazon ブログの記事を参照してください。 Databricks Self-assume role enforcement ポリシーに関する情報については、「Self-assume role enforcement ポリシー」を参照してください。
ポリシーを作成するには、プレースホルダー外部IDを使用する必要があります。
カスタム信頼ポリシーを使用してIAMロールを作成します。
カスタム信頼ポリシーフィールドに、以下のポリシーJSONを貼り付けます。
このポリシーは、Unity Catalog が Databricks ユーザーに代わってサービスにアクセスするロールを引き受けることができるように、クロスアカウントの信頼関係を確立します。 これは、
Principal
セクションの ARN で指定されます。 これは、Databricks によって作成されたロールを参照する静的な値です。 このポリシーでは、Databricks AWS ARNarn:aws:iam::414351767826:role/unity-catalog-prod-UCMasterRole-14S5ZJVKOTYTL
を使用します。 Databricks on AWS GovCloudを使用している場合は、Databricks on AWS GovCloud ARNarn:aws-us-gov:iam::044793339203:role/unity-catalog-prod-UCMasterRole-1QRFA8SGY15OJ
を使用してください。このポリシーは、プレースホルダーとして外部 ID を
0000
に設定します。 これは、後の手順でサービス資格情報の外部 ID に更新します。{ "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" } } }] }
アクセス許可ポリシーの構成をスキップします。この構成は、後のステップで追加します。
IAMロールを保存します。
サービスと同じアカウントに IAM ポリシーを作成します。
ガイドラインとして使用できる 2 つのサンプル ポリシーを次に示します。 サンプルポリシーの 1 つは、AWS Glue に接続するサービス認証情報用です。 もう 1 つは AWS Secrets Manager を参照します。 追加する実際のアクションとリソースは、接続するサービスと必要なアクセスのレベルによって異なります。 サービスの AWS IAM ドキュメントを参照してください。
sts:AssumeRole
アクションは、サービスに関係なく同じです。次の値を置き換えます。
<AWS-ACCOUNT-ID>
:AWSアカウントのアカウントID(Databricksアカウントではありません)。<AWS-IAM-ROLE-NAME>
:前のステップで作成したAWS IAMロールの名前。
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "secretsmanager:GetResourcePolicy", "secretsmanager:GetSecretValue" ], "Resource": [ "arn:aws:secretsmanager:us-west-2:111122223333:secret:aes128-1a2b3c" ], "Effect": "Allow" }, { "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::<AWS-ACCOUNT-ID>:role/<AWS-IAM-ROLE-NAME>" ], "Effect": "Allow" } ] }
次の値を置き換えます。
<AWS-GLUE-REGION>
: AWS Glue カタログを保持している AWS アカウントのリージョン。 この値と AWS アカウント ID が AWS Glue カタログ ID を構成します。<AWS-ACCOUNT-ID>
:AWSアカウントのアカウントID(Databricksアカウントではありません)。<AWS-IAM-ROLE-NAME>
:前のステップで作成したAWS IAMロールの名前。
注:
AWS Lake Formation を使用している場合は、IAMロールに Lake Formation リソースへのアクセス権を付与する必要もあります。https://docs.aws.amazon.com/lake-formation/latest/dg/hybrid-access-mode.html を参照してください。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "GrantCatalogAccessToGlue", "Effect": "Allow", "Action": [ "glue:GetDatabase", "glue:GetDatabases", "glue:GetPartition", "glue:GetPartitions", "glue:GetTable", "glue:GetTables", "glue:GetUserDefinedFunction", "glue:GetUserDefinedFunctions", "glue:BatchGetPartition" ], "Resource": [ "arn:aws:glue:<AWS-GLUE-REGION>:<AWS-ACCOUNT-ID>*", ] }, { "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::<AWS-ACCOUNT-ID>:role/<AWS-IAM-ROLE-NAME>" ], "Effect": "Allow" } ] }
IAMポリシーをIAMロールにアタッチします。
ロールの[アクセス許可]タブで、作成したIAMポリシーをアタッチします。
ステップ2:IAMロールの詳細をDatabricksに渡す
必要な権限: CREATE SERVICE CREDENTIAL
権限。 メタストア管理者ロールとアカウント管理者ロールの両方に、この特権が含まれています。 Unity Catalogが有効になっているワークスペースのワークスペース管理者にも、この権限が自動的に付与されます。
Databricksで、メタストアにリンクされているワークスペースにログインします。
[カタログ] をクリックします。
[クイック アクセス] ページで、[外部データ] > ボタンをクリックし、[資格情報] タブに移動して、[資格情報の作成] を選択します。
[サービス資格情報] を選択します。
[資格情報名] 、クラウド テナントのサービスへのアクセスを に許可する ロール ロール 、およびオプションのコメントを入力します。IAMARNUnity Catalog
[作成] をクリックします。
[サービス資格情報が作成されました] ダイアログで、外部 ID をコピーします。
また、外部 ID は、サービス資格情報の詳細ページでいつでも表示できます。 「サービス資格情報の表示」を参照してください。
[完了] をクリックします。
ステップ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": "<SERVICE-CREDENTIAL-EXTERNAL-ID>"
ポリシーは次のようになります。置換テキストは、サービス資格情報の外部 ID、アカウント ID、および IAMロールの値を使用するように更新されます。
{ "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": "<SERVICE-CREDENTIAL-EXTERNAL-ID>" } } } ] }
自己引き受け型ロールの適用ポリシー
2023 年 6 月 30 日、AWS は IAMロール信頼ポリシー を更新し、STS:AssumeRole
呼び出しに対してロールIAM明示的に自己信頼することを要求しました。その結果、Databricksは、サービス認証情報のAWS IAMロールを自己仮定することを求めており、まもなく非自己仮定サービス資格情報を禁止する予定です。 詳細については、この コミュニティのブログ記事を参照してください。
は、 2024 年 9 月 20Databricks 日より、自己想定しない ServiceAWSIAM ロールを使用した 資格情報の作成を禁止します。非自己仮定の IAMロールを持つ既存のサービス資格情報は引き続き機能しますが、それらのロールを使用して新しいサービス資格情報を作成することはできません。
2025 年 1 月 20 日に、Databricks は、非自己想定の IAMID ロールを持つ既存のサービス資格情報の使用のブロックを開始します。これにより、自己前提ではない資格情報を使用して実行されるワークロードやジョブが中断される可能性があります。
(オプション)特定のワークスペースにサービス資格情報を割り当てる
プレビュー
この機能はパブリックプレビュー段階です。
デフォルトでは、サービス資格情報には、メタストア内のすべてのワークスペースからアクセスできます。 つまり、ユーザーにそのサービス資格情報に対する特権が付与されている場合、メタストアに接続されている任意のワークスペースからその特権を行使できます。 ワークスペースを使用してユーザー データ アクセスを分離する場合は、特定のワークスペースからのみサービス資格情報へのアクセスを許可することができます。 この機能は、ワークスペース バインドまたはサービス資格情報の分離と呼ばれます。
サービス認証情報を特定のワークスペースにバインドする一般的なユースケースは、クラウド管理者が本番運用 クラウド アカウント 認証情報を使用してサービス認証情報を設定し、 Databricks ユーザーがこの認証情報を使用して、本番運用ワークスペースでのみ外部クラウド サービスにアクセスできるようにするシナリオです。
ワークスペースのバインドの詳細については、「 (オプション) ストレージ資格情報を特定のワークスペースに割り当てる 」および「 カタログ アクセスを特定のワークスペースに制限する」を参照してください。
サービス資格情報を 1 つ以上のワークスペースにバインドする
特定のワークスペースにサービス資格情報を割り当てるには、カタログ エクスプローラーを使用します。
必要なアクセス許可: メタストア管理者またはサービス資格情報の所有者。
注:
メタストア管理者は、カタログ エクスプローラーを使用してメタストア内のすべてのサービス資格情報を表示でき、サービス資格情報の所有者は、サービス資格情報が現在のワークスペースに割り当てられているかどうかに関係なく、メタストアで所有するすべてのサービス資格情報を表示できます。 ワークスペースに割り当てられていないサービス資格情報はグレー表示されます。
メタストアにリンクされているワークスペースにログインします。
サイドバーで、「 カタログ 」をクリックします。
[クイック アクセス] ページで、[外部データ>] ボタンをクリックし、[資格情報] タブに移動します。
サービス資格情報を選択し、[ ワークスペース] タブに移動します。
[ワークスペース] タブで、[すべてのワークスペースがアクセス可能] チェックボックスをオフにします。
サービス資格情報が既に 1 つ以上のワークスペースにバインドされている場合、このチェック ボックスは既にオフになっています。
[ワークスペースに割り当てる] をクリックし、割り当てるワークスペースを入力または検索します。
アクセス権を取り消すには、[ワークスペース] タブに移動し、ワークスペースを選択して、[取り消し] をクリックします。すべてのワークスペースからのアクセスを許可するには、[すべてのワークスペースがアクセス可能] チェックボックスをオンにします。
次のステップ
サービス資格情報を表示、更新、削除、および他のユーザーにサービス資格情報を使用するアクセス許可を付与する方法について説明します。 マネージドサービスの認証情報を参照してください。
コードでサービス資格情報を使用する方法について説明します。 「Unity Catalog サービスの資格情報を使用して外部クラウド サービスに接続する」を参照してください。
制限事項
次の制限が適用されます:
Databricks Runtime 15.4 LTS には、Python のサポートのみが含まれています。
SQLウェアハウスはサポートされていません。
サービス資格情報に対して実行されたアクションの一部の監査イベントは、
system.access.audit
テーブルに表示されません。 サービス資格情報を作成、削除、更新、読み取り、一覧表示、または使用したユーザーに関する監査情報が利用可能になります。 Audit log システムテーブルリファレンスを参照してください。サービス資格情報のプレビュー期間中、
INFORMATION_SCHEMA.STORAGE_CREDENTIALS
(非推奨) にはストレージ資格情報とサービス資格情報の両方が表示され、INFORMATION_SCHEMA.STORAGE_CREDENTIAL_PRIVILEGES
(非推奨) にはストレージ資格情報とサービス資格情報の両方に適用される特権が表示されます。 これは正しくないプレビュー動作であり、修正されるため、続行するために依存しないでください。 代わりに、ストレージとサービスの両方の資格情報にINFORMATION_SCHEMA.CREDENTIALS
とINFORMATION_SCHEMA.CREDENTIAL_PRIVILEGES
を使用する必要があります。