Festlegen von Berechtigungen für Ressourcen in Databricks-Ressourcenpaketen

In diesem Artikel wird beschrieben, wie Sie Berechtigungen für Azure Databricks-Aufträge, Delta Live Tables-Pipelines und MLOps-Stapel in Databricks-Ressourcenpaketen festlegen. Weitere Informationen finden Sie unter Was sind Databricks-Ressourcenpakete?.

In Paketkonfigurationsdateien von Azure Databricks können Sie Berechtigungen definieren, die für alle im Paket definierten Ressourcen gelten sollen. Oder Sie können eine oder mehrere Berechtigungen definieren, die für bestimmte Ressourcen gelten sollen.

Hinweis

Berechtigungen dürfen sich nicht überlappen. Mit anderen Worten: Berechtigungen für einen Benutzer/eine Benutzerin, eine Gruppe oder einen Dienstprinzipal können nicht sowohl in der permissions-Zuordnung der obersten Ebene als auch innerhalb der resources-Zuordnung definiert werden.

Definieren von Berechtigungen, die für alle Ressourcen gelten sollen

Sie können Berechtigungen definieren, die für alle Experimente, Aufträge, Modelle und Pipelines gelten sollen, die in resources mithilfe der permissions-Zuordnung auf oberster Ebene definiert werden. Weitere Informationen finden Sie unter Berechtigungen.

Databricks empfiehlt diesen Ansatz zum Verwalten von Ressourcenberechtigungen für Databricks Asset Bundles.

Definieren von Berechtigungen für eine bestimmte Ressource

Sie können die permissions-Zuordnung in einer Experiment-, Auftrags-, Modell- oder Pipelinedefinition in resources verwenden, um eine oder mehrere Berechtigungen für diese Ressource zu definieren.

Alle Berechtigungen in der permissions-Zuordnung müssen die folgenden beiden Zuordnungen enthalten:

• Entweder user_name, group_name oder service_principal_name mit dem Namen des Benutzers, der Gruppe oder des Dienstprinzipals.
• level mit dem Namen der Berechtigungsstufe. Folgende Berechtigungsstufen sind für die einzelnen Ressourcen zulässig:
  • Experimente: CAN_EDIT, CAN_MANAGE und CAN_READ.
  • Aufträge: CAN_MANAGE, CAN_MANAGE_RUN, CAN_VIEW und IS_OWNER.
  • Modelle: CAN_EDIT, CAN_MANAGE, CAN_MANAGE_STAGING_VERSIONS, CAN_MANAGE_PRODUCTION_VERSIONS und CAN_READ.
  • Pipelines: CAN_MANAGE, CAN_RUN, CAN_VIEW und IS_OWNER.

Informationen zu bestimmten Berechtigungsstufen finden Sie unter:

• Experimente: Zugriffssteuerungslisten für MLflow-Experimente
• Aufträge: Auftrags-ACLs
• Modelle: Zugriffssteuerungslisten für MLflow-Modelle
• Pipelines: Delta Live Tables pipeline ACLs

Hinweis

Zulässige Berechtigungsstufen für Ressourcen können nicht unbedingt auf Ressourcen angewendet werden, die die permissions-Zuordnung auf oberster Ebene nutzen. Gültige Berechtigungsstufen für die permissions-Zuordnung finden Sie unter Berechtigungen.

Die folgende Syntax zeigt, wie sie mehrere Berechtigungen pro Ressourcentyp deklarieren, entweder in der resources-Zuordnung auf oberster Ebene oder einer resources-Zuordnung innerhalb eines Ziels (Auslassungspunkte geben ausgelassenen Inhalt aus Platzgründen an):

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

Alle Berechtigungen, die für eine Ressource in der resources-Zuordnung auf oberster Ebene deklariert sind, werden mit allen Berechtigungen kombiniert, die für dieselbe resources-Zuordnung in einem einzelnen Ziel deklariert sind. Sehen Sie sich als Beispiel die folgende resources-Zuordnung für dieselbe Ressource auf oberster Ebene und in einem Ziel an (Auslassungspunkte geben ausgelassenen Inhalt aus Platzgründen an):

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

Wenn Sie für dieses Beispiel databricks bundle validate ausführen, sieht der resultierende Graph wie folgt aus (Auslassungspunkte weisen auf Inhalte hin, die der Übersichtlichkeit halber weggelassen wurden):

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