Partilhar via

Definir permissões para recursos no Databricks Asset Bundles

Este artigo descreve como definir permissões para recursos em Databricks Asset Bundles. Para obter informações sobre recursos suportados em pacotes, consulte Recursos do Databricks Asset Bundles.

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 pode definir 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 utilizador, grupo ou entidade de serviço não podem ser definidas tanto no mapeamento ao nível permissions superior como dentro do mapeamento resources.

Definir permissões para aplicar a todos os recursos

Você pode definir permissões para aplicar a todos os recursos suportados definidos em resources usando o mapeamento superior de nível permissions. O Databricks recomenda essa abordagem para gerenciar permissões de recursos do Databricks Asset Bundles.

As permissões definem o nível de permissões permitido para um user_name, group_name, ou service_principal_name. Os níveis de permissão de nível superior permitidos são CAN_VIEW, CAN_MANAGEe 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 na definição de pipeline em resources para definir uma ou mais permissões para esse recurso.

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

  • Ou user_name, group_nameou service_principal_name, definido como o 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:

Importante

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

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 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 mapeamento resources para o mesmo recurso, tanto ao nível superior como em um destino específico:

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 gráfico 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 das 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 espaço de trabalho e arquivos especificados no pacote estarão na seguinte ordem:

  1. As permissões definidas para o recurso na implementação desejada
  2. As permissões definidas para a implantação destinada
  3. As permissões definidas para o recurso no pacote
  4. As permissões de nível superior definidas no pacote

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

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:
          # ...
  • Last updated on