はじめに
Unity Catalog が有効な Azure Databricks ワークスペースから、別の Microsoft Entra ID テナントに属する Azure Data Lake Storage Gen2 (ADLS Gen2) に安全にアクセスし、データの読み書きを行いたいケースがあります。
読み取りのみであれば Delta Sharing を使うことができますが、書き込みを行うケースでは Delta Sharing では対応できません。
また、同一テナント内であればアクセス コネクタを用いた構成が一般的ですが、アクセス コネクタが利用するマネージド ID はクロステナント シナリオをサポートしていません (参考: Azure リソースのマネージド ID に関してよく寄せられる質問)。
そのため、クロステナント環境での安全なデータアクセスを実現するために、マルチテナント設定のサービス プリンシパル (SP) を Unity Catalog のストレージ資格情報として使用する構成が有効です。
この記事では、まずネットワーク制限の無い最小構成を紹介し、その後に Private Link を利用した閉域構成を解説します。
参考
本記事は、以下の Azure Networking Blog を参考にしています。
1. SP を使った最小構成
構成イメージは以下の通りです。最小構成なので ADLS Gen2 側のネットワーク制限は無し (Public Access Enabled) とします。
マルチテナント アプリケーションとしてのサービス プリンシパル
マルチテナント用のサービス プリンシパルの仕組みは次のとおりです。
- Tenant A 側で「アプリ登録」を行うと、そのアプリに対応するサービス プリンシパル (SP) が Tenant A に作成されます
- そのアプリ登録が「マルチテナント対応」に設定されている場合、Tenant B 側のユーザーが同意 (consent) すると、Tenant B 側にも同一アプリ ID を持つ SP が作成されます
- この Tenant B 側の SP は、Tenant B から見ると「マルチテナント アプリケーション」として登録された形になります
この Tenant B 側に作成された SP に対して、ADLS Gen2 側で Azure RBAC によりアクセス権を付与することで、Tenant A 側から Tenant B のリソースへ安全にアクセスできるようになります。
このように、実際のアクセス許可は Tenant B 側で作成された SP に対して与えられる点が、クロステナント シナリオの重要なポイントです。
マルチテナント アプリケーションの詳細については以下の日本マイクロソフトのサポート情報のブログをご覧ください。
1-1. サービス プリンシパルの作成 (Databricks側)
-
Azure ポータルで Databricks ワークスペースが存在するテナントのサブスクリプションにサインインする
-
Microsoft Entra ID → アプリの登録 → 新しい登録 を開く
-
任意の名前でアプリケーションを作成する
- サポートされるアカウントの種類: 任意の組織のディレクトリ内のアカウント (任意の Microsoft Entra ID テナント - マルチテナント)
- リダイレクト URI: 任意の URI を指定する必要がある。ここでは Web で
https://login.microsoftonline.com/common/oauth2/nativeclientを指定
-
作成後、以下を控える
- アプリケーション (クライアント) ID
-
証明書とシークレット → 新しいクライアント シークレット を作成し、値を控える
- 適切な期限を設定する
- 値を控える
これらの情報（クライアント ID, クライアント シークレット）は、後で Unity Catalog のストレージ資格情報を作成する際に使用します。
リダイレクト URI を省略した場合の挙動
リダイレクト URI を省略すると、後続の手順で Entra ID テナントの同意を付与した後に、エラーメッセージ AADSTS500113: No reply address is registered for the application. が表示されます。
クライアント シークレットの最大有効期間に注意
クライアント シークレットの最大有効期間は 730 日 (24 ヶ月) です。有効期間を迎える前にシークレットのローテーションが必要なことを認識しておく必要があります。
1-2. 同意および RBAC 権限の付与 (Storage側)
-
Entra ID のアプリケーション管理者ロールを持つユーザーで、ストレージ アカウントが存在するテナントにサインインし、次の URL にアクセスして管理者の同意を付与する
https://login.microsoftonline.com/{tenantB-directory-id}/adminconsent?client_id={sp-client-id}-
{tenantB-directory-id}は Storage 側テナントのディレクトリ ID、 -
{sp-client-id}は Databricks 側で作成した SP のクライアント ID - 上記 URL にアクセス & サインイン後、以下の画面が表示されるので承諾をクリック
- 空白のページに遷移するが、URL が
https://login.microsoftonline.com/common/oauth2/nativeclient?admin_consent=True&tenant={tenantB-directory-id}のようになっていればOK
-
-
同意が付与されたら、Azure ポータルで対象のストレージ アカウントを開き、アクセス制御 (IAM) を選択する
-
「ロールの割り当てを追加」を選択する
-
ロールに「ストレージ Blob データ共同作成者」を選択する
-
メンバーに先ほど作成した SP を指定する
-
割り当てを保存する
この設定により、Databricks 側テナントで作成したマルチテナント用 SP に対して、Storage 側の ADLS Gen2 への読み書き権限が付与されます。
1-3. ストレージ資格情報の登録 (Databricks側)
-
Unity Catalog のストレージ資格情報の作成権限を持つユーザーで Databricks ワークスペースにサインインする
-
ノートブックを新規作成し、以下を貼り付けて実行し、ストレージ資格情報を作成する
- セル 1: シークレットを使うのが望ましいが、ここでは簡単のために
getpassで必要な値をインタラクティブに入力-
directory_id: Storage 側の Entra ID テナント ID -
application_id: SP 作成時に控えたアプリケーション (クライアント) ID -
client_secret: SP 作成時に控えたクライアント シークレット
-
import getpass directory_id = getpass.getpass("Enter directory_id: ") application_id = getpass.getpass("Enter application_id: ") client_secret = getpass.getpass("Enter client_secret: ")- セル 2: Databricks SDK for Python を用いたコマンドを実行する
- 備考：他にも REST API や Databricks CLI を用いる方法がある (ストレージ資格情報作成について現状 SQL コマンドは未サポート)
from databricks.sdk import WorkspaceClient from databricks.sdk.service.catalog import AzureServicePrincipal w = WorkspaceClient() w.storage_credentials.create( name=f"cred_sp", azure_service_principal=AzureServicePrincipal( directory_id=directory_id, application_id=application_id, client_secret=client_secret ) )- 以下のような実行結果になる
- セル 1: シークレットを使うのが望ましいが、ここでは簡単のために
-
作成したストレージ資格情報は UI からも確認できる
- カタログ エクスプローラー > 外部データ > 資格情報
1-4. 外部ロケーションの作成と動作確認 (Databricks側)
-
ノートブックまたは SQL エディタで、以下を実行して外部ロケーションを作成する
CREATE EXTERNAL LOCATION extloc_sp URL 'abfss://<container>@<storage-account>.dfs.core.windows.net/<path>' WITH (STORAGE CREDENTIAL sp_credential) COMMENT 'cross-tenant access to ADLS Gen2' -
作成したストレージ資格情報は UI からも確認できる
- カタログ エクスプローラー > 外部データ > 外部ロケーション
- 念の為、接続のテストがすべてパスすることを確認しておくと良い
1-5. 動作確認 (Databricks側)
-
カタログ エクスプローラーから上記外部ロケーションを指定して新規カタログを作成
-
カタログ エクスプローラーから上記カタログ配下に新規スキーマを作成
-
ファイル アップロード機能を用いて新規テーブルを作成
-
テーブルが作成され、データが存在することを確認
これで、Azure Databricks ワークスペースから SP を介して別テナントの ADLS Gen2 に読み書きできていることが確認できました。
2. Private Link 構成
この構成では、Databricks 側から別テナントの ADLS Gen2 に対して Azure Private Link 経由でアクセスします。Private Link はクロス テナントのシナリオを問題なくサポートします。
VNet 内で稼働するクラスター (クラシック コンピューティング) から ADLS Gen2 への Private Link の構成手順は以下の通りです。
2-1. Private Endpoint の作成 (Databricks側)
-
Storage 側テナントのストレージ アカウントの「設定」 > エンドポイントからリソース ID を控えておく
-
Databricks 側テナントで Azure ポータルを開き、Private Endpoint の新規作成画面に進む
-
接続先リソースとして Storage 側テナントのストレージ アカウントのリソース ID を入力し、サブリソース名に「dfs」を指定する
-
Databricks ワークスペースから Private Endpoint に到達できるネットワークを指定する
-
プライベート DNS 統合は選択できないためスキップし、新規作成する
-
同様の手順で、もう 1 つ「blob」サブリソースを指定した Private Endpoint を作成する
2-2. Private Endpoint の承認 (Storage側)
-
Storage 側テナントにサインインする
-
ストレージ アカウント > ネットワーク > プライベート エンドポイントを開く
-
Databricks 側からの dfs と blob 双方の要求を承認する
2-3. DNS 設定 (Databricks側)
-
プライベート DNS ゾーン
privatelink.dfs.core.windows.netを作成する
-
サブリソース dfs のプライベート エンドポイントに関連付けられたネットワーク インターフェイスのプライベート IPv4 アドレスを A レコードで追加する
-
プライベート DNS ゾーンを Databricks ワークスペースが統合された VNet に関連付ける
-
上記 1-3 をプライベート DNS ゾーン
privatelink.blob.core.windows.netに対しても同様に実施する
2-4. 動作確認 (Databricks側)
SP の構成、ストレージ資格情報、カタログ・テーブルの作成手順は前章と同様に実施してあるものとし、クラシック コンピューティングのクラスターを起動し、Private Link 経由でデータの読み書きが行えることを確認する
2-5. サーバーレス コンピューティングの Private Link 構成
サーバーレス コンピューティングから ADLS Gen2 へのプライベート接続の構成については、以下のドキュメントの手順に沿って作業を行えば OK です。
これで、Databricks 側から別テナントの ADLS Gen2 へ閉域で安全にアクセスできる構成が完成しました。
まとめ
別テナントのストレージに対しても、SP を利用することで Unity Catalog 管理下の Databricks ワークスペースから安全にデータを読み書きできます。ポイントは、Databricks 側テナントでマルチテナント用のサービス プリンシパルを作成し、Storage 側で管理者同意と RBAC 権限を付与するという構成にあります。
また、Private Link を組み合わせることで、プライベート接続も実現できます。これらを押さえておくことで、シンプルかつセキュアなクロス テナント アクセスを構築できます。