Definir permissões para recursos no Databricks Asset Bundles

Este artigo descreve como definir permissões para trabalhos do Azure Databricks, pipelines Delta Live Tables e MLOps Stacks em Databricks Asset Bundles. Consulte O que são Databricks Asset Bundles?.

Nos arquivos de configuração do pacote do Azure Databricks, você pode definir permissões para aplicar a todos os recursos definidos no pacote ou pode definir uma ou mais permissões para aplicar a recursos específicos.

Definir permissões para aplicar a todos os recursos

Você pode definir permissões para aplicar a todos os experimentos, trabalhos, modelos e pipelines definidos usando resources o mapeamento de nível permissions superior. Consulte as permissões.

O Databricks recomenda essa abordagem para gerenciar permissões de recursos do Databricks Asset Bundles.

Definir permissões para um recurso específico

Você pode usar o mapeamento em uma definição de experimento permissions , trabalho, modelo ou pipeline para resources definir uma ou mais permissões para esse recurso.

Cada permissão no permissions mapeamento deve incluir os dois mapeamentos a seguir:

• Ou user_name, group_nameou , com service_principal_nameo nome do usuário, grupo ou entidade de serviço, respectivamente.
• level, com o nome do nível de permissão. Os níveis de permissão permitidos para cada recurso são os seguintes:
  • Experiências: CAN_EDIT, CAN_MANAGE e CAN_READ.
  • Empregos: CAN_MANAGE, CAN_MANAGE_RUN, CAN_VIEW, e IS_OWNER.
  • Modelos: CAN_EDIT, CAN_MANAGE, CAN_MANAGE_STAGING_VERSIONS, CAN_MANAGE_PRODUCTION_VERSIONS, e CAN_READ.
  • Condutas: CAN_MANAGE, CAN_RUN, CAN_VIEW, e IS_OWNER.

Para obter informações sobre níveis de permissão específicos, consulte:

• Experimentos: ACLs de experimento MLflow
• Empregos: ACLs de trabalho
• Modelos: ACLs do modelo MLflow
• Pipelines: ACLs de pipeline Delta Live Tables

A sintaxe a seguir mostra como declarar várias permissões para cada tipo de recurso, seja no mapeamento de nível resources superior ou em um resources mapeamento dentro de um destino (as reticências indicam conteúdo omitido, para brevidade):

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

Todas as permissões declaradas para um recurso no mapeamento de nível resources superior são combinadas com quaisquer permissões declaradas para esse mesmo resources mapeamento em um destino individual. Por exemplo, dado o seguinte resources mapeamento para o mesmo recurso no nível superior e em um destino (reticências indicam conteúdo omitido, para brevidade):

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 você executa databricks bundle validate este exemplo, o gráfico resultante é o seguinte (reticências indicam conteúdo omitido, para brevidade):

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