Gérez les identités, les autorisations et les privilèges pour les Lakeflow Jobs

Les Lakeflow Jobs utilisent deux ensembles d'autorisations : les privilèges de job qui contrôlent qui peut consulter, exécuter et gérer un job, et les privilèges Exécuter en tant que qui déterminent l'identité qu'un job utilise pour accéder aux données et à d'autres Ressources. Cet article explique les deux, ainsi que les bonnes pratiques de gouvernance.

remarque

Les secrets ne sont pas masqués des stdout et stderr Stream du Driver Spark de la Ressource de compute classique. Pour protéger les données sensibles, par défaut, les logs du Driver Spark ne sont consultables que par les utilisateurs disposant de la permission CAN MANAGE sur le compute de Job et le compute polyvalent en mode d'accès dédié ou standard. Le même default s'applique aux Ressources de compute créées à partir d'un Pool. Pour permettre aux utilisateurs disposant des permissions CAN ATTACH TO ou CAN RESTART de consulter les logs, définissez la propriété suivante dans le champ de configuration Spark du compute : spark.databricks.acl.needAdminPermissionToViewLogs false.

Sur les compute hérités avec le mode d'accès partagé sans isolation, les logs du driver Spark peuvent être consultés par les utilisateurs disposant de l'autorisation CAN ATTACH TO, CAN RESTART ou CAN MANAGE. Pour limiter l'accès aux logs aux seuls utilisateurs disposant de l'autorisation CAN MANAGE, définissez spark.databricks.acl.needAdminPermissionToViewLogs sur true.

Comme spark.databricks.acl.needAdminPermissionToViewLogs est une propriété Spark au niveau du compute, vous devez la définir sur chaque compute qui en a besoin. Pour les exécutions de job éphémères soumises via jobs/runs/submit, telles que celles déclenchées par un orchestrateur externe, définissez la propriété dans new_cluster.spark_conf au moment de la soumission, ainsi que toute entrée access_control_list.

Privilèges du Job et utilisateur d'exécution

Les Jobs sont des objets dans Databricks et ont des privilèges qui vous permettent d'accéder à ces Jobs ou de les gérer. Cette page décrit ces privilèges comme des privilèges de job (ou des autorisations).

