Impostare le autorizzazioni per le risorse nei bundle di asset di Databricks

Questo articolo descrive come impostare le autorizzazioni per i processi di Azure Databricks, le pipeline delle tabelle live delta e gli stack MLOps nei bundle di asset di Databricks. Consultare Che cosa sono i Databricks Asset Bundle?.

Nei file di configurazione del bundle di Azure Databricks è possibile definire le autorizzazioni da applicare a tutte le risorse definite nel bundle oppure definire una o più autorizzazioni da applicare a risorse specifiche.

Definire le autorizzazioni da applicare a tutte le risorse

È possibile definire le autorizzazioni da applicare a tutti gli esperimenti, i processi, i modelli e le pipeline definiti in resources usando il mapping di primo livello permissions . Vedere autorizzazioni.

Databricks consiglia questo approccio per la gestione delle autorizzazioni delle risorse dei bundle di asset di Databricks.

Definire le autorizzazioni per una risorsa specifica

È possibile usare il permissions mapping in una definizione di esperimento, processo, modello o pipeline in resources per definire una o più autorizzazioni per tale risorsa.

Ogni autorizzazione nel permissions mapping deve includere i due mapping seguenti:

• Rispettivamente user_name, group_nameo service_principal_name, con il nome dell'utente, del gruppo o dell'entità servizio.
• level, con il nome del livello di autorizzazione. I livelli di autorizzazione consentiti per ogni risorsa sono i seguenti:
  • Esperimenti: CAN_EDITe CAN_MANAGE CAN_READ.
  • Processi: CAN_MANAGE, CAN_MANAGE_RUN, CAN_VIEWe IS_OWNER.
  • Modelli: CAN_EDIT, CAN_MANAGE, CAN_MANAGE_STAGING_VERSIONSCAN_MANAGE_PRODUCTION_VERSIONS, e CAN_READ.
  • Pipeline: CAN_MANAGE, CAN_RUN, CAN_VIEWe IS_OWNER.

Per informazioni sui livelli di autorizzazione specifici, vedere:

• Esperimenti: ACL dell'esperimento MLflow
• Processi: ACL di processo
• Modelli: ACL del modello MLflow
• Pipeline: ACL della pipeline di tabelle live delta

La sintassi seguente illustra come dichiarare più autorizzazioni per ogni tipo di risorsa, nel mapping di primo livello resources o in un resources mapping all'interno di una destinazione (i puntini di sospensione indicano il contenuto omesso, per brevità):

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

Tutte le autorizzazioni dichiarate per una risorsa nel mapping di primo livello resources vengono combinate con tutte le autorizzazioni dichiarate per lo stesso resources mapping in una singola destinazione. Ad esempio, dato il mapping seguente resources per la stessa risorsa sia al livello superiore che in una destinazione (i puntini di sospensione indicano il contenuto omesso, per brevità):

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

Quando si esegue databricks bundle validate per questo esempio, il grafico risultante è il seguente (i puntini di sospensione indicano il contenuto omesso, per brevità):

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