Accès au groupe de compute dédié

Cet article explique comment créer une ressource de compute assignée à un groupe en utilisant le mode d'accès **Dédié**.

Le mode d'accès par groupe dédié permet aux utilisateurs d'obtenir l'efficacité opérationnelle d'un cluster en mode d'accès standard tout en prenant également 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 et R.

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 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é est la dernière version du mode d'accès utilisateur unique. Avec un accès dédié, une ressource de compute peut être attribuée à un seul utilisateur ou groupe, n'autorisant que le ou les utilisateurs attribués à utiliser la ressource de compute.

Lorsqu'un utilisateur est connecté à une ressource de compute dédiée à un groupe (un cluster de groupe), les autorisations de l'utilisateur s'adaptent automatiquement aux autorisations du groupe, permettant ainsi à l'utilisateur de partager la ressource en toute sécurité avec les autres membres du groupe.

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

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.

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'utilisateur qui exécute 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'utilisateur qui s'authentifie et effectue l'action
• identity_metadata.run_as: Le groupe d’autorisation dont les permissions sont utilisées pour l’action.

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.

Limitations connues

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

• Les Jobs créés à l'aide de l'API et du SDK ne peuvent pas se voir attribuer d'accès de groupe. C'est parce que le paramètre run_as du Job ne prend en charge qu'un seul utilisateur ou Service Principal.
• Les Jobs qui utilisent Git échoueront car le répertoire temporaire que le Job utilise pour extraire le repo Git n'est pas inscriptible. Utilisez des Dossiers Git à la place.
• Les tables système de lignage n'enregistrent pas le identity_metadata.run_as (le groupe autorisant) ni le identity_metadata.run_by (l'utilisateur authentifiant) pour les charges de travail qui s'exécutent sur un cluster de groupe.
• Les Logs d'audit livrés au stockage client n'enregistrent pas le identity_metadata.run_as (le groupe d'autorisation) ou le identity_metadata.run_by (l'utilisateur d'authentification) pour les charges de travail qui s'exécutent sur un cluster de groupes. 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 de catalogues ne filtre pas par les assets uniquement accessibles au groupe.
• Les gestionnaires de groupe qui ne sont pas membres du groupe ne peuvent pas créer, modifier ou supprimer des clusters de groupe. Seuls les administrateurs de Workspace et les membres du groupe peuvent le faire.
• 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 pour les workspaces avec des ACL 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 ACL du workspace sont désactivées.
• La commande %run et les autres actions exécutées dans le contexte du notebook utilisent toujours les autorisations de l'utilisateur plutôt que les autorisations du groupe. C'est parce 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 autorisations du groupe.
• La fonction is_member(<group>) renvoie 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 correctement l'appartenance à des clusters de groupe et à d'autres modes d'accès, utilisez is_member(<group>) OR current_user() == <group>.
• La création et l'accès aux Endpoint de service de modèles ne sont pas pris en charge.
• La création et l'accès aux Endpoint de recherche IA ou aux index 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 d'upload de fichiers ne prend pas en charge les clusters de groupe.