Nastavit oprávnění pro prostředky v automatizačních deklarativních balíčcích

Tento článek popisuje, jak konfigurovat oprávnění pro prostředky v deklarativních balíčcích automatizace. Pro informace o prostředcích podporovaných v balíčcích naleznete Prostředky pro deklarativní automatizační balíčky.

V konfiguračních souborech Azure Databricks bundle můžete definovat oprávnění na nejvyšší úrovni, která se použijí pro všechny prostředky definované v sadě prostředků, 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ě resources můžete definovat oprávnění, která se mají použít pro všechny podporované prostředky definované v permissions. Databricks doporučuje tento přístup ke správě oprávnění prostředků deklarativní automatizace.

Oprávnění určují povolenou úroveň přístupu pro user_name, group_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í na 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í permissions můžete použít v řídicím panelu, experimentu, úloze, modelu nebo definici datového potrubí resources k určení 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_RUN, CAN_READ*
    • Databázové instance: CAN_MANAGE, CAN_USECAN_CREATE
    • Agenti Genie: CAN_EDIT, CAN_MANAGE, CAN_RUN, CAN_VIEW
    • 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

* Uživatelské rozhraní pracovního prostoru odkazuje na přístup jen pro zobrazení jako CAN VIEW, zatímco rozhraní API oprávnění používá funkci CAN READ k reprezentaci stejné úrovně přístupu.

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:
          # ...
  • Last updated on