Nastavte oprávnění pro prostředky v Databricks Asset Bundles

Tento článek popisuje, jak nastavit oprávnění pro prostředky v sadě prostředků Databricks. Informace oprostředcích

V konfiguračních souborech sady Azure Databricks můžete definovat oprávnění na nejvyšší úrovni, která se mají použít pro všechny prostředky definované v sadě, nebo můžete definovat oprávnění, která se mají použít pro konkrétní prostředky.

Poznámka:

Oprávnění se nesmí překrývat. Jinými slovy, oprávnění pro uživatele, skupinu nebo služební objekt nelze definovat v mapování nejvyšší úrovně permissions i v rámci resources mapování.

Definování oprávnění, která se mají použít pro všechny prostředky

Pomocí mapování nejvyšší úrovně můžete definovat oprávnění, která se mají použít pro všechny podporované prostředky definované v resources mapování nejvyšší úrovně permissions . Databricks doporučuje tento přístup ke správě oprávnění Sady prostředků Databricks.

Oprávnění definují povolenou úroveň oprávnění pro úroveň user_namegroup_name, nebo service_principal_name. Povolené úrovně oprávnění nejvyšší úrovně jsou CAN_VIEW, CAN_MANAGEa CAN_RUN. Další informace o mapování nejvyšší úrovně permissions najdete v tématu oprávnění.

Následující příklad nastaví oprávnění nejvyšší úrovně pro dev cíl. Uživatel someone@example.com bude mít CAN_RUN oprávnění:my-job

bundle:
  name: my-bundle

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

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

Definování oprávnění pro konkrétní prostředek

Mapování můžete použít permissions v řídicím panelu, experimentu, úloze, modelu nebo definici resources kanálu k definování jednoho nebo více oprávnění pro daný prostředek.

Každé oprávnění v permissions mapování musí obsahovat následující:

• Buď user_name, group_namenebo service_principal_name, nastavte na jméno uživatele, skupiny nebo instanční objekt, v uvedeném pořadí.
• level, nastavte na název úrovně oprávnění. Povolené úrovně oprávnění pro každý prostředek jsou následující:
  • Výstrahy: CAN_EDIT, CAN_MANAGE, CAN_READ, CAN_RUN
  • Aplikace: CAN_MANAGE, CAN_USE
  • Klastery: CAN_ATTACH_TO, CAN_MANAGE, CAN_RESTART
  • Řídicí panely: CAN_EDIT, CAN_MANAGE, CAN_VIEW, CAN_READ
  • Databázové instance: CAN_MANAGE, CAN_USECAN_CREATE
  • Experimenty: CAN_EDIT, CAN_MANAGE, CAN_READCAN_RUN
  • Úlohy: CAN_MANAGE, CAN_MANAGE_RUN, CAN_VIEW, IS_OWNER
  • Modely: CAN_EDIT, CAN_MANAGE, CAN_MANAGE_STAGING_VERSIONS, CAN_MANAGE_PRODUCTION_VERSIONS, CAN_READ
  • Kanály: CAN_MANAGE, CAN_RUN, CAN_VIEWIS_OWNER
  • Tajné obory: READ, WRITEMANAGE
  • SQL Warehouse: CAN_MANAGE, CAN_USE, CAN_VIEW, CAN_MONITORIS_OWNER

Důležité

Povolené úrovně oprávnění pro prostředky nemusí být nutně použitelné u prostředků pomocí mapování nejvyšší úrovně permissions. Platné úrovně oprávnění pro mapování nejvyšší úrovně permissions najdete v tématu Oprávnění.

Následující syntaxe ukazuje, jak deklarovat oprávnění pro typ prostředku (v tomto příkladu kanály) v mapování nejvyšší úrovně resources a v resources mapování v rámci cíle:

# ...
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>
          # ...
    # ...

Všechna oprávnění deklarovaná pro zdroj v mapování nejvyšší úrovně resources se zkombinují se všemi oprávněními, která jsou deklarována pro stejné resources mapování v cílovém místě. Například při zohlednění následujícího mapování resources pro stejný prostředek na nejvyšší úrovni i v cílové úrovni:

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
          # ...

Při spuštění databricks bundle validate v tomto příkladu je výsledný graf následující:

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

Pořadí oprávnění podle priority

Pokud jste v konfiguraci balíčku definovali permissions na několika místech, oprávnění udělená prostředkům, adresářům pracovních prostorů a souborům zadaným v balíčku jsou v tomto pořadí:

1. Oprávnění definovaná pro prostředek v cílovém nasazení
2. Oprávnění definovaná pro cílové nasazení
3. Oprávnění definovaná pro prostředek v sadě
4. Oprávnění definovaná v oprávněních nejvyšší úrovně sady

Například v následující konfiguraci bude mít skupina test-groupCAN_MANAGE oprávnění pro úlohu ve dev cíli, ale CAN_MANAGE_RUN oprávnění pro úlohu ve prod cíli.

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:
          # ...