Partager via

Gérer les identités, les autorisations et les privilèges pour les projets Databricks

  • Article

Cet article contient des recommandations et des instructions pour la gestion des identités, des autorisations et des privilèges pour les travaux Databricks.

Remarque

Les secrets ne sont pas expurgés des flux stdout et stderr du journal du pilote Spark d’un cluster. Pour protéger des données sensibles, les journaux de pilote Spark sont affichables par défaut uniquement par des utilisateurs ayant une autorisation PEUT GÉRER sur un travail, un mode d’accès utilisateur unique et des clusters en mode d’accès partagé. Pour autoriser des utilisateurs avec l’autorisation PEUT ATTACHER À ou PEUT REDÉMARRER à afficher les journaux sur ces clusters, définissez la propriété de configuration Spark suivante dans la configuration de cluster : spark.databricks.acl.needAdminPermissionToViewLogs false.

Sur des clusters en mode d’accès Aucune isolation partagée, les utilisateurs peuvent afficher des journaux de pilote Spark avec l’autorisation PEUT ATTACHER À ou PEUT GÉRER. Pour limiter les utilisateurs qui peuvent lire les journaux aux seuls utilisateurs avec l’autorisation PEUT GÉRER, définissez spark.databricks.acl.needAdminPermissionToViewLogs sur true.

Consultez configuration Spark pour découvrir comment ajouter des propriétés Spark à une configuration de cluster.

Privilèges par défaut pour les travaux

Les travaux ont les privilèges suivants définis par défaut :

  • Le créateur du travail reçoit l’autorisation EST PROPRIÉTAIRE.
  • Les administrateurs d’espace de travail reçoivent l’autorisation PEUT GÉRER.
  • Le créateur du travail est défini pour Exécuter en tant que.

Autorisations d’administrateur pour les travaux

Par défaut, les administrateurs d’espace de travail peuvent remplacer le propriétaire d’un travail ou une configuration Exécuter en tant que par n’importe quel utilisateur ou principal de service dans l’espace de travail. Les administrateurs de compte peuvent configurer le paramètre RestrictWorkspaceAdmins pour modifier ce comportement. Consultez Restreindre les administrateurs de l’espace de travail.

Comment les travaux interagissent-ils avec les autorisations Unity Catalog ?

L’exécution du travail en tant qu’identité de l’utilisateur dans le paramètre Exécuter en tant que. Cette identité est évaluée par rapport aux octrois d’autorisations pour les éléments suivants :

  • Ressources gérées par Unity Catalog, notamment les tables, les volumes, les modèles et les vues.
  • Listes de contrôle d’accès (ACL) aux tables héritées pour les ressources inscrites dans le metastore Hive hérité.
  • Listes de contrôle d’accès pour le calcul, les Notebooks, les requêtes et d’autres ressources d’espace de travail.
  • Secrets Databricks Consultez Gestion des secrets.

Remarque

Les allocations Unity Catalog et les listes de contrôle d’accès aux table héritées nécessitent des modes d’accès de calcul compatibles. Consultez Configurer le calcul pour les projets.

Tâches SQL et autorisations

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

Les requêtes SQL, les alertes et les tâches de tableau de bord hérité 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 la ressource SQL configurée.
  • Exécuter en tant que viewer : les exécutions de la tâche SQL planifiée utilisent toujours l’ensemble d’identités dans le champ Exécuter sous du travail.

Pour en savoir plus sur les paramètres de partage de requêtes, consultez Configurer les autorisations de requête.

Exemple

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

  • L’utilisateur A est le propriétaire de la requête 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 tâche dans un travail nommé my_job.
  • L’utilisateur B configure l’exécution de my_job avec un principe de service nommé prod_sp.
  • Lors de l’exécution de my_job, il utilise l’identité de l’utilisateur A pour exécuter my_query.

Supposons maintenant que l’utilisateur B ne souhaite pas ce comportement. À partir de la configuration existante, les événements suivants se produisent :

  • L’utilisateur A modifie le paramètre de partage pour my_query Exécuter en tant que viewer.
  • Lors de l’exécution de my_job, il utilise l’identité prod_sp.

Configurer l’identité pour les exécutions de projet

Pour modifier le paramètre Exécuter en tant que, vous devez disposer de l’autorisation PEUT GÉRER ou EST PROPRIÉTAIRE sur le travail.

Vous pouvez définir le paramètre Exécuter en tant que sur vous-même ou sur n’importe quel principal de service dans l’espace de travail sur lequel vous disposez du droit d’utilisation Utilisateur de principal de service.

