View a markdown version of this page

Ajouter des utilisateurs et configurer des comptes de service - Amazon SageMaker AI

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Ajouter des utilisateurs et configurer des comptes de service

Contrôle d'accès précis : notre recommandation

Les utilisateurs sont différenciés en fonction de leur nom d'utilisateur Kubernetes. Le nom d'utilisateur Kubernetes de l'utilisateur est défini dans son entrée d'accès. Pour vous assurer que deux utilisateurs humains ont des noms d'utilisateur distincts, il existe deux options :

  1. Recommandé - Plusieurs utilisateurs humains peuvent utiliser le même rôle à condition que chacun ait son propre nom de session distinct qui persistera entre les sessions. Par défaut, les noms d'utilisateur Kubernetes pour les rôles IAM sont au format. arn:aws:sts::{ACCOUNT_ID}:assumed-role/{ROLE_NAME}/{SESSION_NAME} Avec cette valeur par défaut, les utilisateurs seront déjà différenciés par nom de session. Un administrateur dispose de plusieurs moyens pour appliquer des noms de session uniques par utilisateur.

    • Connexion SSO - Les utilisateurs utilisant la connexion SSO auront par défaut un nom de session lié à leur nom d'utilisateur AWS

    • Service central de distribution d'informations d'identification - Les clients professionnels peuvent disposer d'un service de distribution d'informations d'identification interne que les utilisateurs peuvent appeler pour obtenir des informations d'identification avec leur identité.

    • Application basée sur les rôles : demandez aux utilisateurs IAM de définir leur aws:username nom de session de rôle lorsqu'ils assument un rôle IAM dans votre. Compte AWS Vous trouverez de la documentation sur la façon de procéder ici : https://aws.amazon.com/blogs/security/easily-control-naming-individual-iam-role-sessions/

  2. Si 2 Data Scientists utilisent des entrées d'accès différentes (rôle IAM ou utilisateur différents), ils seront toujours comptés comme des utilisateurs différents.

Création d'une entrée d'accès

Politique IAM requise pour le rôle de data scientist :

  • eks:DescribeCluster

Politiques d'accès et de saisie obligatoires

  • AmazonSagemakerHyperpodSpacePolicy- limité à l'espace de noms DS devrait créer des espaces dans

  • AmazonSagemakerHyperpodSpaceTemplatePolicy- limité à l'espace de noms « jupyter-k8s-shared »

  • AmazonSagemakerHyperpodUserClusterPolicy- limité au cluster

Espaces privés et publics

Nous prenons en charge deux types de modèles de partage : « Public » et « OwnerOnly ». Les champs « AccessType » et « OwnershipType » utilisent ces deux valeurs.

  • AccessType: les espaces publics sont accessibles à toute personne disposant d'autorisations dans l'espace de noms, alors que seuls le créateur de l'espace et les administrateurs OwnerOnly peuvent y accéder. Les utilisateurs administrateurs sont définis selon les critères suivants :

  • OwnershipType: Les espaces publics peuvent être modified/deleted occupés par toute personne disposant d'autorisations dans l'espace de noms, OwnerOnly modified/deleted par le créateur ou par l'administrateur.

Les utilisateurs administrateurs sont définis comme suit :

  1. Membre du groupe system:masters Kubernetes

  2. Fait partie du groupe Kubernetes défini dans la variable d'environnement CLUSTER_ADMIN_GROUP du helm chart.

Les groupes d'un utilisateur peuvent être configurés à l'aide des entrées d'accès EKS. Un espace peut être défini comme « Public » ou « OwnerOnly » en configurant la spécification dans l'objet :

apiVersion: workspace.jupyter.org/v1alpha1 kind: Workspace metadata: labels: app.kubernetes.io/name: jupyter-k8s name: example-workspace spec: displayName: "Example Workspace" image: "public.ecr.aws/sagemaker/sagemaker-distribution:3.4.2-cpu" desiredStatus: "Running" ownershipType: "Public"/"OwnerOnly" accessType: "Public"/"OwnerOnly" # more fields here