Ustawianie uprawnień dla zasobów w pakietach zasobów usługi Databricks

W tym artykule opisano sposób ustawiania uprawnień dla zasobów w pakietach zasobów usługi Databricks. Aby uzyskać informacje o zasobach obsługiwanych w pakietach, zobacz Zasoby pakietu zasobów usługi Databricks.

W plikach konfiguracji pakietu usługi Azure Databricks można zdefiniować uprawnienia na najwyższym poziomie, aby zastosować je do wszystkich zasobów zdefiniowanych w pakiecie lub zdefiniować uprawnienia do zastosowania do określonych zasobów.

Definiowanie uprawnień do zastosowania do wszystkich zasobów

Uprawnienia do zastosowania do wszystkich obsługiwanych zasobów zdefiniowanych w resources programie można zdefiniować przy użyciu mapowania najwyższego poziomu permissions . Databricks rekomenduje takie podejście do zarządzania uprawnieniami zasobów Pakietów Zasobów Databricks.

Uprawnienia definiują dozwolony poziom uprawnień dla elementu user_name, group_namelub service_principal_name. Dozwolone poziomy uprawnień najwyższego poziomu to CAN_VIEW, CAN_MANAGEi CAN_RUN. Aby uzyskać więcej informacji na temat mapowania najwyższego poziomu permissions , zobacz uprawnienia.

W poniższym przykładzie ustawiono uprawnienia najwyższego dev poziomu dla obiektu docelowego. Użytkownik someone@example.com będzie miał CAN_RUN uprawnienia do elementu my-job:

bundle:
  name: my-bundle

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

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

Definiowanie uprawnień dla określonego zasobu

Mapowanie można użyć permissions na pulpicie nawigacyjnym, eksperymencie, zadaniu, modelu lub definicji potoku, resources aby zdefiniować co najmniej jedno uprawnienie dla tego zasobu.

Każde uprawnienie w permissions mapowaniu musi zawierać następujące uprawnienia:

• Albo user_name, group_namelub service_principal_name, ustaw odpowiednio nazwę użytkownika, grupy lub jednostki usługi.
• level, ustaw wartość na nazwę poziomu uprawnień. Dozwolone poziomy uprawnień dla każdego zasobu są następujące:
  • Alerty: CAN_EDIT, CAN_MANAGE, CAN_READ, CAN_RUN
  • Aplikacje: CAN_MANAGE, CAN_USE
  • Klastry: CAN_ATTACH_TO, , CAN_MANAGECAN_RESTART
  • Panele kontrolne: CAN_EDIT, CAN_MANAGE, CAN_VIEW, CAN_READ
  • Wystąpienia bazy danych: CAN_MANAGE, CAN_USE, CAN_CREATE
  • Eksperymenty: CAN_EDIT, CAN_MANAGE, CAN_READ, CAN_RUN
  • Zadania: CAN_MANAGE, , CAN_MANAGE_RUN, CAN_VIEWIS_OWNER
  • Modele: CAN_EDIT, CAN_MANAGE, CAN_MANAGE_STAGING_VERSIONS, CAN_MANAGE_PRODUCTION_VERSIONS, CAN_READ
  • Potoki: CAN_MANAGE, CAN_RUN, CAN_VIEW, IS_OWNER
  • Zakresy tajne: READ, WRITE, MANAGE
  • SQL Warehouse: CAN_MANAGE, , CAN_USECAN_VIEW, , CAN_MONITORIS_OWNER

Poniższa składnia pokazuje, jak zadeklarować uprawnienia dla typu zasobu (w tym przykładzie potoki) w mapowaniu najwyższego poziomu resources i w resources mapowaniu w ramach elementu docelowego:

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

Wszystkie uprawnienia zadeklarowane dla zasobu w mapowaniu najwyższego poziomu resources są łączone ze wszystkimi uprawnieniami zadeklarowanymi dla tego samego resources mapowania w pojedynczym obiekcie docelowym. Na przykład biorąc pod uwagę następujące mapowanie resources dla tego samego zasobu zarówno na najwyższym poziomie, jak i w obiekcie docelowym:

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

Po uruchomieniu databricks bundle validate dla tego przykładu wynikowy wykres wygląda następująco:

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

Kolejność pierwszeństwa uprawnień

Jeśli zdefiniowano permissions w wielu miejscach w konfiguracji pakietu, uprawnienia przyznane zasobom, katalogom obszarów roboczych i plikom określonym w pakiecie są w następującej kolejności:

1. Uprawnienia zdefiniowane dla zasobu we wdrożeniu docelowym
2. Uprawnienia zdefiniowane dla wdrożenia docelowego
3. Uprawnienia zdefiniowane dla zasobu w pakiecie
4. Uprawnienia zdefiniowane w uprawnieniach najwyższego poziomu pakietu

Na przykład w następującej konfiguracji grupa test-group będzie miała CAN_MANAGE uprawnienia do zadania w dev obiekcie docelowym, ale CAN_MANAGE_RUN uprawnienia dla zadania w prod obiekcie docelowym:

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