Udostępnij za pośrednictwem

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

  • Artykuł

W tym artykule opisano sposób ustawiania uprawnień dla zadań usługi Azure Databricks, potoków delta live tables i stosów MLOps w pakietach zasobów usługi Databricks. Zobacz Co to są pakiety zasobów usługi Databricks?.

W plikach konfiguracji pakietu usługi Azure Databricks można zdefiniować uprawnienia do zastosowania do wszystkich zasobów zdefiniowanych w pakiecie lub zdefiniować co najmniej jedno uprawnienie do zastosowania do określonych zasobów.

Uwaga

Uprawnienia nie mogą się nakładać. Innymi słowy, nie można zdefiniować uprawnień dla użytkownika, grupy lub jednostki usługi zarówno w mapowaniu najwyższego poziomu permissions , jak i w resources ramach mapowania.

Definiowanie uprawnień do zastosowania do wszystkich zasobów

Uprawnienia do stosowania do wszystkich eksperymentów, zadań, modeli i potoków zdefiniowanych w resources programie można zdefiniować przy użyciu mapowania najwyższego poziomu permissions . Zobacz uprawnienia.

Definiowanie uprawnień dla określonego zasobu

Tablicę można użyć w definicji eksperymentu permissions , zadania, modelu lub potoku, resources aby zdefiniować co najmniej jedno uprawnienie dla tego zasobu.

Każde uprawnienie w tablicy permissions musi zawierać następujące dwa mapowania:

  • Albo user_name, group_namelub service_principal_name, z nazwą użytkownika, grupy lub jednostki usługi, odpowiednio.
  • level, z nazwą poziomu uprawnień. Dozwolone poziomy uprawnień dla każdego zasobu są następujące:
    • Eksperymenty: CAN_EDIT, CAN_MANAGE i CAN_READ.
    • Zadania: CAN_MANAGE, , CAN_VIEWCAN_MANAGE_RUNi IS_OWNER.
    • Modele: CAN_EDIT, , CAN_MANAGE_STAGING_VERSIONSCAN_MANAGE, CAN_MANAGE_PRODUCTION_VERSIONSi CAN_READ.
    • Potoki: CAN_MANAGE, , CAN_VIEWCAN_RUNi IS_OWNER.

Aby uzyskać informacje o określonych poziomach uprawnień, zobacz:

Poniższa składnia pokazuje, jak zadeklarować wiele uprawnień dla każdego typu zasobu w mapowaniu najwyższego poziomu resources lub resources mapowanie w obiekcie docelowym (wielokropek wskazuje pominiętą zawartość dla zwięzłości):

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

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 resources mapowanie dla tego samego zasobu zarówno na najwyższym poziomie, jak i w obiekcie docelowym (wielokropek wskazuje pominiętą zawartość dla zwięzłości):

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

Po uruchomieniu databricks bundle validate tego przykładu wynikowy wykres jest następujący (wielokropek wskazuje pominiętą zawartość w celu zwięzłości):

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