メインコンテンツまでスキップ
に最終更新

フェデレーション ポリシーを構成する

Databricks OAuth トークンフェデレーションを使用すると、ID プロバイダー (IdP) からトークンを使用して Databricks API に安全にアクセスできます。 OAuth トークンのフェデレーションを有効にするには、フェデレーションポリシーを Databricks アカウント全体またはワークロード用に構成する必要があります。

このページでは、OAuth トークン フェデレーション ポリシーを作成して構成する方法について説明します。

ワークロード ID フェデレーション​

ワークロードアイデンティティフェデレーションにより、Databricksの外部で実行される自動化されたワークロードは、Databricksシークレットを必要とせずにDatabricks APIにアクセスできます。アカウント 管理者は、サービスプリンシパル フェデレーション ポリシーを使用してワークロード ID フェデレーションを構成できます。

サービスプリンシパル フェデレーション ポリシーは、 Databricks アカウントのサービスプリンシパルに関連付けられ、次の項目を指定します。

  • サービスプリンシパルが認証できる ID プロバイダー (または発行者)。
  • Databricks サービスプリンシパルとしての認証が許可されているワークロード ID (またはサブジェクト)。

たとえば、 GitHub Actions ワークロードに対して次のサービスプリンシパル フェデレーション ポリシーがあるとします。

  • 発行者： https://token.actions.githubusercontent.com
  • オーディエンス： https://github.com/my-github-org
  • サブジェクト： repo:my-github-org/my-repo:environment:prod

この JWT 本文を使用して、Databricks に対して認証できます。

JSON
{
  "iss": "https://token.actions.githubusercontent.com",
  "aud": "https://github.com/my-github-org",
  "sub": "repo:my-github-org/my-repo:environment:prod"
}

サービスプリンシパル フェデレーション ポリシーを構成する​

アカウント管理者は、 Databricks CLI または Databricks APIを使用してサービスプリンシパルフェデレーションポリシーを構成できます。 Databricksサービスプリンシパルごとに最大 20 個のサービスプリンシパル フェデレーション ポリシーを作成できます。

サービスプリンシパル フェデレーション ポリシーを設定するには、以下を指定する必要があります。

  • 発行者URL: ワークロード ID トークンの iss 要求で指定された、ワークロード ID プロバイダーを識別する HTTPS URL。

  • サブジェクト: ワークロード ランタイム環境内のワークロードの一意の識別子。指定しない場合は、デフォルトはsubです。

  • オーディエンス： aud 要求で指定されているトークンの意図された受信者。トークンは、その対象ユーザーがポリシー内の少なくとも 1 つの対象と一致する場合、一致と見なされます。指定しない場合、 デフォルト は あなたの Databricks アカウント IDです。

  • サブジェクト要求: (省略可能) トークンのワークロード ID (サブジェクトとも呼ばれます) を含むトークン要求を指定します。設定しない場合、 Databricks は デフォルトで sub を使用します。 Databricksでは、ワークロード ID フェデレーションの デフォルト sub 要求を維持することをお勧めします。 別の主張を選択するのは、 sub が適切または安定したサブジェクト識別子でない場合のみであり、これはまれです。詳細については、「 サービスプリンシパル フェデレーション ポリシーの例」を参照してください。

  • トークン署名の検証: (オプション) トークン署名の検証に使用されるJSON Web Key Sets (JWKS) 形式の公開キーまたはその URL。 JWKS JSON は最大 5 個のキーをサポートします。アイデンティティプロバイダーがさらに公開する場合は、代わりに JWKS URI を使用します。

    指定されていない場合、Databricks は発行者の既知のエンドポイントからキーを取得します。これが推奨される方法です。ID プロバイダーは、トークン署名の検証に使用される公開キーの場所を指定するjwks_uriを含む OpenID プロバイダー メタデータを<issuer-url>/.well-known/openid-configurationで提供する必要があります。

  1. アカウント管理者として、 https://accounts.gcp.databricks.comで Databricks アカウント コンソールにサインインします。
  2. [ ユーザー管理 ] をクリックします。
  3. サービスプリンシパル タブに移動します。
  4. ポリシーを作成するサービスプリンシパルを選択します。
  5. [ 資格情報とシークレット ] タブに移動します。
  6. フェデレーション ポリシー タブで、 ポリシーの作成 をクリックします。
  7. フェデレーション資格情報プロバイダーを選択し、対応するフィールドを構成します。
  8. 「 ポリシーの作成 」をクリックします。

