Databricks アセットバンドルのリソースに対するアクセス許可を設定する

この記事では、 Databricks アセット バンドルで Databricks ジョブ、Delta Live Tables パイプライン、MLOps スタックのアクセス許可を設定する方法について説明します。 「 Databricks アセット バンドルとは」を参照してください。

Databricks バンドル 構成ファイルでは、バンドルで定義されているすべてのリソースに適用するアクセス許可を定義することも、特定のリソースに適用する 1 つ以上のアクセス許可を定義することもできます。

注：

権限は重複できません。 つまり、ユーザー、グループ、またはサービスプリンシパルの権限は、最上位の permissions マッピングと resources マッピングの両方で定義できません。

すべてのリソースに適用するアクセス許可を定義する

最上位のpermissionsマッピングを使用して、resourcesで定義されているすべてのエクスペリメント、ジョブ、モデル、およびパイプラインに適用する権限を定義できます。「 アクセス許可」を参照してください。

Databricks では、Databricks Asset Bundles リソースのアクセス許可を管理するために、このアプローチをお勧めします。

特定のリソースに対するアクセス許可を定義する

resourcesのエクスペリメント、ジョブ、モデル、またはパイプライン定義でpermissionsマッピングを使用して、そのリソースに対する 1 つ以上の権限を定義できます。

permissionsマッピングの各権限には、次の 2 つのマッピングが含まれている必要があります。

• user_name、group_name、または service_principal_nameのいずれかに、それぞれユーザー、グループ、またはサービスプリンシパルの名前を指定します。

• levelをアクセス許可レベルの名前に置き換えます。 各リソースに許可されるアクセス許可レベルは次のとおりです。

  • エクスペリメント: CAN_EDIT, CAN_MANAGE and CAN_READ.

  • ジョブ: CAN_MANAGE、 CAN_MANAGE_RUN、 CAN_VIEW、および IS_OWNER。

  • モデル: CAN_EDIT、 CAN_MANAGE、 CAN_MANAGE_STAGING_VERSIONS、 CAN_MANAGE_PRODUCTION_VERSIONS、および CAN_READ。

  • パイプライン: CAN_MANAGE、 CAN_RUN、 CAN_VIEW、および IS_OWNER。

特定のアクセス許可レベルに関する情報については、以下を参照してください。

• 拡張機能: MLflow拡張機能 ACL

• ジョブ: ジョブ ACL

• モデル: MLflow モデル ACL

• パイプライン: Delta Live Tables パイプライン ACLs

注：

リソースに対して許可された権限レベルは、必ずしも最上位レベルのpermissionsマッピングを使用するリソースに適用できるとは限りません。 permissionsマッピングの有効な権限レベルについては、権限を参照してください。

次の構文は、最上位の resources マッピングまたはターゲット内の resources マッピングで、リソースの種類ごとに複数のアクセス許可を宣言する方法を示しています (省略記号は、簡潔にするために省略されたコンテンツを示します)。

# ...
resources:
  experiments:
    <some-programmatic-identifier-for-this-experiment>:
      # ...
      permissions:
        - user_name: <user-name> # Or:
          group_name: <group-name> # Or:
          service_principal_name: <service-principal-name>
          level: <permission-level>
      # ...
  jobs:
    <some-programmatic-identifier-for-this-job>:
      # ...
      permissions:
        - user_name: <user-name> # Or:
          group_name: <group-name> # Or:
          service_principal_name: <service-principal-name>
          level: <permission-level>
      # ...
  models:
    <some-programmatic-identifier-for-this-model>:
      # ...
      permissions:
        - user_name: <user-name> # Or:
          group_name: <group-name> # Or:
          service_principal_name: <service-principal-name>
          level: <permission-level>
      # ...
  pipelines:
    <some-programmatic-identifier-for-this-pipeline>:
      # ...
      permissions:
        - user_name: <user-name> # Or:
          group_name: <group-name-1> # Or:
          service_principal_name: <service-principal-name>
          level: <permission-level>
      # ...

targets:
  <some-programmatic-identifier-for-this-target>:
    resources:
      experiments:
        <some-programmatic-identifier-for-this-experiment>:
          # ...
          permissions:
            - user_name: <user-name> # Or:
              group_name: <group-name> # Or:
              service_principal_name: <service-principal-name>
              level: <permission-level>
          # ...
      jobs:
        <some-programmatic-identifier-for-this-job>:
          # ...
          permissions:
            - user_name: <user-name> # Or:
              group_name: <group-name> # Or:
              service_principal_name: <service-principal-name>
              level: <permission-level>
          # ...
      models:
        <some-programmatic-identifier-for-this-model>:
          # ...
          permissions:
            - user_name: <user-name> # Or:
              group_name: <group-name> # Or:
              service_principal_name: <service-principal-name>
              level: <permission-level>
          # ...
      pipelines:
        <some-programmatic-identifier-for-this-pipeline>:
          # ...
          permissions:
            - user_name: <user-name> # Or:
              group_name: <group-name> # Or:
              service_principal_name: <service-principal-name>
              level: <permission-level>
          # ...
    # ...

最上位の resources マッピングでリソースに対して宣言されているアクセス許可は、個々のターゲットで同じ resources マッピングに対して宣言されているアクセス許可と組み合わされます。 たとえば、最上位レベルとターゲットの両方で同じリソースに対して次の resources マッピングがあるとします (省略記号は、簡潔にするために省略されたコンテンツを示します)。

bundle:
  name: my-bundle

resources:
  jobs:
    my-job:
      # ...
      permissions:
        - user_name: someone@example.com
          level: CAN_VIEW
      # ...

targets:
  dev:
    # ...
    resources:
      jobs:
        my-job:
          # ...
          permissions:
            - user_name: someone@example.com
              level: CAN_RUN
          # ...

この例で databricks bundle validate を実行すると、結果のグラフは次のようになります (省略記号は、簡潔にするために省略された内容を示します)。

{
  "...": "...",
  "resources": {
    "jobs": {
      "my-job": {
        "permissions": [
          {
            "level": "CAN_VIEW",
            "user_name": "someone@example.com"
          },
          {
            "level": "CAN_RUN",
            "user_name": "someone@example.com"
          }
        ],
        "...": "..."
      }
    }
  }
}