Accès au groupe de compute dédié

Le compute de groupe dédié dans Databricks exécute des notebooks et des jobs en utilisant les autorisations d'un groupe assigné. Vous pouvez partager la ressource de compute avec les membres du groupe et les utilisateurs qui ont l'autorisation d'assumer le groupe.

Le mode d'accès de groupe dédié permet aux utilisateurs d'obtenir l'efficacité opérationnelle d'un cluster en mode d'accès standard tout en prenant en charge de manière sécurisée les langages et les charges de travail qui ne sont pas pris en charge par le mode d'accès standard, tels que Databricks Runtime pour ML, les APIs RDD (Resilient Distributed Dataset) et R.

Les clusters de groupe sont un moyen d'assumer un rôle dans Databricks. Lorsqu'un utilisateur se connecte à un cluster de groupe, ses permissions d'identité d'utilisateur sont remplacées par les permissions du groupe pour les opérations sur ce cluster. Cela équivaut à assumer le groupe en tant que rôle pour la durée de la session du cluster. Pour les autres méthodes d'assomption de rôle, y compris le sélecteur de rôle, le CLI et l'API, consultez Changer de rôle RBAC.

Exigences

Pour utiliser le mode d'accès de groupe dédié :

• Le Workspace doit être activé pour Unity Catalog.
• Vous devez utiliser Databricks Runtime 15.4 ou une version ultérieure.
• Le groupe doit être un groupe de comptes attribué au workspace.
• Le groupe attribué doit disposer des autorisations CAN MANAGE sur un dossier Workspace dans lequel il peut conserver des Notebooks, des expérimentations ML et d'autres artefacts Workspace utilisés par le cluster de groupe.

Qu'est-ce que le mode d'accès dédié ?

Le mode d’accès dédié, anciennement appelé mode d’accès mono-utilisateur, attribue une ressource compute à un utilisateur, ou à un groupe. Une ressource compute attribuée à un groupe est appelée cluster de groupe. Seul l’utilisateur auquel elle est attribuée, ou les utilisateurs qui peuvent agir en tant que groupe auquel elle est attribuée, peuvent y exécuter des charges de travail.

Créez une ressource de compute dédiée à un groupe

Pour créer un compute de groupe, vous devez avoir la permission d'utiliser une politique de compute ou le droit de création de clusters sans restriction. Sauf si vous êtes administrateur du workspace, vous devez également être membre du groupe assigné ou avoir la permission de l'assumer.

1. Dans votre Workspace Databricks, accédez à Compute et cliquez sur Créer un compute .
2. Développer la section Avancé .
3. Sous Mode d'accès , cliquez sur Manuel puis sélectionnez Dédié (anciennement : Utilisateur unique) dans le menu déroulant.
4. Dans le champ Utilisateur ou groupe unique , sélectionnez le groupe que vous souhaitez assigner à cette ressource.
5. Configurez les autres paramètres de compute souhaités, puis cliquez sur Créer.

Accorder l’accès au compute de groupe

Pour utiliser un cluster de groupe, vous avez besoin des deux éléments suivants :

• L'autorisation CAN ATTACH TO sur la ressource compute.
• Appartenance au groupe attribué, y compris par l’intermédiaire d’un groupe imbriqué, ou autorisation d’ assumer le groupe attribué.

Affecter un groupe à une ressource de compute donne automatiquement à ce groupe CAN ATTACH TO. Vous pouvez accorder des autorisations de compute à des utilisateurs ou des groupes supplémentaires, mais cela ne modifie pas le groupe assigné ou l'identité de la workload. Ces utilisateurs doivent toujours être membres du groupe assigné ou avoir l'autorisation de l'assumer. Être gestionnaire de groupe ne donne pas, seul, l'autorisation de créer, modifier, supprimer ou utiliser le cluster.

Pour accorder un accès au compute, vous devez avoir CAN MANAGE sur la ressource de compute :

1. Dans la barre latérale, cliquez sur Compute .
2. Dans la ligne de la ressource de compute, ouvrez le menu kebab et sélectionnez Modifier les autorisations .
3. Dans Paramètres d’autorisation , cliquez sur le menu déroulant Sélectionner un utilisateur, un groupe ou un Service Principal… , puis sélectionnez l’utilisateur ou le groupe.
4. Sélectionnez l'autorisation CAN ATTACH TO dans le menu déroulant des autorisations.
5. Cliquez sur Ajouter , puis sur Enregistrer .