Pour configurer le paramètre Exécuter en tant que pour un travail dans l’interface utilisateur de l’espace de travail, sélectionnez un travail existant en procédant comme suit :

  1. Cliquez sur Icône de flux de travail Workflows dans la barre latérale.
  2. Dans la colonne Nom, cliquez sur le nom d’un travail.
  3. Dans le panneau latéral Détails de la tâche , cliquez sur l’icône en forme de crayon en regard du champ Exécuter en tant que.
  4. Recherchez et sélectionnez un utilisateur ou un principal de service.
  5. Cliquez sur Enregistrer.

Pour plus d’informations sur l’utilisation des principaux de service, voir les rubriques suivantes :

Bonnes pratiques de gouvernance des travaux

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

  • Affecter la propriété d’un travail à un principal de service

    Si l’utilisateur propriétaire d’un travail quitte votre organisation, le travail peut échouer. Utilisez des principaux de service pour que les travaux soient robustes pour l’attrition des employés.

    Par défaut, les administrateurs d’espace de travail peuvent gérer les autorisations de travail et réaffecter la propriété, si nécessaire.

  • Exécuter des travaux de production en utilisant un principal de service

    Les travaux s’exécutent à l’aide des privilèges du propriétaire du travail par défaut. Si vous attribuez la propriété à un principal de service, le travail s’exécute à l’aide des autorisations du principal de service.

    L’utilisation de principaux de service pour les travaux de production vous permet de restreindre les autorisations d’accès en écriture sur les données de production. Si vous exécutez des travaux à l’aide des autorisations d’un utilisateur, cet utilisateur a besoin des mêmes autorisations pour modifier les données de production requises par le travail.

  • Toujours utiliser les configurations de calcul compatibles avec Unity Catalog

    La gouvernance des données Unity Catalog nécessite l’utilisation d’une configuration de calcul prise en charge.

    Le calcul serverless pour les travaux et les entrepôts SQL utilise toujours Unity Catalog.

    Pour les travaux avec le calcul classique, Databricks recommande le mode d’accès partagé pour les charges de travail prises en charge. Utilisez le mode d’accès utilisateur unique si nécessaire.

    Les pipelines Delta Live Tables configurés avec Unity Catalog présentent certaines limitations. Voir Limitations.

  • Restreindre les autorisations sur les travaux de production

    Les utilisateurs qui déclenchent, arrêtent ou redémarrent des exécutions de travaux ont besoin de l’autorisation Peut gérer l’exécution.

    Les utilisateurs qui consultent la configuration du travail ou qui surveillent les exécutions ont besoin de l’autorisation Affichage.

    Accordez uniquement des privilèges Gérer ou Est propriétaire aux utilisateurs approuvés pour modifier le code de production.

Contrôler l'accès à un emploi

Le contrôle d’accès aux travaux permet aux propriétaires de travaux et aux administrateurs d’accorder des permissions affinées sur les travaux. Les autorisations suivantes sont disponibles :

Remarque

Chaque autorisation inclut les octrois d’autorisations ci-dessous dans le tableau suivant.

Autorisation Accorder
Est propriétaire L’identité utilisée pour Exécuter en tant que par défaut.
Gérer Les utilisateurs peuvent modifier la définition du travail, y compris les autorisations. Les utilisateurs peuvent suspendre et reprendre une planification.
Can Manage Run Les utilisateurs peuvent déclencher et annuler des exécutions de travaux.
Affichage Les utilisateurs peuvent afficher les résultats de l’exécution du travail.

Pour plus d’informations sur les niveaux d’autorisation des travaux, consultez Listes de contrôle d’accès (ACL) des tâches.

Configurer les autorisations de travaux

Pour configurer les autorisations pour un travail dans l’interface utilisateur de l’espace de travail, sélectionnez un travail existant en procédant comme suit :

  1. Cliquez sur Icône de flux de travail Workflows dans la barre latérale.
  2. Dans la colonne Nom, cliquez sur le nom d’un travail.
  3. Dans le panneau Détails du travail, cliquez sur Modifier les autorisations. La boîte de dialogue Paramètres d’autorisation s’affiche.
  4. Cliquez sur le champ Sélectionner un utilisateur, un groupe ou un principal de service... et commencez à saisir un utilisateur, un groupe ou un principal de service. Le champ recherche toutes les identités disponibles dans l’espace de travail.
  5. Cliquez sur Ajouter..
  6. Cliquez sur Enregistrer.

Gérer le propriétaire de la tâche

Seuls des administrateurs d’espace de travail peuvent modifier le propriétaire du travail. Un propriétaire de travail exactement doit être affecté. Les propriétaires de travaux peuvent être des utilisateurs ou des principaux de service.