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

W tym artykule opisano, jak ustawić uprawnienia dla zadań w Azure Databricks, potoków DLT oraz stosów MLOps w pakietach zasobów Databricks Asset Bundles. 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 głównego elementu usługi zarówno w mapowaniu nadrzędnym permissions, jak i w mapowaniu resources.

Definiowanie uprawnień do zastosowania do wszystkich zasobów

Można zdefiniować uprawnienia do stosowania we wszystkich eksperymentach, zadaniach, modelach i potokach zdefiniowanych w resources przy użyciu mapowania najwyższego poziomu permissions. Zobacz uprawnienia.

Databricks rekomenduje takie podejście do zarządzania uprawnieniami zasobów Pakietów Zasobów Databricks.

Definiowanie uprawnień dla określonego zasobu

Można użyć mapowania permissions w definicji eksperymentu, zadania, modelu lub potoku resources, aby zdefiniować jedno lub więcej uprawnień dla tego zasobu.

Każda zgoda w permissions mapowaniu 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_MANAGE_RUNCAN_VIEWi IS_OWNER.
  • Modele: CAN_EDIT, CAN_MANAGE, CAN_MANAGE_STAGING_VERSIONS, CAN_MANAGE_PRODUCTION_VERSIONS i CAN_READ.
  • Potoki: CAN_MANAGE, CAN_RUN, CAN_VIEW i IS_OWNER.

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

• Eksperymenty: listy ACL eksperymentu MLflow
• Zadania: listy ACL zadań
• Modele: ACL modelu MLflow
• Potoki: listy ACL dla potoku DLT

Uwaga

Dozwolone poziomy uprawnień dla zasobów nie zawsze muszą być stosowane do zasobów przy użyciu mapowania najwyższego poziomu permissions. Aby uzyskać prawidłowe poziomy uprawnień dla permissions mapowania, zobacz uprawnienia.

Poniższa składnia pokazuje, jak zadeklarować wiele uprawnień dla każdego typu zasobu, w mapowaniu najwyższego poziomu resources lub w mapowaniu resources w obiekcie docelowym (wielokropki wskazują 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"
          }
        ],
        "...": "..."
      }
    }
  }
}