Databricks サービスプリンシパル フェデレーション ポリシーの例​

次の表に、サービスプリンシパル フェデレーション ポリシーと対応する JWT 本文の例を示します。

これらの一般的な ID プロバイダーの一部でワークロード ID フェデレーションを有効にするための完全な構成手順については、「 CI/CD でワークロード ID フェデレーションを有効にする」を参照してください。

ツール

フェデレーション ポリシー

一致するトークンの例

GitHub Actions

発行者： https://token.actions.githubusercontent.com
オーディエンス： https://github.com/<github-org>
サブジェクト： repo:<github-org>/<repo>:environment:prod

{
"iss": "https://token.actions.githubusercontent.com",
"aud": "https://github.com/<github-org>",
"sub": "repo:<github-org>/<repo>:environment:prod"
}

Kubernetes

発行者： https://kubernetes.default.svc
オーディエンス： https://kubernetes.default.svc
サブジェクト： system:serviceaccount:namespace:serviceaccountname
JWKS JSON: {"keys":[{"kty":"rsa","e":"AQAB","use":"sig","kid":"<key-id>","alg":"RS256","n":"uPUViFv..."}]}

{
"iss": "https://kubernetes.default.svc",
"aud": ["https://kubernetes.default.svc"],
"sub": "system:serviceaccount:namespace:serviceaccountname"
}

Azure DevOps

発行者： https://vstoken.dev.azure.com/<org_id>
オーディエンス： api://AzureADTokenExchange
サブジェクト： sc://my-org/my-project/my-connection

{
"iss": "https://vstoken.dev.azure.com/<org_id>",
"aud": "api://AzureADTokenExchange",
"sub": "sc://my-org/my-project/my-connection"
}

GitLab

発行者： https://gitlab.example.com
オーディエンス： https://gitlab.example.com
サブジェクト： project_path:my-group/my-project:...

{
"iss": "https://gitlab.example.com",
"aud": "https://gitlab.example.com",
"sub": "project_path:my-group/my-project:..."
}

CircleCI

発行者： https://oidc.circleci.com/org/<org_id>
オーディエンス： <org_id>
サブジェクト： 7cc1d11b-46c8-4eb2-9482-4c56a910c7ce
主題の主張: oidc.circleci.com/project-id

{
"iss": "https://oidc.circleci.com/org/<org_id>",
"aud": "<org_id>",
"oidc.circleci.com/project-id": "7cc1d11b-46c8-4eb2-9482-4c56a910c7ce"
}

AWS IAMアウトバウンドIDフェデレーション

発行者: https://<uuid>.tokens.sts.global.api.aws (アカウント固有の発行者 URL)
オーディエンス： databricks（またはGetWebIdentityTokenに渡される合意された値）
サブジェクト： arn:aws:iam::<account>:role/<role-name>

{
"iss": "https://<uuid>.tokens.sts.global.api.aws",
"aud": ["databricks"],
"sub": "arn:aws:iam::123456789012:role/my-workload-role"
}

ツール

フェデレーション ポリシー

一致するトークンの例

GitHub Actions

発行者： https://token.actions.githubusercontent.com
オーディエンス： https://github.com/<github-org>
サブジェクト： repo:<github-org>/<repo>:environment:prod

{
"iss": "https://token.actions.githubusercontent.com",
"aud": "https://github.com/<github-org>",
"sub": "repo:<github-org>/<repo>:environment:prod"
}

Kubernetes