Voir Autorisations de compute.

Pour modifier ou supprimer définitivement un cluster de groupe, vous avez besoin de CAN MANAGE sur la ressource de compute. L'édition nécessite également d'être membre du groupe attribué, ou d'avoir la permission d'assumer son identité, sauf si vous êtes administrateur du workspace.

Utiliser un compute de groupe à partir d’un notebook

Pour exécuter un notebook avec les autorisations d'un groupe assigné :

1. Ouvrez un notebook dans un dossier de workspace auquel le groupe assigné peut accéder.

2. Dans le sélecteur de compute du notebook, sélectionnez le cluster du groupe. S’il n’est pas répertorié, cliquez sur Plus… pour le trouver.

3. Dans une cellule SQL, ou une cellule qui commence par %sql, exécutez la commande suivante pour vérifier l'identité de la session :

   SQL

   SELECT session_user();

Le résultat est le nom du groupe assigné. Accordez des autorisations de données et de workspace à ce groupe pour les opérations effectuées par le notebook. Vos autorisations personnelles ne s'ajoutent pas aux autorisations du groupe sur le cluster.

Si vous agissez déjà en tant que rôle via le sélecteur de rôle du workspace, ce rôle doit correspondre au groupe affecté au cluster. Voir Passer d'un rôle RBAC à un autre.

Pour plus d’informations sur l’association de notebooks, consultez Associer un notebook à une ressource compute polyvalente.

Exécuter les jobs en tant que groupe

Les jobs peuvent s'exécuter avec les autorisations d'un groupe, y compris lorsque vous configurez le job via l'API ou le SDK. Dans les détails du job, définissez Exécuter en tant que sur le groupe affecté à la ressource de compute. Le groupe doit disposer de l'autorisation d'accéder aux notebooks, aux fichiers et aux données utilisés par le job.

Dans une requête Jobs API, définissez run_as.group_name sur le nom du groupe :

JSON

{
  "run_as": {
    "group_name": "analytics-team"
  }
}

Pour connaître les étapes de configuration, les exigences du groupe et le comportement lorsqu’une tâche utilise un compute dédié affecté à une identité différente, consultez Définir l’option Exécuter en tant que sur un groupe.

Bonnes pratiques pour la gestion des clusters de groupe

Étant donné que les autorisations des utilisateurs sont limitées au groupe lors de l'utilisation de clusters de groupe, Databricks recommande de créer un dossier /Workspace/Groups/<groupName> pour chaque groupe que vous prévoyez d’utiliser avec un cluster de groupe. Puis, attribuez les autorisations CAN MANAGE sur le dossier au groupe. Cela permet aux groupes d'éviter les erreurs d'autorisation. Tous les notebooks et Workspace assets du groupe doivent être gérés dans le dossier du groupe.

Vous devez également modifier les charges de travail suivantes pour qu'elles s'exécutent sur des clusters de groupe :

• MLflow : assurez-vous d'exécuter le Notebook depuis le dossier de groupe ou exécutez mlflow.set_tracking_uri("/Workspace/Groups/<groupName>").
• AutoML : définissez le parameter facultatif experiment_dir sur “/Workspace/Groups/<groupName>” pour vos exécutions AutoML.
• dbutils.notebook.run: Assurez-vous que le groupe dispose de l'autorisation READ sur le Notebook en cours d'exécution.

Comportement en matière d'autorisations sur les clusters de groupes

Toutes les commandes, queries et autres actions effectuées sur un cluster de groupe utilisent les autorisations attribuées au groupe, et non à l'utilisateur individuel.

Les autorisations utilisateur individuelles ne peuvent pas être appliquées, car tous les membres du groupe ont un accès complet aux Spark API et à l’environnement de compute partagé. Si des autorisations basées sur l’utilisateur étaient appliquées, un membre pourrait query des données restreintes, et un autre membre sans accès pourrait toujours récupérer les résultats via l’environnement partagé. Par conséquent, le groupe lui-même, et non l’utilisateur membre du groupe, doit disposer des autorisations nécessaires pour effectuer l’action avec succès.