Les jobs s'exécutent et effectuent également des tâches au nom d'un utilisateur (ou d'un principal) qui dispose de ses propres privilèges pour agir sur les ressources que le job référence. L'utilisateur au nom duquel le Job agit est appelé utilisateur **Exécuter en tant que**, et ces privilèges sont désignés sur cette page comme des *privilèges Exécuter en tant que* (ou permissions). Les privilèges de l'utilisateur **Exécuter en tant que** sont utilisés lorsque le Job est exécuté.

Par exemple, si l' utilisateur A crée un Job et définit l'utilisateur Exécuter en tant que sur l' utilisateur B , le Job s'exécute avec les privilèges de l'utilisateur B. Si l' utilisateur C exécute le Job, le Job s'exécute toujours avec les privilèges de l'utilisateur B. Cela signifie qu'il est possible de donner à quelqu'un la possibilité d'exécuter un job pour obtenir des informations à partir de datasets auxquels ils n'ont pas eux-mêmes accès.

default privileges for jobs

Les tâches ont les privilèges suivants définis par default :

• L'auteur du Job se voit accorder l'autorisation IS OWNER sur le Job.
• Les administrateurs du Workspace se voient accorder l'autorisation CAN MANAGE sur le Job.
• Le créateur du job est défini pour **« Exécuter en tant que »**.
• Les autorisations de l'utilisateur **Exécuter en tant que** sont utilisées lors de l'exécution du job (incluant les tâches à l'intérieur du job).

Parce que le default est de définir le créateur comme propriétaire et utilisateur **Exécuter en tant que**, les privilèges du créateur sont utilisés lors de l'exécution du Job par default. Databricks recommande de modifier l'utilisateur **Exécuter en tant que** en un Service Principal, afin que les privilèges puissent être contrôlés séparément des privilèges du propriétaire, et que les Jobs ne s'interrompent pas lorsque le propriétaire quitte l'entreprise ou que ses privilèges sont modifiés.

Autorisations d’administration pour les jobs

By default, les administrateurs du Workspace peuvent modifier le propriétaire du Job ou la configuration Exécuter en tant que pour tout utilisateur ou Service Principal dans le Workspace. Les administrateurs de compte peuvent configurer le paramètre RestrictWorkspaceAdmins pour modifier ce comportement. Voir Restreindre les administrateurs de Workspace.

Comment les Jobs interagissent-ils avec les autorisations de Unity Catalog

Les jobs s'exécutent avec l'identité de l'utilisateur dans le paramètre Exécuter en tant que . Lors de l'exécution de tâches, cette identité est évaluée par rapport aux autorisations accordées pour les Ressources suivantes qui pourraient être utilisées dans ces tâches :

• Actifs gérés par Unity Catalog, y compris les tables, les volumes, les modèles et les vues.
• Listes de contrôle d'accès (ACL) de table héritées pour les assets enregistrés dans le Hive metastore hérité.
• ACLs pour le compute, les notebooks, les queries et d'autres assets du Workspace.
• Secrets Databricks. Consultez Gestion des secrets.

remarque

Les octrois Unity Catalog et les ACL de table héritées nécessitent des modes d'accès au compute compatibles. Consultez Configurer le calcul pour les Jobs.

Lorsque les privilèges sont évalués

Les privilèges du Job sont évalués lorsqu'un utilisateur effectue une action sur ce Job, telle que la modification ou l'exécution du Job.

Les privilèges Exécuter en tant que sont évalués pendant une exécution de Job. Ainsi, chaque tâche peut vérifier les privilèges lorsque la tâche start ou pendant l'exécution.

remarque

Tous les privilèges **Exécuter en tant que** ne sont pas vérifiés au début de l'exécution d'un job. Si vous modifiez les privilèges de l'utilisateur **Exécuter en tant que** pendant l'exécution d'un job, surtout si vous supprimez des privilèges, le job pourrait échouer avant de se terminer.

Tâches et autorisations SQL

La tâche de fichier est le seul type de tâche SQL à respecter entièrement l'utilisateur Exécuter en tant que .

Les requêtes SQL et les alertes respectent les paramètres de partage configurés.

• Exécuter en tant que propriétaire : les exécutions de la tâche SQL planifiée utilisent toujours l’identité du propriétaire de l’asset SQL configuré.
• Exécuter en tant qu'utilisateur en lecture seule : Les exécutions de la tâche SQL planifiée utilisent toujours l'identité définie dans le champ Exécuter en tant que du job.

Pour en savoir plus sur les paramètres de partage de query, consultez Configurez les autorisations de query.

Exemple

Le scénario suivant illustre l'interaction des paramètres de partage SQL et du paramètre Exécuter en tant que du Job :

• L'utilisateur A est le propriétaire de la query SQL nommée my_query.
• L'utilisateur A configure my_query avec le paramètre de partage Exécuter en tant que propriétaire .
• L'utilisateur B planifie my_query comme une tâche dans un Job nommé my_job.
• L'utilisateur B configure my_job pour s'exécuter avec un service principal nommé prod_sp.
• Lorsque my_job s'exécute, il utilise l'identité de User A pour exécuter my_query.

Supposons maintenant que l'utilisateur B ne souhaite pas ce comportement. À partir de la configuration existante, ce qui suit se produit :

• L'utilisateur A modifie le paramètre de partage de my_query en **Exécuter en tant qu'invité**.
• Lorsque my_job s'exécute, il utilise l’identité prod_sp.

Configurez l'utilisateur d'exécution pour les exécutions de Job

Pour modifier le paramètre Exécuter en tant que , vous devez disposer de l’autorisation CAN MANAGE ou IS OWNER sur le Job.

Vous pouvez définir le paramètre Exécuter en tant que sur vous-même ou sur tout Service Principal du Workspace pour lequel vous disposez du droit Utilisateur de Service Principal .

Pour configurer le paramètre **Exécuter en tant que** pour un job dans l'interface utilisateur du workspace, sélectionnez un job existant en suivant les étapes suivantes :

1. Dans la barre latérale de votre workspace Databricks, cliquez sur Tâches & Pipelines .
2. Vous pouvez, si vous le souhaitez, sélectionner les filtres Jobs et M’appartenant pour trouver plus facilement le Job.
3. Cliquez sur le nom du Job dans la liste.
4. Dans le volet Détails du job , cliquez sur l'icône en forme de crayon à côté du champ Exécuter en tant que .
5. Recherchez et sélectionnez un utilisateur ou un Service Principal.
6. Cliquez sur Enregistrer .

Pour plus d'informations sur l'utilisation des principaux de service, consultez les éléments suivants :

• Service Principal
• Rôles de gestion des Service Principals
• Répertorier les Service Principal que vous pouvez utiliser.

Définir Exécuter en tant que sur un groupe

info

Aperçu

Cette fonctionnalité est en Aperçu public. Pour rejoindre cette préversion, contactez l'équipe de votre compte Databricks.

La définition de l'identité Exécuter en tant que d'un Job pour un groupe fonctionne de la même manière que sa définition pour un utilisateur ou un Service Principal : le Job s'exécute avec les autorisations de cette identité. Lorsque l'identité Exécuter en tant que est un groupe, toutes les tâches s'exécutent en tant que groupe, les autorisations du groupe sont utilisées pour l'accès aux données, et les Logs d'audit enregistrent identity_metadata.run_as comme le groupe. Étant donné que les Jobs sont toujours exécutés par le Service Principal de l'application du service Jobs, identity_metadata.run_by enregistre toujours cette identité. Les assets du Workspace créés pendant l'exécution (notebooks, queries, fichiers) sont détenus par le groupe.

Vous n'avez pas besoin de prendre l'identité du groupe pour définir Exécuter en tant que sur celui-ci. Si vous créez un Job en prenant l'identité du groupe, Databricks définit automatiquement le propriétaire et Exécuter en tant que du Job sur le groupe. Vous pouvez également définir Exécuter en tant que sur le groupe manuellement. Pour configurer Exécuter en tant que sur un groupe manuellement, vous devez soit :

• Être membre du groupe, ou
• Avoir la permission « Assumer » sur le groupe, si le groupe est utilisé pour un accès exclusif.

Pour configurer **Run as** à un groupe dans l'interface utilisateur du Workspace :

1. Dans la barre latérale de votre workspace Databricks, cliquez sur Tâches & Pipelines .
2. Cliquez sur le nom du Job dans la liste.
3. Dans le volet latéral **Détails du Job**, cliquez sur l'icône du crayon à côté du champ **Exécuter en tant que**.
4. Recherchez et sélectionnez le groupe.
5. Cliquez sur Enregistrer .

Les tâches s'exécutent en tant que groupe **Exécuter en tant que** par default. Si le compute d'une tâche individuelle est un cluster en mode d'accès dédié attribué à un principal différent, la tâche s'exécute plutôt en tant que principal attribué au cluster.

Pour en savoir plus sur l'utilisation des groupes en tant que rôles, consultez le lien Contrôle d'accès basé sur les rôles (RBAC).

Bonnes pratiques pour la gouvernance des jobs

Databricks recommande ce qui suit pour tous les jobs de production :

• Exécutez des Jobs de production à l'aide d'un Service Principal

  Les **Jobs** s'exécutent en tant que créateur du job par default. Si l'utilisateur **Exécuter en tant que** quitte votre organisation, le Job peut échouer.

  Si vous attribuez l'utilisateur **Exécuter en tant que** à un Service Principal, les exécutions de Job utilisent les autorisations du Service Principal et ne changent pas lorsque les utilisateurs partent ou que leurs privilèges ont été modifiés.

  Par default, les administrateurs du Workspace peuvent gérer les permissions de Job et réattribuer la propriété si nécessaire.

  L'utilisation de Service Principal pour les Job de production vous permet également de restreindre les autorisations d'écriture sur les données de production. Si vous exécutez des jobs en utilisant les autorisations d'un utilisateur, cet utilisateur a besoin des mêmes autorisations pour modifier les données de production requises par le job.

• Utilisez toujours des configurations de compute compatibles avec Unity Catalog.

  La gouvernance des données d'Unity Catalog exige que vous utilisiez une configuration de compute prise en charge.

  Le compute Serverless pour les Jobs et les SQL Warehouses utilise toujours Unity Catalog.

  Pour les jobs avec compute classique, Databricks recommande le mode d'accès standard pour les charges de travail prises en charge. Utilisez le mode d'accès dédié si nécessaire.

  Les LakeFlow Pipelines configurés avec Unity Catalog ont certaines limitations. Consulter Limitations.

• Restreindre les privilèges de job sur les jobs de production

  Les privilèges des Jobs contrôlent qui peut afficher, exécuter ou gérer des Jobs.

  • Les utilisateurs qui consultent la configuration des Jobs ou surveillent les exécutions nécessitent l’autorisation Peut afficher .
  • Les utilisateurs qui Trigger, arrêtent ou redémarrent des exécutions de Job ont besoin de la permission Can Manage Run .
  • N'accordez que les privilèges Can Manage ou Is Owner aux utilisateurs autorisés à modifier le code de production.

Contrôler l'accès à un job

Le contrôle d'accès aux Jobs permet aux propriétaires et aux administrateurs de Jobs d'accorder des autorisations granulaires sur les Jobs. Les autorisations suivantes sont disponibles :

remarque

Chaque autorisation inclut les octrois d'autorisations en dessous d'elle dans le tableau suivant.

Autorisation	Accorder
IS OWNER	L'identité utilisée pour Run as by default. Vous pouvez définir l'utilisateur Exécuter en tant que pour contourner cela.
Gestion autorisée	Peut modifier la définition du job, y compris la configuration, les tâches et les autorisations. Peut suspendre et reprendre un calendrier.
CAN MANAGE RUN	Peut Trigger et annuler des exécutions de Job.
Consultation autorisée	Peut consulter les résultats d'exécution du Job, y compris les détails, l'historique et le statut.

Autorisation	Accorder
IS OWNER	L'identité utilisée pour Run as by default. Vous pouvez définir l'utilisateur Exécuter en tant que pour contourner cela.
Gestion autorisée	Peut modifier la définition du job, y compris la configuration, les tâches et les autorisations. Peut suspendre et reprendre un calendrier.
CAN MANAGE RUN	Peut Trigger et annuler des exécutions de Job.
Consultation autorisée	Peut consulter les résultats d'exécution du Job, y compris les détails, l'historique et le statut.

• Le créateur d'un Job a l'autorisation IS OWNER par default.
• Un Job ne peut pas avoir plus d'un propriétaire.
• Un groupe ne peut pas se voir attribuer l'autorisation IS OWNER en tant que propriétaire.
• Les jobs déclenchés via Exécuter maintenant assument les autorisations de l'utilisateur Exécuter en tant que (le propriétaire, par default) et non celles de l'utilisateur qui a émis Exécuter maintenant .
• Le contrôle d'accès aux Jobs s'applique aux Jobs affichés dans l'interface utilisateur Jobs & Pipelines et à leurs exécutions. Il ne s'applique pas aux :

  • Workflows de notebook qui exécutent du code modulaire ou lié. Elles utilisent les autorisations du notebook lui-même. Si le Notebook provient de Git, une nouvelle copie est créée et ses fichiers héritent des autorisations de l'utilisateur qui a déclenché l'exécution.

  • Tâches soumises par l'API. Celles-ci utilisent les permissions default du Notebook, sauf si vous définissez explicitement le access_control_list dans la requête API.

Pour des informations sur les niveaux d’autorisation de Job, consultez les listes ACL de Job.

Configurez les autorisations de Job

Pour configurer les autorisations pour un job dans l'interface utilisateur du Workspace, sélectionnez un job existant en suivant les étapes suivantes :

1. Dans la barre latérale de votre workspace Databricks, cliquez sur Tâches & Pipelines .
2. Facultativement, sélectionnez les filtres **Jobs** et **Appartenant à moi**.
3. Cliquez sur le **Link** **Nom** de votre Job.
4. Dans le volet Détails du job , cliquez sur Modifier les autorisations . La boîte de dialogue Paramètres d'autorisation apparaît.
5. Cliquez sur le champ Sélectionner un utilisateur, un groupe ou un Service Principal… et start à saisir un utilisateur, un groupe ou un Service Principal. Le champ recherche toutes les identités disponibles dans le workspace.
6. Cliquez sur **Ajouter**.
7. Cliquez sur Enregistrer .

Pour modifier ou supprimer une autorisation existante, cliquez sur Modifier les autorisations pour ouvrir la boîte de dialogue Paramètres d'autorisation . Pour modifier une autorisation, sélectionnez un niveau différent dans le menu déroulant à côté de l'identité. Pour supprimer une autorisation, cliquez sur le x à côté de l'identité.

Gérer le propriétaire du job

Seuls les administrateurs de workspace peuvent modifier le propriétaire du Job. Un seul propriétaire de Job doit être attribué. Les propriétaires de Job peuvent être des utilisateurs ou des Service Principal.

Tâches de Notebook et accès à l'API

Lorsque vous exécutez une tâche de Notebook via l'interface utilisateur, la sortie (dans le Notebook) n'est accessible que si l'utilisateur a accès au Notebook sous-jacent. Cependant, lorsque le même Job est exécuté via l'API, la sortie d'exécution est visible pour l'API, même si l'utilisateur de l'API n'a accès qu'au Job lui-même, et non au Notebook.