発行者： https://kubernetes.default.svc
オーディエンス： https://kubernetes.default.svc
サブジェクト： system:serviceaccount:namespace:serviceaccountname
JWKS JSON: {"keys":[{"kty":"rsa","e":"AQAB","use":"sig","kid":"<key-id>","alg":"RS256","n":"uPUViFv..."}]}

{
"iss": "https://kubernetes.default.svc",
"aud": ["https://kubernetes.default.svc"],
"sub": "system:serviceaccount:namespace:serviceaccountname"
}

Azure DevOps

発行者： https://vstoken.dev.azure.com/<org_id>
オーディエンス： api://AzureADTokenExchange
サブジェクト： sc://my-org/my-project/my-connection

{
"iss": "https://vstoken.dev.azure.com/<org_id>",
"aud": "api://AzureADTokenExchange",
"sub": "sc://my-org/my-project/my-connection"
}

GitLab

発行者： https://gitlab.example.com
オーディエンス： https://gitlab.example.com
サブジェクト： project_path:my-group/my-project:...

{
"iss": "https://gitlab.example.com",
"aud": "https://gitlab.example.com",
"sub": "project_path:my-group/my-project:..."
}

CircleCI

発行者： https://oidc.circleci.com/org/<org_id>
オーディエンス： <org_id>
サブジェクト： 7cc1d11b-46c8-4eb2-9482-4c56a910c7ce
主題の主張: oidc.circleci.com/project-id

{
"iss": "https://oidc.circleci.com/org/<org_id>",
"aud": "<org_id>",
"oidc.circleci.com/project-id": "7cc1d11b-46c8-4eb2-9482-4c56a910c7ce"
}

AWS IAMアウトバウンドIDフェデレーション

発行者: https://<uuid>.tokens.sts.global.api.aws (アカウント固有の発行者 URL)
オーディエンス： databricks（またはGetWebIdentityTokenに渡される合意された値）
サブジェクト： arn:aws:iam::<account>:role/<role-name>

{
"iss": "https://<uuid>.tokens.sts.global.api.aws",
"aud": ["databricks"],
"sub": "arn:aws:iam::123456789012:role/my-workload-role"
}

注記

AWS IAMアウトバウンドIDフェデレーションでは、トークン内のsubクレームは、呼び出し元のワークロード（例：Lambda実行ロール、ECSタスクロール、またはEC2インスタンスロール）のIAMロールARNです。

サービスプリンシパルフェデレーションポリシーのベストプラクティス​

各サービスプリンシパルは、最大20個のフェデレーションポリシーをサポートします。その制限に達しないようにするには、以下のガイドラインに従ってください。

サービスプリンシパルごとに外部IDを1つマッピングします。​

外部ワークロードのIDごとに、専用のサービスプリンシパルを作成します。単一のサービスプリンシパルに対して複数のフェデレーションポリシーを適用することが適切なのは、同一の論理IDが異なるIDプロバイダーを通じて認証を行う場合に限られます。例えば、GitHub ActionsとAzure DevOpsの両方で実行されるワークロードの場合、同じサービスプリンシパル上に、プロバイダーごとに1つずつ、合計2つのポリシーが必要になります。

複数のポリシーを使用して、異なるワークロード（リージョンごとに個別のKubernetesポッドなど）を単一のサービスプリンシパルにマッピングしないでください。代わりに、ワークロードごとに個別のサービスプリンシパルを作成してください。これにより、監査ログの帰属情報が保持され、他のワークロードに影響を与えることなく、あるワークロードへのアクセス権を取り消すことができます。

グループを使用して権限管理を効率化​

複数のサービス プリンシパルに同じアクセス許可が必要な場合は、それらをDatabricksグループのメンバーとして追加し、そのグループにアクセス許可を割り当てます。 ID管理のベストプラクティスを参照してください。

代替クレームにはsubject_claimプロパティを使用してください​

