Définir les autorisations pour les ressources dans les groupes d'actifs Databricks

Cet article explique comment définir des autorisations pour les tâches Azure Databricks, les pipelines Delta Live Tables et MLOps Stacks dans les bundles d'actifs Databricks. Consultez Que sont les packs de ressources Databricks ?.

Dans les fichiers de configuration groupésd’Azure Databricks, vous pouvez définir des autorisations pour s’appliquer à toutes les ressources définies dans le bundle, ou vous pouvez définir une ou plusieurs autorisations à appliquer à des ressources spécifiques.

Remarque

Les autorisations ne peuvent pas se chevaucher. En d’autres termes, les autorisations d’un utilisateur, d’un groupe ou d’un principal de service ne peuvent pas être définies à la fois dans le mappage permissions de niveau supérieur et dans le mappage resources.

Définir des autorisations à appliquer à toutes les ressources

Vous pouvez définir des autorisations à appliquer à toutes les expériences, travaux, modèles et pipelines définis dans resources à l’aide du mappage de permissions de niveau supérieur. Consultez autorisations.

Databricks recommande cette approche pour la gestion des autorisations de ressources Databricks Asset Bundles.

Définir des autorisations pour une ressource spécifique

Vous pouvez utiliser le mappage permissions dans une définition d’expérience, de travail, de modèle ou de pipeline au sein de resources afin de définir une ou plusieurs autorisations pour cette ressource.

Chaque autorisation du mappage permissions doit inclure les deux mappages suivants :

• Soit user_name, group_name, ou service_principal_name, avec le nom de l'utilisateur, du groupe ou du principal du service, respectivement.
• level, avec le nom du niveau d'autorisation. Les niveaux d’autorisation autorisés pour chaque ressource sont les suivants :
  • Expériences : CAN_EDIT, CAN_MANAGE et CAN_READ.
  • Travaux : CAN_MANAGE, CAN_MANAGE_RUN, CAN_VIEWet IS_OWNER.
  • Modèles : CAN_EDIT, CAN_MANAGE, CAN_MANAGE_STAGING_VERSIONS, CAN_MANAGE_PRODUCTION_VERSIONS, et CAN_READ.
  • Pipelines : CAN_MANAGE, CAN_RUN, CAN_VIEW, et IS_OWNER.

Pour plus d’informations sur les niveaux d’autorisation spécifiques, consultez :

• Expériences : ACL d’expérience MLflow
• Travaux : Listes ACL de travaux
• Modèles : ACL de modèles MLflow
• Pipelines : listes de contrôle d’accès du pipeline Delta Live Tables

Remarque

Les niveaux d’autorisation autorisés pour les ressources ne peuvent pas nécessairement être appliqués aux ressources à l’aide du mappage permissions de premier niveau. Pour connaître les niveaux d’autorisation valides du mappage permissions, consultez Autorisations.

La syntaxe suivante montre comment déclarer plusieurs autorisations pour chaque type de ressource, soit dans le mappage resources de niveau supérieur, soit dans un mappage resources au sein d'une cible (les points de suspension indiquent le contenu omis, par souci de concision) :

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

Toutes les autorisations déclarées pour une ressource dans le mappage resources de niveau supérieur sont combinées avec toutes les autorisations déclarées pour ce même mappage resources dans une cible individuelle. Par exemple, étant donné le mappage resources suivant pour la même ressource au niveau supérieur et dans une cible (les points de suspension indiquent le contenu omis, par souci de concision) :

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

Lorsque vous exécutez databricks bundle validate pour cet exemple, le graphique résultant est le suivant (les points de suspension indiquent du contenu omis, par souci de concision) :

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