Definir permissões para recurso em Databricks ativo Bundles

Este artigo descreve como definir permissões para recurso em Databricks ativo Bundles. Para obter informações sobre o recurso suportado em pacotes, consulte Databricks ativo Bundles recurso.

Nos arquivos de configuração do pacote Databricks, o senhor 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 usuário, grupo ou entidade de serviço não podem ser definidas no mapeamento de nível superior permissions e no mapeamento resources.

Definir permissões a serem aplicadas a todos os recursos

O senhor pode definir permissões a serem aplicadas a todos os recursos compatíveis definidos em resources usando o mapeamento de nível superior permissions. Databricks recomenda essa abordagem para gerenciar as permissões de recurso do Databricks ativo Bundles.

As permissões definem o nível de permissões permitido para user_name, group_name ou 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 superior permissions, consulte permissões.

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

YAML

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

O senhor pode usar o mapeamento permissions em um dashboard, experimento, trabalho, modelo ou definição pipeline em resources para definir uma ou mais permissões para esse recurso.

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

• user_name, group_name, ou service_principal_name, definido como o nome do usuário, grupo ou entidade de serviço, respectivamente.
• level, defina com o nome do nível de permissão. Os níveis de permissão permitidos para cada recurso são os seguintes:
  • Painéis: CAN_EDIT, CAN_MANAGE CAN_VIEW e CAN_READ.
  • Experimentos: 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.
  • pipeline: CAN_MANAGE, CAN_RUN, CAN_VIEW, e IS_OWNER.

important

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

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

YAML

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

YAML

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 resources de nível superior são combinadas com todas as permissões declaradas para o mesmo mapeamento resources em um destino individual. Por exemplo, dado o seguinte mapeamento resources para o mesmo recurso no nível superior e em um destino:

YAML

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 o senhor executa databricks bundle validate para este exemplo, o gráfico resultante é o seguinte:

JSON

{
  "...": "...",
  "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 o senhor tiver o endereço permissions definido em vários locais na configuração do pacote, as permissões concedidas ao recurso, aos diretórios workspace e aos arquivos especificados no pacote estarão na seguinte ordem:

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

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

YAML

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