Databricks Service Principals 実務と資格対策: 機械アカウント/自動化/権限委譲

本番ジョブやCI/CDパイプラインで「誰かの個人アカウント」の認証情報を使っていませんか？ 担当者が退職するとトークンが無効化され、パイプラインが一斉に止まる——これは多くの組織で実際に起きるインシデントです。Service Principal（サービスプリンシパル）はこの問題を解決する「機械専用のID」です。 人間のユーザーではなく、アプリケーション・自動化プロセス・CI/CDツールが Databricks API を呼び出すために使用します。

この記事では、Service Principalの作成から OAuth M2M 認証、Unity Catalog権限の付与、CI/CD連携、 そしてPATとの比較まで、実務と資格試験（Data Engineer Associate / Professional）の両面で必要な知識を整理します。

Service Principalとは何か

Service Principalは、Databricksのアカウントレベルで管理される非人間用のセキュリティプリンシパルです。 人間のユーザーと同様に、Unity CatalogのGRANT/REVOKEで権限を付与でき、監査ログにも操作が記録されます。 以下が人間ユーザーとの主な違いです。

• 対話的なログイン（UI/SSO）は行わない。API経由でのみ認証する
• 個人のメールアドレスではなく、Application IDで識別される
• 退職・異動の影響を受けない。チームの人事異動でパイプラインが止まるリスクを排除
• 最小権限の原則を適用しやすい。必要なテーブル・ジョブだけに権限を絞れる

Service Principalの作成方法

Service Principalは3つの方法で作成できます。環境規模と運用方針に応じて選択します。

方法1: Databricks UI（Admin Console）

Account Console → User Management → Service Principals → Add service principal で作成。 小規模な環境や初期検証に適しています。ワークスペースへの割り当てもUIから行えます。

方法2: SCIM API（プログラマティック）

# SCIM APIでService Principalを作成
curl -X POST "https://accounts.cloud.databricks.com/api/2.0/accounts/<account_id>/scim/v2/ServicePrincipals" \
  -H "Authorization: Bearer <admin_token>" \
  -H "Content-Type: application/json" \
  -d '{
    "displayName": "cicd-pipeline-sp",
    "entitlements": [
      { "value": "workspace-access" }
    ]
  }'

# レスポンスからapplicationIdを取得
# → "applicationId": "12345678-abcd-efgh-ijkl-123456789012"

方法3: Terraform（IaCによる管理）

resource "databricks_service_principal" "cicd_sp" {
  display_name = "cicd-pipeline-sp"
}

resource "databricks_service_principal_role" "cicd_sp_role" {
  service_principal_id = databricks_service_principal.cicd_sp.id
  role                 = "roles/workspace.user"
}

# ワークスペースへの割り当て
resource "databricks_mws_permission_assignment" "cicd_ws" {
  workspace_id = var.workspace_id
  principal_id = databricks_service_principal.cicd_sp.id
  permissions  = ["USER"]
}

Terraformは本番環境でのService Principal管理に最も推奨される方法です。 作成・権限付与・ワークスペース割り当てをすべてコードで管理でき、変更履歴がGitに残ります。

OAuth M2Mトークン取得のフロー

Service PrincipalがDatabricks APIを呼び出す際の認証方式として、OAuth Machine-to-Machine（M2M）が推奨されます。 これはOAuth 2.0のClient Credentials Grantに基づくフローです。

# ステップ1: Service Principalにシークレットを生成（Account Console or API）
# → Client ID: <application_id>
# → Client Secret: <generated_secret>

# ステップ2: OAuthトークンエンドポイントにリクエスト
curl -X POST "https://<workspace_url>/oidc/v1/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=<application_id>" \
  -d "client_secret=<generated_secret>" \
  -d "scope=all-apis"

# ステップ3: レスポンスのaccess_tokenをAPI呼び出しに使用
# {
#   "access_token": "eyJhbGciOiJSUzI1NiIs...",
#   "token_type": "Bearer",
#   "expires_in": 3600
# }

