Aller au contenu principal
Dernière mise à jour le

Définir les autorisations pour les ressources dans les Declarative Automation Bundles

Cet article décrit comment définir les permissions pour les ressources dans les Declarative Automation Bundles. Pour des informations sur les ressources prises en charge dans les bundles, consultez Ressources des Declarative Automation Bundles.

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

remarque

Les autorisations ne peuvent pas se chevaucher. En d'autres termes, les autorisations pour un utilisateur, un groupe ou un Service Principal ne peuvent pas être définies à la fois dans le mappage permissions de haut niveau et dans le mappage resources.

Définir les autorisations à appliquer à toutes les ressources​

Vous pouvez définir des permissions à appliquer à toutes les Ressources prises en charge définies dans resources en utilisant le mappage de niveau supérieur permissions. Databricks recommande cette approche pour la gestion des permissions de ressources des Declarative Automation Bundles.

Les autorisations définissent le niveau d'autorisation autorisé pour un user_name, group_name ou service_principal_name. Les niveaux d'autorisation supérieurs autorisés sont CAN_VIEW, CAN_MANAGE et CAN_RUN. Pour plus d'information sur le mappage permissions de niveau supérieur, consultez les autorisations.

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

YAML
bundle:
  name: my-bundle

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

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

Définissez les autorisations pour une ressource spécifique​

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

Chaque autorisation de la correspondance permissions doit inclure les éléments suivants :

  • Soit user_name, group_name, ou service_principal_name, défini respectivement sur le nom de l'utilisateur, du groupe, ou du Service Principal.
  • level, défini sur le nom du niveau d'autorisation. Les niveaux d'autorisation autorisés pour chaque ressource sont les suivants :

* L'interface utilisateur du Workspace désigne l'accès en lecture seule comme CAN VIEW, tandis que l'API Permissions utilise CAN READ pour représenter le même niveau d'accès.

important

Les niveaux d'autorisation autorisés pour les ressources ne peuvent pas nécessairement être appliqués aux ressources utilisant le mappage permissions de niveau supérieur. Pour les niveaux d'autorisation valides pour le mappage permissions de niveau supérieur, consultez les autorisations.

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

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

YAML
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 pour cet exemple, le graphe résultant est le suivant :

JSON
{
  "...": "...",
  "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(e) à plusieurs endroits dans la configuration de votre bundle, les autorisations accordées aux Ressources, aux répertoires du Workspace et aux fichiers spécifiés dans le bundle sont dans l'ordre suivant :

  1. Les autorisations définies pour la ressource dans le déploiement cible
  2. Les autorisations définies pour le déploiement cible
  3. Les autorisations définies pour la ressource dans le bundle
  4. Les autorisations définies dans les autorisations de premier niveau du bundle

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

YAML
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:
          # ...
Sur cette page