Establecimiento de permisos para recursos en conjuntos de recursos de Databricks

En este artículo se describe cómo establecer permisos para trabajos de Azure Databricks, canalizaciones de Delta Live Tables y pilas de MLOps en conjuntos de recursos de Databricks. Consulte ¿Qué son las agrupaciones de recursos de Databricks?

En los archivos de configuración de agrupación de Azure Databricks, puede definir permisos para aplicarlos a todos los recursos definidos en la agrupación, o bien puede definir uno o varios 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 a la vez en la asignación de permissions de nivel superior y en la asignación de resources.

Definición de permisos para aplicarlos a todos los recursos

Puede definir permisos para aplicarlos a todos los experimentos, trabajos, modelos y canalizaciones definidos en resources mediante la asignación de permissions de nivel superior. Consulte los permisos.

Databricks recomienda este enfoque para administrar los permisos de recursos de Databricks Asset Bundles.

Definición de permisos para un recurso específico

Puede usar la asignación permissions en una definición de experimento, trabajo, modelo o canalización en resources para definir uno o más permisos para ese recurso.

Cada permiso de la asignación de permissions debe incluir las dos asignaciones siguientes:

• O bien user_name, group_name o service_principal_name, con el nombre del usuario, grupo o entidad de seguridad del servicio, respectivamente.
• level, con el nombre del nivel de permiso. Los niveles de permisos permitidos para cada recurso son los siguientes:
  • Experimentos: CAN_EDIT, CAN_MANAGE y CAN_READ.
  • Trabajos: CAN_MANAGE, CAN_MANAGE_RUN, CAN_VIEW y IS_OWNER.
  • Modelos: CAN_EDIT, CAN_MANAGE, CAN_MANAGE_STAGING_VERSIONS, CAN_MANAGE_PRODUCTION_VERSIONS y CAN_READ.
  • Canalizaciones: CAN_MANAGE, CAN_RUN, CAN_VIEW y IS_OWNER.

Para obtener información sobre los niveles de permisos específicos, consulte:

• Experimentos: ACL de experimento de MLflow
• Trabajos: ACL de trabajo
• Modelos: ACL de modelo de MLflow
• Canalizaciones: ACL de canalización de Delta Live Tables

Nota:

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

La siguiente sintaxis muestra cómo declarar múltiples permisos para cada tipo de recurso, ya sea en la asignación resources de nivel superior o en una asignación resources dentro de un destino (los puntos suspensivos indican contenido omitido, por brevedad):

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

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 resources para el mismo recurso tanto en el nivel superior como en un destino (los puntos suspensivos indican contenido omitido, por brevedad):

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

Cuando ejecuta databricks bundle validate para este ejemplo, el gráfico resultante es como el que se muestra a continuación (los puntos suspensivos indican contenido omitido, para abreviar):

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