Par exemple, le groupe a besoin d'une autorisation explicite pour query une table, accéder à un Secret Scope ou un secret, utiliser des identifiants de connexion Unity Catalog, accéder à un dossier Git ou créer un objet Workspace.

Exemple d’autorisations de groupe

Lorsque vous créez un objet de données à l'aide du cluster de groupes, le groupe est attribué comme propriétaire de l'objet.

Par exemple, si vous avez un notebook associé à un cluster de groupe et exécutez la commande suivante :

SQL

use catalog main;
create schema group_cluster_group_schema;

Exécutez ensuite cette query pour vérifier le propriétaire du schéma :

SQL

describe schema group_cluster_group_schema;

Activité de compute dédiée au groupe d'audit

Deux identités clés sont impliquées lorsqu'un cluster de groupe exécute une charge de travail :

1. L'identité qui lance la charge de travail sur le cluster de groupe
2. Le groupe dont les autorisations sont utilisées pour effectuer les actions réelles de la charge de travail

La table système des logs d'audit enregistre ces identités sous les parameters suivants :

• identity_metadata.run_by: L’identité d’authentification qui initie l’action.
• identity_metadata.run_as: Le groupe d’autorisation dont les permissions sont utilisées pour l’action.

Pour les charges de travail interactives, run_by identifie l'utilisateur. Pour les charges de travail de job, il identifie le service principal de l'application du service Jobs. Voir Exécuter en tant que groupe.

L'exemple de query suivant récupère les métadonnées d'identité pour une action effectuée avec le cluster de groupe :

SQL

select action_name, event_time, user_identity.email, identity_metadata
from system.access.audit
where user_identity.email = "uc-group-cluster-group" AND service_name = "unityCatalog"
order by event_time desc limit 100;

Consultez la référence de la table système de journalisation d'audit pour plus d'exemples de requêtes. Consultez la référence de la table système de Logs d'audit.

Les audit logs délivrés au stockage du client prennent également en charge les métadonnées d'identité. Le JSON livré utilise identityMetadata.runAs pour le groupe autorisant et identityMetadata.runBy pour l'identité authentifiant. Ces champs ne sont pas renseignés pour chaque événement d'audit. Voir Référence des audit logs.

Limitations connues

L’accès de groupe dédié présente les limitations suivantes :

• Les jobs qui utilisent Git échouent car le répertoire temporaire utilisé par le job pour extraire le repo Git n'est pas accessible en écriture. Utilisez plutôt des dossiers Git.
• Le champ created_by dans les tables système de lignage des tables et des colonnes enregistre le groupe. Ces tables n’enregistrent pas séparément l’utilisateur qui a lancé la charge de travail.
• Lorsqu'il est attaché à un cluster de groupe, l'Explorateur de catalogues ne filtre pas par les assets uniquement accessibles au groupe.
• Si un groupe est renommé, vous devez mettre à jour manuellement toutes les politiques de compute qui référencent le nom du groupe.
• Les clusters de groupe ne sont pas pris en charge dans les Workspace où les listes de contrôle d'accès (ACL) sont désactivées (isWorkspaceAclsEnabled est false), car ces Workspace ne disposent pas de contrôles de sécurité et d'accès aux données.
• La commande %run et les autres actions dans le contexte du notebook utilisent les permissions de l'utilisateur plutôt que celles du groupe. Cela est dû au fait que ces actions sont gérées par l'environnement du notebook, et non par l'environnement du cluster. Les commandes alternatives telles que dbutils.notebook.run() sont exécutées sur le cluster et utilisent donc les permissions du groupe.
• La fonction is_member(<group>) retourne false lorsqu'elle est invoquée sur un cluster de groupe car le groupe n'est pas membre de lui-même. Pour vérifier l'appartenance à la fois aux clusters de groupe et aux autres modes d'accès, utilisez is_member(<group>) OR session_user() = <group>.
• AI Search impose des restrictions lorsque vous agissez en tant que groupe. Voir les opérations prises en charge et les restrictions d'index.
• La suppression de fichiers et de dossiers n'est pas prise en charge dans les clusters de groupe.
• L'interface utilisateur d'upload de fichiers ne prend pas en charge les clusters de groupe.