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.

Definir permissões para um recurso específico

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

Cada permissão na matriz 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:

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"
          }
        ],
        "...": "..."
      }
    }
  }
}