Definir permissões de recursos nos Pacotes de Ativos do Databricks

Este artigo descreve como definir permissões de trabalhos do Azure Databricks, pipelines do Delta Live Tables e pilhas do MLOps nos Pacotes de Ativos do Databricks. Confira O que são Pacotes de Ativos do Databricks?.

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

Observação

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

Defina as permissões a serem aplicadas a todos os recursos

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

O Databricks recomenda essa abordagem para gerenciar permissões de recursos de pacotes de ativos do Databricks.

Definir permissões para um recurso específico

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

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

• Tanto user_name, group_namequanto service_principal_name, com o 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:
  • Experimentos: CAN_EDIT, CAN_MANAGE e CAN_READ.
  • Trabalhos: CAN_MANAGE, CAN_MANAGE_RUN, CAN_VIEW e IS_OWNER.
  • Modelos: CAN_EDIT, CAN_MANAGE, CAN_MANAGE_STAGING_VERSIONS, CAN_MANAGE_PRODUCTION_VERSIONSe CAN_READ.
  • Pipelines: CAN_MANAGE, CAN_RUN, CAN_VIEWe IS_OWNER.

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

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

Observação

Os níveis de permissão permitidos para recursos não podem necessariamente ser aplicados a recursos que usam o mapeamento permissions de nível superior. Para obter os níveis de permissão válidos para o mapeamento permissions, consulte permissões.

A sintaxe a seguir mostra como declarar várias permissões para cada tipo de recurso, seja no mapeamento de nível superior resources ou em um mapeamento resources dentro de um destino (reticências indicam conteúdo omitido, para fins de 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 em um recurso no mapeamento de nível superior resources são combinadas com quaisquer permissões declaradas nesse mesmo mapeamento resources em um destino individual. Por exemplo, dado o mapeamento a seguir resources para o mesmo recurso no nível superior e em um destino (reticências indicam conteúdo omitido, por 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 para esse exemplo, o gráfico resultante é o seguinte (as elipses indicam conteúdo omitido, para fins de brevidade):

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