Establecimiento de permisos para recursos en conjuntos de recursos de Databricks

En este artículo se describe cómo establecer permisos para los recursos de Databricks Asset Bundles. Para obtener información sobre los recursos admitidos en paquetes, consulte Recursos de paquetes de activos de Databricks.

En los archivos de configuración de agrupación de Azure Databricks, puede definir permisos en el nivel superior para aplicarlos a todos los recursos definidos en la agrupación, o bien puede definir permisos para aplicarlos a recursos específicos.

Definición de permisos para aplicarlos a todos los recursos

Puede definir permisos para aplicar a todos los recursos admitidos definidos en resources mediante la asignación de nivel permissions superior. Databricks recomienda este enfoque para administrar los permisos de recursos de Databricks Asset Bundles.

Los permisos definen el nivel de permisos permitido para un user_name, group_nameo service_principal_name. Los niveles de permisos de nivel superior permitidos son CAN_VIEW, CAN_MANAGE y CAN_RUN. Para obtener más información sobre el mapeo de nivel superior permissions, consulte permisos.

En el ejemplo siguiente se establecen los permisos de nivel superior para el dev destino. El usuario someone@example.com tendrá CAN_RUN permisos en my-job:

bundle:
  name: my-bundle

resources:
  jobs:
    my-job:
      # ...

targets:
  dev:
    # ...
    permissions:
      - user_name: someone@example.com
        level: CAN_RUN

Definición de permisos para un recurso específico

Puede usar la permissions asignación en un panel, experimento, trabajo, modelo o definición de pipeline en resources para definir uno o varios permisos para ese recurso.

Cada permiso en el permissions mapeo debe incluir lo siguiente:

• O user_name, group_name, o service_principal_name, se establece como el nombre del usuario, grupo o principal de servicio, respectivamente.
• level, se configura como el nombre del nivel de permiso. Los niveles de permisos permitidos para cada recurso son los siguientes:
  • Alertas: CAN_EDIT, CAN_MANAGE, CAN_READ, CAN_RUN
  • Aplicaciones: CAN_MANAGE, CAN_USE
  • Clústeres: CAN_ATTACH_TO, CAN_MANAGE, CAN_RESTART
  • Paneles: CAN_EDIT, CAN_MANAGE, CAN_VIEW, CAN_READ
  • Instancias de base de datos: CAN_MANAGE, CAN_USE, CAN_CREATE
  • Experimentos: CAN_EDIT, CAN_MANAGE, CAN_READ, CAN_RUN
  • Trabajos: CAN_MANAGE, CAN_MANAGE_RUN, CAN_VIEW, , IS_OWNER
  • Modelos: CAN_EDIT, CAN_MANAGE, CAN_MANAGE_STAGING_VERSIONS, , CAN_MANAGE_PRODUCTION_VERSIONS, CAN_READ
  • Canalizaciones: CAN_MANAGE, CAN_RUN, CAN_VIEW, IS_OWNER
  • Ámbitos secretos: READ, WRITE, MANAGE
  • SQL Warehouse: CAN_MANAGE, CAN_USE, CAN_VIEW, , CAN_MONITOR, IS_OWNER

La sintaxis siguiente muestra cómo declarar permisos para un tipo de recurso (en este ejemplo, canalizaciones) en la asignación de nivel superior resources y en una asignación resources dentro de un objetivo.

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

Cualquier permiso que se declare para un recurso en la asignación de resources de nivel superior se combina con cualquier permiso que se declare para esa misma asignación de resources en un destino individual. Por ejemplo, dada la siguiente asignación de resources para el mismo recurso en el nivel superior y en un destino:

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

Al ejecutar databricks bundle validate para este ejemplo, el gráfico resultante es el siguiente:

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

Orden de precedencia de permisos

Si tiene permissions definido en varios lugares de la configuración del paquete, los permisos que se conceden a los recursos, directorios del área de trabajo y archivos especificados en el paquete están en el siguiente orden:

1. Permisos definidos para el recurso en la implementación de destino
2. Permisos definidos para la implementación de destino
3. Permisos definidos para el recurso en la agrupación
4. Los permisos definidos en el nivel de permisos superior del conjunto

Por ejemplo, en la siguiente configuración, el grupo test-group tendrá CAN_MANAGE permisos para el trabajo en el objetivo dev, pero CAN_MANAGE_RUN permiso para el trabajo en el objetivo 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:
          # ...