Ajouter des utilisateurs et configurer des comptes de service - Amazon SageMaker AI
Contrôle d'accès précis : notre recommandationEspaces privés et publics

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 garantir que deux utilisateurs humains ont des noms d'utilisateur distincts, deux options s'offrent à vous :

  1. Recommandé - Plusieurs utilisateurs humains peuvent utiliser le même rôle tant que chacun possède son propre nom de session distinct qui sera conservé entre les sessions. Par défaut, les noms d'utilisateur Kubernetes pour les rôles IAM sont au format suivant. 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 imposer 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 de vente d'informations d'identification centralisé - Les entreprises clientes peuvent disposer d'un service de vente 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 : obligez les utilisateurs IAM à définir leur nom de session aws:username comme rôle lorsqu'ils assument un rôle IAM dans votre. Compte AWS La documentation sur la façon de procéder est disponible ici : https://aws.amazon.com/blogs/sécurité/ easily-control-naming-individual -iam-role-sessions/

  2. Si deux data scientists utilisent des entrées d'accès différentes (rôle ou utilisateur IAM différent), ils seront toujours considéré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 d'entrée requises

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

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

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, tandis que seuls le créateur de l'espace ainsi que les utilisateurs administrateurs OwnerOnly peuvent y accéder. Les utilisateurs administrateurs sont définis selon les critères suivants :

  • OwnershipType: Les espaces publics peuvent être réservés modified/deleted à toute personne disposant d'autorisations dans l'espace de noms, OwnerOnly qu'il s' modified/deleted agisse du créateur ou de l'administrateur.

Les utilisateurs administrateurs sont définis par :

  1. Membre du groupe system:masters Kubernetes

  2. Fait partie du groupe Kubernetes défini dans la variable d'environnement CLUSTER_ADMIN_GROUP du graphique de barre.

Les groupes d'utilisateurs 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