Definir permissões para recurso em Databricks ativo Bundles

Este artigo descreve como definir permissões para Databricks Job, Delta Live Tables pipeline e MLOps Stacks em Databricks ativo Bundles. Consulte O que são pacotes Databricks ativos?.

Nos arquivos de configuração do pacote do 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 um recurso específico.

Observação

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 permissions de nível superior e no mapeamento resources .

Definir permissões para aplicar a todos os recursos

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

Databricks recomenda essa abordagem para gerenciar as permissões de recurso do Databricks ativo Bundles.

Definir permissões para um recurso específico

O senhor pode usar o mapeamento permissions em um experimento, Job, 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 os dois mapeamentos a seguir:

  • Ou user_name, group_name ou 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_VERSIONS e CAN_READ.

    • pipeline: CAN_MANAGE, CAN_RUN, CAN_VIEW e IS_OWNER.

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

Observação

Os níveis de permissão permitidos para recurso não podem necessariamente ser aplicados a recurso usando 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 diversas permissões para cada tipo de recurso, no mapeamento resources de nível superior ou em um mapeamento resources dentro de um destino (reticências indicam conteúdo omitido, por questões 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>
          # ...
    # ...

Quaisquer permissões declaradas para um recurso no mapeamento resources de nível superior são combinadas com quaisquer permissões declaradas para esse 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 (as reticências indicam conteúdo omitido, por questões de 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 este exemplo, o gráfico resultante é o seguinte (as reticências indicam o conteúdo omitido, por questões de brevidade):

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