Comparteix via

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 agrupaciones, consulte Recursos de conjuntos de recursos 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.

Nota:

Los permisos no se pueden superponer. Es decir, los permisos de un usuario, grupo o entidad de servicio no se pueden definir en la asignación permissions de nivel superior y dentro de la asignación de resources.

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 la asignación de nivel permissions superior, 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 canalización en resources para definir uno o varios permisos para ese recurso.

Cada permiso de la permissions asignación debe incluir lo siguiente:

  • O user_name, group_nameo service_principal_name, se establece en el nombre del usuario, el grupo o la entidad de servicio, respectivamente.
  • level, se establece en el nombre del nivel de permiso. Los niveles de permisos permitidos para cada recurso son los siguientes:

Importante

Los niveles de permisos permitidos para los recursos no siempre se pueden aplicar a los recursos mediante el mapeo de nivel superior permissions. Para conocer los niveles de permisos válidos para la asignación de nivel permissions superior, consulte permisos.

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

# ...
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:
          # ...
  • Last updated on