デフォルトでは、Databricks は ID トークンのsubクレームを使用してワークロードを識別します。IDプロバイダーがsubクレームを安定したワークロード識別子として使用しない場合は、 subject_claimプロパティをプロバイダーが使用するクレーム名に設定してください。例については、 「サンプルDatabricksプリンシパル フェデレーション ポリシー」の CircleCI 構成を参照してください。 。

アカウント全体のトークンフェデレーション​

アカウント 管理者は OAuth アカウント フェデレーション ポリシーを使用して、 Databricks アカウントでトークン フェデレーションを構成できます。 アカウント federation ポリシー を使用すると、 Databricks アカウント内のすべてのユーザーとサービスプリンシパルが、ID プロバイダーからのトークンを使用して Databricks API にアクセスできます。 アカウント フェデレーション ポリシーでは、次のものを指定します。

  • Databricks がトークンを受け入れる ID プロバイダーまたは発行者。
  • トークンを対応する Databricks ユーザーまたはサービスプリンシパルにマッピングするための基準。

たとえば、次のフィールドを持つフェデレーションポリシーがあるとします。

  • 発行者： https://idp.mycompany.com/oidc
  • オーディエンス： databricks
  • 主題の主張: sub

この JWT 本文を使用して、次のように Databricks に認証しますusername@mycompany.com

JSON
{
  "iss": "https://idp.mycompany.com/oidc",
  "aud": "databricks",
  "sub": "username@mycompany.com"
}

アカウントフェデレーションポリシーを構成する​

アカウント 管理者は、 Databricks UI、 Databricks CLI 、または Databricks REST APIを使用してアカウントフェデレーションポリシーを構成できます。 Databricks アカウントでは、最大 20 個のアカウント フェデレーション ポリシーを指定できます。

アカウントフェデレーションポリシーを設定するには、以下を指定する必要があります。

  • 発行者URL: トークンの iss 要求で指定された ID プロバイダーを識別する HTTPS URL。

  • オーディエンス： aud 要求で指定されているトークンの意図された受信者。トークンは、その対象ユーザーがポリシー内の少なくとも 1 つの対象と一致する場合、一致と見なされます。指定しない場合、 デフォルト は あなたの Databricks アカウント IDです。

  • サブジェクトのクレーム: トークンが発行されたユーザーの Databricks ユーザー名を含むトークン要求。指定しない場合、デフォルトは subです。

  • トークン署名の検証: (オプション) トークン署名の検証に使用されるJSON Web Key Sets (JWKS) 形式の公開キーまたはその URL。 JWKS JSON は最大 5 個のキーをサポートします。アイデンティティプロバイダーがさらに公開する場合は、代わりに JWKS URI を使用します。

    指定されていない場合、Databricks は発行者の既知のエンドポイントからキーを取得します。これが推奨される方法です。ID プロバイダーは、トークン署名の検証に使用される公開キーの場所を指定するjwks_uriを含む OpenID プロバイダー メタデータを<issuer-url>/.well-known/openid-configurationで提供する必要があります。

重要

アカウント全体のフェデレーションの場合、 登録する フルマネージド 会社独自の IdP など、組織から信頼されています。 顧客やパートナーが管理するIdPなど、制御できない外部IdPとのアカウント全体のフェデレーションは構成しないでください。

  1. アカウント管理者として、 https://accounts.gcp.databricks.comで Databricks アカウント コンソールにサインインします。
  2. 「セキュリティ」 をクリックし、 「認証」 タブに移動します。
  3. [フェデレーション ポリシー] で、[ ポリシーの作成 ] をクリックします。
  4. 発行者の URL、対象ユーザー、サブジェクト要求、およびオプションのトークン署名検証を入力します。
  5. 「 ポリシーの作成 」をクリックします。

アカウントフェデレーションポリシーの例​

次の表に、アカウント フェデレーション ポリシーの例と、一致する JWT 本文を示します。

フェデレーション ポリシー

一致するトークンの例

発行者： https://idp.mycompany.com/oidc
オーディエンス： 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d

