Festlegen von Berechtigungen für Ressourcen in Databricks-Ressourcenpaketen

In diesem Artikel wird beschrieben, wie Berechtigungen für Ressourcen in Databricks Asset Bundles festgelegt werden. Informationen zu Ressourcen, die in Bundles unterstützt werden, finden Sie unter Databricks Asset Bundles-Ressourcen.

In Azure Databricks-Bündelkonfigurationsdateien können Sie Berechtigungen auf oberster Ebene definieren, um auf alle im Bundle definierten Ressourcen anzuwenden, oder Sie können Berechtigungen definieren, die für bestimmte Ressourcen gelten sollen.

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

Sie können Berechtigungen definieren, die auf alle unterstützten Ressourcen angewendet werden sollen, die in resources der Zuordnung der obersten Ebene permissions definiert sind. Databricks empfiehlt diesen Ansatz zum Verwalten von Ressourcenberechtigungen für Databricks Asset Bundles.

Berechtigungen definieren die zulässige Berechtigungsstufe für ein user_name, group_nameoder service_principal_name. Zulässige Berechtigungsstufen auf oberster Ebene sind CAN_VIEW, CAN_MANAGE und CAN_RUN. Weitere Informationen zur Zuordnung der obersten Ebene permissions finden Sie unter "Berechtigungen".

Im folgenden Beispiel werden Berechtigungen auf oberster Ebene für das dev Ziel festgelegt. Der Benutzer someone@example.com verfügt CAN_RUN über Berechtigungen für my-job:

bundle:
  name: my-bundle

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

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

Definieren von Berechtigungen für eine bestimmte Ressource

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

Jede Berechtigung in der permissions Zuordnung muss Folgendes enthalten:

• Entweder user_name, , group_nameoder service_principal_name, auf den Namen des Benutzers, der Gruppe oder des Dienstprinzipals festgelegt, bzw. auf den Dienstprinzipal.
• level, auf den Namen der Berechtigungsstufe festgelegt. Folgende Berechtigungsstufen sind für die einzelnen Ressourcen zulässig:
  • Warnungen: CAN_EDIT, , CAN_MANAGECAN_READCAN_RUN
  • Apps: CAN_MANAGE, CAN_USE
  • Cluster: CAN_ATTACH_TO, CAN_MANAGE, CAN_RESTART
  • Dashboards: CAN_EDIT, , CAN_MANAGE, CAN_VIEWCAN_READ
  • Datenbankinstanzen: CAN_MANAGE, CAN_USE, CAN_CREATE
  • Experimente: CAN_EDIT, CAN_MANAGE, CAN_READCAN_RUN
  • Jobs: CAN_MANAGE, CAN_MANAGE_RUN, CAN_VIEW, IS_OWNER
  • Modelle: CAN_EDIT, , CAN_MANAGECAN_MANAGE_STAGING_VERSIONS, , CAN_MANAGE_PRODUCTION_VERSIONSCAN_READ
  • Pipelines: CAN_MANAGE, CAN_RUN, CAN_VIEWIS_OWNER
  • Geheime Bereiche: READ, WRITEMANAGE
  • SQL Warehouse: CAN_MANAGE, CAN_USE, CAN_VIEW, CAN_MONITORIS_OWNER

Die folgende Syntax zeigt, wie Berechtigungen für einen Ressourcentyp (in diesem Beispiel Pipelines) in der Zuordnung der obersten Ebene resources und in einer Zuordnung innerhalb eines resources Ziels deklariert werden:

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

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. Gehen Sie z. B. von der folgenden resources-Zuordnung für dieselbe Ressource auf oberster Ebene und in einem Ziel aus:

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

Wenn Sie databricks bundle validate für dieses Beispiel ausführen, lautet das resultierende Diagramm wie folgt:

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

Berechtigungsreihenfolge

Wenn Sie an mehreren Stellen in ihrer Bundlekonfiguration definiert haben permissions , sind die Berechtigungen, die Ressourcen, Arbeitsbereichsverzeichnissen und im Bundle angegebenen Dateien zugewiesen wurden, in der folgenden Reihenfolge:

1. Die Berechtigungen, die in der Zielbereitstellung für die Ressource definiert sind
2. Die für die Zielbereitstellung definierten Berechtigungen
3. Die berechtigungen, die für die Ressource im Bundle definiert sind
4. Die Berechtigungen, die auf der obersten Ebene des Bundles definiert sind

Beispielsweise verfügt die Gruppe test-group in der folgenden Konfiguration über CAN_MANAGE Berechtigungen für den Auftrag im dev Ziel, aber über CAN_MANAGE_RUN Berechtigungen für den Auftrag im prod Ziel.

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