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.

Nota

As permissões não podem se sobrepor. Em outras palavras, as permissões para um usuário, grupo ou entidade de serviço não podem ser definidas no mapeamento de nível permissions superior e dentro do resources mapeamento.

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.

Definir permissões para um recurso específico

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

Cada permissão na permissions matriz 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 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"
          }
        ],
        "...": "..."
      }
    }
  }
}