{
"iss": "https://idp.mycompany.com/oidc",
"aud": "2ff814a6-3304-4ab8-85cb-cd0e6f879c1d",
"sub": "username@mycompany.com"
}

発行者： https://idp.mycompany.com/oidc
オーディエンス： 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d
主題の主張: preferred_username

{
"iss": "https://idp.mycompany.com/oidc",
"aud": ["2ff814a6-3304-4ab8-85cb-cd0e6f879c1d", "other-audience"],
"preferred_username": "username@mycompany.com",
"sub": "some-other-ignored-value"
}

発行者： https://idp.mycompany.com/oidc
オーディエンス： 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d
JWKS JSON: {"keys":[{"kty":"RSA","e":"AQAB","use":"sig","kid":"<key-id>","alg":"RS256","n":"uPUViFv..."}]}

{
"iss": "https://idp.mycompany.com/oidc",
"aud": "2ff814a6-3304-4ab8-85cb-cd0e6f879c1d",
"sub": "username@mycompany.com"
}
(ポリシーの公開鍵を使用して署名が検証されます)

発行者： https://idp.mycompany.com/oidc
オーディエンス： 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d
JWKS URI: https://idp.mycompany.com/jwks.json

{
"iss": "https://idp.mycompany.com/oidc",
"aud": "2ff814a6-3304-4ab8-85cb-cd0e6f879c1d",
"sub": "username@mycompany.com"
}
(jwks_uriから取得した公開鍵を使用して署名が検証されました)

フェデレーション ポリシー

一致するトークンの例

発行者： https://idp.mycompany.com/oidc
オーディエンス： 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d

{
"iss": "https://idp.mycompany.com/oidc",
"aud": "2ff814a6-3304-4ab8-85cb-cd0e6f879c1d",
"sub": "username@mycompany.com"
}

発行者： https://idp.mycompany.com/oidc
オーディエンス： 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d
主題の主張: preferred_username

{
"iss": "https://idp.mycompany.com/oidc",
"aud": ["2ff814a6-3304-4ab8-85cb-cd0e6f879c1d", "other-audience"],
"preferred_username": "username@mycompany.com",
"sub": "some-other-ignored-value"
}

発行者： https://idp.mycompany.com/oidc
オーディエンス： 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d
JWKS JSON: {"keys":[{"kty":"RSA","e":"AQAB","use":"sig","kid":"<key-id>","alg":"RS256","n":"uPUViFv..."}]}

{
"iss": "https://idp.mycompany.com/oidc",
"aud": "2ff814a6-3304-4ab8-85cb-cd0e6f879c1d",
"sub": "username@mycompany.com"
}
(ポリシーの公開鍵を使用して署名が検証されます)

発行者： https://idp.mycompany.com/oidc
オーディエンス： 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d
JWKS URI: https://idp.mycompany.com/jwks.json

{
"iss": "https://idp.mycompany.com/oidc",
"aud": "2ff814a6-3304-4ab8-85cb-cd0e6f879c1d",
"sub": "username@mycompany.com"
}
(jwks_uriから取得した公開鍵を使用して署名が検証されました)

次のステップ​

アカウントのフェデレーションポリシーを設定した後、次の操作を行います。

  • ユーザーが Databricks と交換できるトークンを生成するように ID プロバイダー (IdP) を構成します。セットアップの詳細については、IdP のドキュメントを参照してください。一般的な IdP でワークロード ID フェデレーションを有効にする手順については、「 CI/CD でのワークロード ID フェデレーションの有効化」を参照してください。
  • IdP の JWT を使用して、最初に Databricks OAuth トークンと交換して Databricks API にアクセスします。API 呼び出しの Bearer: ヘッダーに Databricks OAuth トークンを含めて、要求を完了します。JWT は有効であり、RS256 または ES256 アルゴリズムを使用して署名されている必要があります。実装の詳細については、「 ID プロバイダートークンを使用した認証」を参照してください。
このページの見出し