Machtigingen instellen voor resources in Databricks Asset Bundles

In dit artikel wordt beschreven hoe u machtigingen instelt voor resources in Databricks Asset Bundles. Zie Databricks Asset Bundles-resources voor informatie over resources die worden ondersteund in bundels.

In Azure Databricks-bundelconfiguratiebestanden kunt u machtigingen definiëren op het hoogste niveau om toe te passen op alle resources die in de bundel zijn gedefinieerd, of u kunt machtigingen definiëren die moeten worden toegepast op specifieke resources.

Machtigingen definiëren die moeten worden toegepast op alle resources

U kunt machtigingen definiëren die moeten worden toegepast op alle ondersteunde resources die zijn gedefinieerd in resources de toewijzing op het hoogste niveau permissions . Databricks raadt deze methode aan voor het beheren van resourcemachtigingen voor Databricks Asset Bundles.

Machtigingen definiëren het toegestane machtigingsniveau voor een user_name, group_nameof service_principal_name. Toegestane machtigingsniveaus op het hoogste niveau zijn CAN_VIEW, CAN_MANAGEen CAN_RUN. Zie permissions voor meer informatie over de toewijzing op het hoogste niveau.

In het volgende voorbeeld worden machtigingen op het hoogste niveau ingesteld voor het dev doel. De gebruiker someone@example.com heeft CAN_RUN machtigingen voor my-job:

bundle:
  name: my-bundle

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

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

Machtigingen definiëren voor een specifieke resource

U kunt de permissions toewijzing gebruiken in een dashboard, experiment, taak, model of pijplijndefinitie resources om een of meer machtigingen voor die resource te definiëren.

Elke machtiging in de permissions toewijzing moet het volgende bevatten:

• Stel user_namedeze group_nameservice_principal_namein op respectievelijk de naam van de gebruiker, groep of service-principal.
• level, ingesteld op de naam van het machtigingsniveau. Toegestane machtigingsniveaus voor elke resource zijn het volgende:
  • Waarschuwingen: CAN_EDIT, CAN_MANAGE, , CAN_READCAN_RUN
  • Apps: CAN_MANAGE, CAN_USE
  • Clusters: CAN_ATTACH_TO, CAN_MANAGECAN_RESTART
  • Dashboards: CAN_EDIT, CAN_MANAGE, , CAN_VIEWCAN_READ
  • Database-exemplaren: CAN_MANAGE, CAN_USE, CAN_CREATE
  • Experimenten: CAN_EDIT, CAN_MANAGE, , CAN_READCAN_RUN
  • Banen: CAN_MANAGE, CAN_MANAGE_RUN, CAN_VIEW, IS_OWNER
  • Modellen: CAN_EDIT, CAN_MANAGE, CAN_MANAGE_STAGING_VERSIONS, , CAN_MANAGE_PRODUCTION_VERSIONSCAN_READ
  • Pijplijnen: CAN_MANAGE, CAN_RUN, , CAN_VIEWIS_OWNER
  • Geheime bereiken: READ, WRITEMANAGE
  • SQL Warehouse: CAN_MANAGE, CAN_USE, CAN_VIEW, CAN_MONITORIS_OWNER

De volgende syntaxis laat zien hoe u machtigingen declareert voor een resourcetype (in dit voorbeeld pijplijnen) in de toewijzing op het hoogste niveau resources en in een resources toewijzing binnen een doel:

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

Machtigingen die zijn gedeclareerd voor een resource in de toewijzing op het hoogste niveau resources worden gecombineerd met de machtigingen die voor dezelfde resources toewijzing in een afzonderlijke target zijn gedeclareerd. Bijvoorbeeld, gegeven de volgende resources mapping voor dezelfde resource op zowel het hoogste niveau als in een doellocatie:

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

Wanneer u databricks bundle validate voor dit voorbeeld uitvoert, ziet de resulterende grafiek er als volgt uit:

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

Volgorde van prioriteit voor machtigingen

Als u op meerdere locaties in uw bundelconfiguratie hebt permissions gedefinieerd, bevinden de machtigingen die zijn verleend aan resources, werkruimtemappen en bestanden die in de bundel zijn opgegeven, zich in de volgende volgorde:

1. De machtigingen die zijn gedefinieerd voor de resource in de doelimplementatie
2. De machtigingen die zijn gedefinieerd voor de doelimplementatie
3. De toestemmingen die zijn gedefinieerd voor de resource in de bundel
4. De machtigingen die zijn gedefinieerd in de machtigingen op het hoogste niveau van de bundel

In de volgende configuratie heeft de groep test-group bijvoorbeeld CAN_MANAGE machtigingen voor de taak in het dev doel, maar CAN_MANAGE_RUN machtigingen voor de taak in het prod doel.

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