# ステップ4: 取得したトークンでAPIを呼び出す
curl -X GET "https://<workspace_url>/api/2.0/clusters/list" \
  -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIs..."

OAuth M2Mトークンは有効期限（デフォルト1時間）があり、期限切れ時は再取得が必要です。 PATのように長期間有効なトークンを持ち続けるリスクがなく、セキュリティ上の利点があります。

Unity Catalog権限の付与

Service PrincipalにUnity Catalogの権限を付与する方法は、人間のユーザーと同じくGRANT文を使います。 最小権限の原則に従い、ジョブが実際にアクセスするテーブルだけにSELECT/MODIFYを付与します。

-- ETLジョブ用SPに必要最小限の権限を付与
GRANT USAGE ON CATALOG production TO `cicd-pipeline-sp`;
GRANT USAGE ON SCHEMA production.sales TO `cicd-pipeline-sp`;
GRANT SELECT ON TABLE production.sales.raw_orders TO `cicd-pipeline-sp`;
GRANT MODIFY ON TABLE production.sales.cleaned_orders TO `cicd-pipeline-sp`;

-- Schema内にテーブルを新規作成する権限
GRANT CREATE TABLE ON SCHEMA production.sales TO `cicd-pipeline-sp`;

-- 権限の確認
SHOW GRANTS TO `cicd-pipeline-sp`;

CI/CD連携（GitHub Actions例）

GitHub ActionsからDatabricksジョブをトリガーする実装例です。 Service PrincipalのClient IDとClient SecretをGitHub Secretsに保存し、ワークフロー内でOAuthトークンを取得します。

# .github/workflows/deploy-databricks-job.yml
name: Deploy Databricks Job
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Databricks CLI
        run: pip install databricks-cli
      - name: Configure Databricks Auth
        env:
          DATABRICKS_HOST: ${{ secrets.DATABRICKS_HOST }}
          DATABRICKS_CLIENT_ID: ${{ secrets.SP_CLIENT_ID }}
          DATABRICKS_CLIENT_SECRET: ${{ secrets.SP_CLIENT_SECRET }}
        run: |
          databricks configure --host $DATABRICKS_HOST \
            --client-id $DATABRICKS_CLIENT_ID \
            --client-secret $DATABRICKS_CLIENT_SECRET
      - name: Deploy Job
        run: databricks jobs create --json @job-definition.json

PAT vs OAuth M2M 比較表

最小権限設計のベストプラクティス

• 用途別にService Principalを分離: ETL用、モデルサービング用、CI/CD用など、 用途ごとにSPを作成し、それぞれに必要最小限の権限を付与する
• ALL PRIVILEGESは使わない: 利便性のためにALL PRIVILEGESを付与すると、 将来そのSPの認証情報が漏洩した際の影響範囲が広がる
• PATを本番自動化に使わない: PATは個人の開発・デバッグ用に限定し、 自動化にはOAuth M2Mを使用する
• Client Secretはシークレットストアに保管: Databricks Secret Scopeや クラウドのシークレットマネージャー（AWS Secrets Manager / Azure Key Vault）に保管し、 コードやCI/CD設定にハードコードしない
• 定期的な棚卸し: 不要になったService Principalやその権限を定期的にレビューし、 使われていないSPは無効化する

試験で問われるポイント

Service Principalは Data Engineer Associate / Professional の両方で出題される重要トピックです。 以下のパターンを整理しておきましょう。

• 「CI/CDパイプラインから安全にDatabricks APIを呼び出すにはどうするか」→ Service Principal + OAuth M2M
• 「担当者退職時にジョブが止まるリスクを防ぐには」→ PATではなくService Principalを使用
• 「ジョブクラスタのSingle User Modeで指定するプリンシパルは」→ ジョブオーナーまたはService Principal
• 「Service Principalにテーブルアクセスを許可するには」→ GRANT USAGE + GRANT SELECT

問題で確認

よくある質問