Définir des autorisations pour les ressources dans les Databricks Asset Bundles

Cet article explique comment définir des autorisations pour les ressources dans databricks Asset Bundles. Pour plus d’informations sur les ressources prises en charge dans les offres groupées, consultez les ressources Databricks Asset Bundles.

Dans les fichiers de configuration du bundle Azure Databricks, vous pouvez définir des autorisations au niveau supérieur pour s’appliquer à toutes les ressources définies dans le bundle, ou vous pouvez définir des autorisations pour s’appliquer à des ressources spécifiques.

Définir des autorisations à appliquer à toutes les ressources

Vous pouvez définir des autorisations à appliquer à toutes les ressources prises en charge définies à resources l’aide du mappage de niveau permissions supérieur. Databricks recommande cette approche pour gérer les autorisations des ressources des Databricks Asset Bundles.

Les autorisations définissent le niveau d’autorisations autorisé pour un user_name, group_nameou service_principal_name. Les niveaux d’autorisation de niveau supérieur autorisés sont CAN_VIEW, CAN_MANAGE et CAN_RUN. Pour plus d’informations sur le mappage de niveau permissions supérieur, consultez autorisations.

L’exemple suivant définit les autorisations de niveau supérieur pour la dev cible. L’utilisateur someone@example.com aura CAN_RUN des autorisations sur my-job:

bundle:
  name: my-bundle

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

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

Définir des autorisations pour une ressource spécifique

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

Chaque autorisation dans le permissions mappage doit inclure les éléments suivants :

• Soit user_name, soit , group_nameou service_principal_name, défini sur le nom de l’utilisateur, du groupe ou du principal de service, respectivement.
• level, défini sur le nom du niveau d’autorisation. Les niveaux d’autorisation possibles pour chaque ressource sont les suivants :
  • Alertes : CAN_EDIT, , CAN_MANAGECAN_READ,CAN_RUN
  • Applications : CAN_MANAGE, CAN_USE
  • Clusters : CAN_ATTACH_TO, , CAN_MANAGECAN_RESTART
  • Tableaux de bord : CAN_EDIT, CAN_MANAGE, CAN_VIEW, CAN_READ
  • Instances de base de données : CAN_MANAGE, CAN_USE, CAN_CREATE
  • Expériences : CAN_EDIT, , CAN_MANAGECAN_READ,CAN_RUN
  • Travaux : CAN_MANAGE, , CAN_MANAGE_RUNCAN_VIEW,IS_OWNER
  • Modèles : CAN_EDIT, , CAN_MANAGECAN_MANAGE_STAGING_VERSIONS, CAN_MANAGE_PRODUCTION_VERSIONS,CAN_READ
  • Pipelines : CAN_MANAGE, , CAN_RUNCAN_VIEW,IS_OWNER
  • Étendues secrètes : READ, WRITE, MANAGE
  • SQL Warehouse : CAN_MANAGE, , CAN_USECAN_VIEW, CAN_MONITOR,IS_OWNER

La syntaxe suivante montre comment déclarer des autorisations pour un type de ressource (dans cet exemple, les pipelines) dans le mappage de niveau resources supérieur et dans un mappage au sein d’une resources cible :

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

Toutes les autorisations déclarées pour une ressource dans le mappage de resources de niveau supérieur sont combinées avec toutes les autorisations déclarées pour ce même mappage de resources dans une cible individuelle. Par exemple, étant donné le mappage de resources suivant pour la même ressource au niveau supérieur et dans une cible :

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

Lorsque vous exécutez databricks bundle validate cet exemple, le graphique résultant est le suivant :

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

Ordre de priorité des autorisations

Si vous avez permissions défini plusieurs emplacements dans votre configuration de bundle, les autorisations accordées aux ressources, aux répertoires d’espace de travail et aux fichiers spécifiés dans le bundle sont dans l’ordre suivant :

1. Autorisations définies pour la ressource dans le déploiement cible
2. Autorisations définies pour le déploiement cible
3. Autorisations définies pour la ressource dans le bundle
4. Autorisations définies dans les autorisations de niveau supérieur de l’offre groupée

Par exemple, dans la configuration suivante, le groupe test-group aura CAN_MANAGE des autorisations pour le travail dans la dev cible, mais CAN_MANAGE_RUN des autorisations pour le travail dans la prod cible :

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