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

Este artigo descreve como definir permissões para recursos em Pacotes de Ativos do Databricks. Para obter informações sobre os recursos com suporte em pacotes, consulte os recursos de Pacotes de Ativos do Databricks.

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

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

Você pode definir permissões para aplicar a todos os recursos com suporte definidos no resources uso do mapeamento de nível permissions superior. O Databricks recomenda essa abordagem para gerenciar permissões de recursos de pacotes de ativos do Databricks.

As permissões definem o nível de permissões permitido para um user_name, group_nameou service_principal_name. Os níveis de permissão de nível superior permitidos são CAN_VIEW, CAN_MANAGE e CAN_RUN. Para obter mais informações sobre o mapeamento de nível permissions superior, consulte permissões.

O exemplo a seguir define permissões de nível superior para o dev destino. O usuário someone@example.com terá CAN_RUN permissões em my-job:

bundle:
  name: my-bundle

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

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

Definir permissões para um recurso específico

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

Cada permissão no permissions mapeamento deve incluir o seguinte:

• user_name group_nameDefina service_principal_nameo nome do usuário, grupo ou entidade de serviço, respectivamente.
• level, definido como o nome do nível de permissão. Os níveis de permissão permitidos para cada recurso são os seguintes:
  • Alertas: CAN_EDIT, , CAN_MANAGE, CAN_READCAN_RUN
  • Aplicativos: CAN_MANAGE, CAN_USE
  • Clusters: CAN_ATTACH_TO, CAN_MANAGE, CAN_RESTART
  • Painéis: CAN_EDIT, CAN_MANAGE, CAN_VIEW, CAN_READ
  • Instâncias de banco de dados: CAN_MANAGE, , CAN_USECAN_CREATE
  • Experimentos: CAN_EDIT, , CAN_MANAGE, CAN_READCAN_RUN
  • Trabalhos: CAN_MANAGE, , CAN_MANAGE_RUN, CAN_VIEWIS_OWNER
  • Modelos: CAN_EDIT, CAN_MANAGE, , CAN_MANAGE_STAGING_VERSIONS, CAN_MANAGE_PRODUCTION_VERSIONSCAN_READ
  • Pipelines: CAN_MANAGE, , CAN_RUN, CAN_VIEWIS_OWNER
  • Escopos secretos: READ, WRITEMANAGE
  • SQL Warehouse: CAN_MANAGE, , CAN_USE, CAN_VIEW, CAN_MONITOR, IS_OWNER

A sintaxe a seguir mostra como declarar permissões para um tipo de recurso (neste exemplo, pipelines) no mapeamento de nível resources superior e em um resources mapeamento dentro de um destino:

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

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, considerando o seguinte mapeamento resources para o mesmo recurso no nível superior e em um destino:

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

Quando você executa databricks bundle validate para este exemplo, o grafo resultante é o seguinte:

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

Ordem de precedência de permissões

Se você tiver permissions definido em vários locais na configuração do pacote, as permissões concedidas a recursos, diretórios de workspace e arquivos especificados no pacote estão na seguinte ordem:

1. As permissões definidas para o recurso na configuração de destino
2. As permissões definidas para a implantação alvo
3. As permissões definidas para o recurso no pacote
4. As permissões definidas na hierarquia de permissões de nível superior do pacote

Por exemplo, na configuração a seguir, o grupo test-group terá CAN_MANAGE permissões para o trabalho no dev destino, mas CAN_MANAGE_RUN permissões para o trabalho no prod destino:

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