Partilhar via


Definir permissões para recursos no Databricks Asset Bundles

Este artigo descreve como definir permissões para trabalhos do Azure Databricks, pipelines de DLT e pilhas de MLOps no Databricks Asset Bundles. Consulte O que são Databricks Asset Bundles?.

Nos arquivos de configuração do pacote do Azure 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 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 a serem atribuídas a todos os experimentos, trabalhos, modelos e pipelines definidos em resources usando o mapeamento de nível superior permissions. Consulte as permissões.

O Databricks recomenda essa abordagem para gerenciar permissões de recursos do Databricks Asset Bundles.

Definir permissões para um recurso específico

Você pode usar o mapeamento permissions em uma definição de experimento, trabalho, modelo ou 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 utilizador, 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:
    • Experiências: 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.
    • Condutas: CAN_MANAGE, CAN_RUN, CAN_VIEW, e IS_OWNER.

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

Nota

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 os níveis de permissão válidos para o permissions mapeamento, consulte permissões.

A sintaxe a seguir mostra como declarar várias permissões para cada tipo de recurso, seja no mapeamento de nível resources superior ou em um resources mapeamento dentro de um destino (as reticências indicam conteúdo omitido, para 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>
          # ...
    # ...

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 resources mapeamento para o mesmo recurso tanto ao nível superior como num alvo (reticências indicam conteúdo omitido, para 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
          # ...

Ao executar databricks bundle validate para este exemplo, o gráfico resultante é o seguinte (reticências indicam conteúdo omitido, para brevidade):

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