次の方法で共有

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

この記事では、Databricks アセット バンドルでリソースのアクセス許可を設定する方法について説明します。 バンドルでサポートされているリソースの詳細については、「 Databricks Asset Bundles リソース」を参照してください。

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

注

重複するアクセス許可は指定できません。 つまり、ユーザー、グループ、またはサービス プリンシパルに対するアクセス許可を、最上位の permissions マッピングと resources マッピングの両方で定義することはできません。

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

最上位レベルのresources マッピングを使用して、permissionsで定義されているすべてのサポートされているリソースに適用するアクセス許可を定義できます。 Databricks では、Databricks アセット バンドルのリソースのアクセス許可を、この方法で管理することをお勧めします。

アクセス許可は、 user_name、 group_name、または service_principal_nameに許可されるアクセス許可レベルを定義します。 指定できる最上位のアクセス許可レベルは、CAN_VIEW、CAN_MANAGE、CAN_RUN です。 最上位レベルの permissions マッピングの詳細については、 アクセス許可を参照してください。

次の例では、 dev ターゲットの最上位レベルのアクセス許可を設定します。 ユーザー someone@example.comには、CAN_RUNに対するmy-jobアクセス許可があります。

bundle:
  name: my-bundle

resources:
  jobs:
    my-job:
      # ...

targets:
  dev:
    # ...
    permissions:
      - user_name: someone@example.com
        level: CAN_RUN

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

permissionsのダッシュボード、実験、ジョブ、モデル、またはパイプライン定義のresourcesマッピングを使用して、そのリソースに対する 1 つ以上のアクセス許可を定義できます。

permissions マッピングの各アクセス許可には、次のものが含まれている必要があります。

  • user_name、group_name、またはservice_principal_nameのいずれかを、それぞれユーザー、グループ、またはサービス プリンシパルの名前に設定します。
  • levelをクリックして、アクセス許可レベルの名前に設定します。 各リソースで使用できるアクセス許可レベルは次のとおりです。

Important

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

次の構文は、最上位レベルの resources マッピングとターゲット内の resources マッピングで、リソースの種類 (この例ではパイプライン) のアクセス許可を宣言する方法を示しています。

# ...
resources:
  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:
      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:
        - group_name: test-group
          level: CAN_VIEW
      # ...

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

この例の databricks bundle validate を実行すると、結果のグラフは次のようになります。

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

アクセス許可の優先順位の順序

バンドル構成の複数の場所で permissions 定義されている場合、バンドルで指定されたリソース、ワークスペース ディレクトリ、およびファイルに付与されるアクセス許可は次の順序になります。

  1. ターゲット デプロイ内のリソースに対して定義されたアクセス許可
  2. ターゲットデプロイに対して定義されたアクセス許可
  3. バンドル内のリソースに対して定義されたアクセス許可
  4. バンドルの最上位レベルのアクセス許可で定義されているアクセス許可

たとえば、次の構成では、グループ test-groupにはCAN_MANAGE ターゲット内のジョブに対するdevアクセス許可がありますが、CAN_MANAGE_RUN ターゲット内のジョブに対するprodアクセス許可があります。

bundle:
  name: my-bundle

permissions:
  - group_name: test-group
    level: CAN_VIEW

resources:
  jobs:
    my-job:
      # ...
      permissions:
        - group_name: test-group
          level: CAN_MANAGE_RUN
      # ...

targets:
  dev:
    # ...
    resources:
      jobs:
        my-job:
          # ...
          permissions:
            - group_name: test-group
              level: CAN_MANAGE
          # ...
  prod:
    # ...
    resources:
      jobs:
        my-job:
          # ...
  • Last updated on