Databricks Workload Identity Federation入門

クラウド環境でDatabricksクラスタがS3バケットやADLS Gen2ストレージにアクセスする場合、 従来はアクセスキーやInstance Profileといった「シークレットを保持する」方式が一般的でした。Workload Identity Federation（WIF）は、クラウドプロバイダーのIDメカニズムを利用してシークレットを保持せずに（鍵レスで）認証を行う仕組みです。

この記事では、WIFの概念、AWS/Azure/GCPそれぞれの実装方式の比較、 Instance Profile非推奨化の背景、そしてUnity Catalogとの統合を解説します。

なぜ鍵レス認証が必要か

従来のクラウドアクセス方式にはそれぞれセキュリティ上のリスクがあります。

WIFは「静的なシークレットを排除し、クラウドのIDベースの一時的な認証情報で認証する」ことで、 これらのリスクを構造的に排除します。

3クラウドのWIF実装比較

AWS環境でのWIF設定フロー

AWS環境では、IAM RoleにDatabricksのOIDCプロバイダーを信頼するTrust Policyを設定します。

1. IAM Roleを作成: S3バケットへのアクセス権限（GetObject/PutObject/DeleteObject/ListBucket）を付与したIAM Roleを作成
2. Trust PolicyにDatabricksを追加: DatabricksアカウントのOIDCプロバイダーARNを信頼する条件を設定
3. Unity CatalogでStorage Credentialを作成: IAM Role ARNを指定してStorage Credentialを作成
4. External Locationを作成: Storage Credentialを参照し、S3パスを指定してExternal Locationを作成

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::414351767826:role/unity-catalog-prod-UCMasterRole-xxxx"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "<databricks-account-id>"
        }
      }
    }
  ]
}

Azure環境でのWIF設定フロー

Azure環境では、Access ConnectorとManaged Identityを使用します。

1. Databricks Access Connectorを作成: AzureポータルまたはTerraformでAccess Connectorリソースを作成（System Assigned Managed Identityが自動付与）
2. ストレージアカウントにRBAC割り当て: Access ConnectorのManaged Identityに「Storage Blob Data Contributor」ロールを割り当て
3. Unity CatalogでStorage Credentialを作成: Access Connector IDを指定してStorage Credentialを作成
4. External Locationを作成: abfss://形式でADLSパスを指定

# Terraform例: Access Connector
resource "azurerm_databricks_access_connector" "unity" {
  name                = "unity-catalog-connector"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location

  identity {
    type = "SystemAssigned"
  }
}

# ストレージアカウントへのRBAC割り当て
resource "azurerm_role_assignment" "storage_contributor" {
  scope                = azurerm_storage_account.datalake.id
  role_definition_name = "Storage Blob Data Contributor"
  principal_id         = azurerm_databricks_access_connector.unity.identity[0].principal_id
}

GCP環境でのWIF設定フロー

GCP環境では、Workload Identity PoolとProviderを設定してDatabricksからのトークン交換を許可します。

1. サービスアカウントを作成: GCSバケットへのアクセス権限を持つGCPサービスアカウントを作成
2. Workload Identity Poolを作成: DatabricksのOIDCプロバイダーを信頼するPoolを構成
3. サービスアカウントの権限借用を許可: PoolのメンバーがサービスアカウントのTokenを取得できるよう設定
4. Unity CatalogでStorage Credentialを作成: サービスアカウントのEmailを指定

Instance Profile非推奨化の背景

AWS環境で長年使われてきたInstance Profileは、以下の理由で非推奨化が進んでいます。

• 粒度の粗さ: Instance Profileはクラスタ全体に同一のIAM Roleを適用するため、 「テーブルAにはアクセスできるがテーブルBにはアクセスできない」といった細粒度の制御ができない
• Unity Catalogとの非統合: Instance Profileはクラスタレベルの設定であり、 Unity Catalogのデータガバナンス（GRANT/REVOKE）とは独立して動作するため、権限管理が二重化する
• 共有クラスタでのリスク: 共有クラスタにInstance Profileを設定すると、 すべてのユーザーがそのIAM Roleの権限でクラウドリソースにアクセスできてしまう
• 管理の煩雑さ: クラスタごとにInstance Profileを設定・管理する運用負荷が高い

Unity CatalogのStorage Credential + External Locationによる方式では、 データアクセスの権限がUnity Catalogの権限体系に統合され、 ユーザー/グループ単位の細粒度制御が可能になります。

Unity Catalogとの統合

WIFはUnity Catalogの以下の概念と密接に関連しています。

この構成により、クラウドストレージのアクセス制御がUnity Catalogの権限体系に統合され、 Instance Profileのような「クラスタレベルの全員共有権限」を排除できます。

試験で問われるポイント

• 「シークレットなしでS3にアクセスするには」→ Workload Identity Federation（IAM Role + Trust Policy）
• 「Instance Profileの代わりに推奨される方式は」→ Unity Catalog Storage Credential（WIFベース）
• 「Azure環境でDatabricksからADLSにアクセスする推奨構成は」→ Access Connector + Managed Identity
• 「Storage CredentialとExternal Locationの関係は」→ Storage Credentialがクラウド認証、External Locationがパスの紐付け

問題で確認

よくある質問