Accès au groupe de calcul dédié

Cet article explique comment créer une ressource de calcul affectée à un groupe à l’aide du mode d’accès dédié .

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 en toute sécurité les langages et charges de travail qui ne sont pas pris en charge par le mode d’accès standard, tels que Databricks Runtime pour ML, les API RDD et R.

Exigences

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

• L’espace de travail doit être activé pour le catalogue Unity.
• Vous devez utiliser Databricks Runtime 15.4 ou version ultérieure.
• Le groupe affecté doit disposer d’autorisations CAN MANAGE sur un dossier d’espace de travail où ils peuvent conserver des notebooks, des expériences ML et d’autres artefacts d’espace de travail 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é est la dernière version du mode d’accès mono-utilisateur. Avec l’accès dédié, une ressource de calcul peut être affectée à un seul utilisateur ou groupe, ce qui permet uniquement à l’utilisateur affecté d’utiliser la ressource de calcul.

Lorsqu'un utilisateur est connecté à une ressource de calcul dédiée à un groupe (un cluster de groupes), les autorisations de l'utilisateur sont automatiquement réduites pour correspondre à celles du groupe, ce qui permet à l'utilisateur de partager en toute sécurité la ressource avec les autres membres du groupe.

Créer une ressource de calcul dédiée à un groupe

1. Dans votre espace de travail Azure Databricks, accédez à Calcul , puis cliquez sur Créer un calcul.
2. Développez la section Avancé .
3. En mode Accès, cliquez sur Manuel , puis sélectionnez Dédié (anciennement : Mono-utilisateur) dans le menu déroulant.
4. Dans le champ Utilisateur unique ou groupe , sélectionnez le groupe que vous souhaitez affecter à cette ressource.
5. Configurez les autres paramètres de calcul souhaités, puis cliquez sur Créer.

Meilleures pratiques pour la gestion des clusters de groupe

Étant donné que les autorisations utilisateur 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 envisagez d’utiliser avec un cluster de groupe. Ensuite, accordez les autorisations CAN MANAGE sur le dossier au groupe. Cela permet aux groupes d’éviter les erreurs d’autorisation. Tous les blocs-notes et ressources d’espace de travail 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 : vérifiez que vous exécutez le notebook à partir du dossier de groupe ou exécutez mlflow.set_tracking_uri("/Workspace/Groups/<groupName>").
• AutoML : définissez le paramètre de experiment_dir facultatif sur “/Workspace/Groups/<groupName>” pour vos exécutions AutoML.
• dbutils.notebook.run : vérifiez que le groupe dispose d’une autorisation READ sur le notebook en cours d’exécution.

Comportement d’autorisation sur les clusters de groupe

Toutes les commandes, requêtes et autres actions effectuées sur un cluster de groupe utilisent les autorisations affecté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 API Spark et à l’environnement de calcul partagé. Si des autorisations basées sur l’utilisateur ont été appliquées, un membre peut interroger des données restreintes, et un autre membre sans accès peut 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.

Par exemple, le groupe a besoin d’une autorisation explicite pour interroger une table, accéder à une étendue secrète ou un secret, utiliser des informations d’identification de connexion de catalogue Unity, accéder à un dossier Git ou créer un objet d’espace de travail.

Exemples d’autorisations de groupe

Lorsque vous créez un objet de données à l’aide du cluster de groupe, le groupe est affecté en tant que propriétaire de l’objet.

Par exemple, si vous avez un bloc-notes attaché à un cluster de groupe et exécutez la commande suivante :

use catalog main;
create schema group_cluster_group_schema;

Exécutez ensuite cette requête pour vérifier le propriétaire du schéma :

describe schema group_cluster_group_schema;

Audit de l’activité de calcul dédiée au groupe

Il existe deux identités clés impliquées lorsqu’un cluster de groupe exécute une charge de travail :

1. Utilisateur qui exécute la charge de travail sur le cluster de groupe
2. Groupe dont les autorisations sont utilisées pour effectuer les actions de charge de travail réelles

La table système du journal d’audit enregistre ces identités sous les paramètres suivants :

• identity_metadata.run_by: utilisateur d’authentification qui effectue l’action
• identity_metadata.run_as: groupe d’autorisation dont les autorisations sont utilisées pour l’action.

L’exemple de requête suivant extrait les métadonnées d’identité pour une action effectuée avec le cluster de groupe :

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 du journal d’audit pour obtenir d’autres exemples de requêtes. Consultez Référence de table système du journal d’audit.

Limitations connues

L’accès aux groupes dédiés présente les limitations suivantes :

• Les travaux créés à l’aide de l’API et du Kit de développement logiciel (SDK) ne peuvent pas être affectés à l’accès au groupe. Cela est dû au fait que le paramètre du travail run_as supporte uniquement un seul utilisateur ou principal de service.
• Les travaux qui utilisent Git échouent, car le répertoire temporaire utilisé par le travail pour extraire le référentiel Git n’est pas accessible en écriture. Utilisez plutôt des dossiers Git .
• Les tables système de traçabilité n’enregistrent pas identity_metadata.run_as (le groupe d’autorisation) ou identity_metadata.run_by (l’utilisateur authentifié) pour les charges de travail qui s’exécutent sur un cluster de groupe.
• Les journaux d’audit remis au stockage client n’enregistrent pas le identity_metadata.run_as (groupe d’autorisation) ou identity_metadata.run_by (l’utilisateur d’authentification) pour les charges de travail qui s’exécutent sur un cluster de groupe. Vous devez utiliser la table system.access.audit pour afficher les métadonnées d’identité.
• Lorsqu’il est attaché à un cluster de groupe, l’Explorateur catalogue ne filtre pas par ressources uniquement accessibles au groupe.
• Les gestionnaires de groupes qui ne sont pas des membres de groupe ne peuvent pas créer, modifier ou supprimer des clusters de groupe. Seuls les administrateurs de l’espace de travail et les membres du groupe peuvent le faire.
• Si un groupe est renommé, vous devez mettre à jour manuellement toutes les stratégies de calcul qui référencent le nom du groupe.
• Les clusters de groupe ne sont pas pris en charge pour les espaces de travail avec des listes de contrôle d’accès désactivées (isWorkspaceAclsEnabled == false) en raison du manque inhérent de contrôles de sécurité et d’accès aux données lorsque les listes de contrôle d’accès aux espaces de travail sont désactivées.
• La %run commande et d’autres actions exécutées dans le contexte du notebook utilisent toujours les autorisations de l’utilisateur plutôt que les autorisations du groupe. Cela est dû au fait que ces actions sont gérées par l’environnement de notebook, et non par l’environnement du cluster. D'autres commandes, telles que dbutils.notebook.run(), sont exécutées sur le cluster et utilisent donc les autorisations du groupe.
• La is_member(<group>) fonction retourne false lorsqu’elle est appelée sur un cluster de groupe, car le groupe n’est pas membre de lui-même. Pour vérifier correctement l’appartenance aux clusters de groupe et aux autres modes d’accès, utilisez is_member(<group>) OR current_user() == <group>.
• La création et l’accès aux points de terminaison de service de modèles ne sont pas pris en charge.
• La création et l’accès aux points de terminaison ou index de recherche vectorielle ne sont pas pris en charge.
• La suppression de fichiers et de dossiers n’est pas prise en charge dans les clusters de groupe.
• L’interface utilisateur de chargement de fichier ne prend pas en charge les clusters de groupe.