Benutzer hinzufügen und Dienstkonten einrichten - Amazon SageMaker KI
Feinkörnige Zutrittskontrolle — unsere EmpfehlungPrivate und öffentliche Räume

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Benutzer hinzufügen und Dienstkonten einrichten

Feinkörnige Zutrittskontrolle — unsere Empfehlung

Benutzer werden anhand ihres Kubernetes-Benutzernamens unterschieden. Der Kubernetes-Benutzername des Benutzers ist in seinem Zugriffseintrag definiert. Um sicherzustellen, dass zwei menschliche Benutzer unterschiedliche Benutzernamen haben, gibt es zwei Optionen:

  1. Empfohlen — Mehrere menschliche Benutzer können dieselbe Rolle verwenden, solange jeder Benutzer seinen eigenen eindeutigen Sitzungsnamen hat, der zwischen den Sitzungen bestehen bleibt. Standardmäßig haben Kubernetes-Benutzernamen für IAM-Rollen das folgende Format. arn:aws:sts::{ACCOUNT_ID}:assumed-role/{ROLE_NAME}/{SESSION_NAME} Mit dieser Standardeinstellung werden Benutzer bereits nach dem Sitzungsnamen unterschieden. Ein Administrator hat mehrere Möglichkeiten, eindeutige Sitzungsnamen pro Benutzer durchzusetzen.

    • SSO-Anmeldung — Benutzer, die die SSO-Anmeldung verwenden, haben standardmäßig einen Sitzungsnamen, der mit ihrem AWS Benutzernamen verknüpft ist

    • Zentraler Verkaufsservice für Anmeldeinformationen — Für Unternehmenskunden gibt es möglicherweise einen internen Verkaufsdienst für Anmeldeinformationen, den Benutzer anrufen können, um Anmeldeinformationen mit ihrer Identität zu erhalten.

    • Rollenbasierte Durchsetzung — IAM-Benutzer müssen ihren eigenen Sitzungsnamen aws:username angeben, wenn sie in Ihrer Rolle eine IAM-Rolle übernehmen. AWS-Konto Die Dokumentation dazu finden Sie hier: https://aws.amazon.com/blogs/easily-control-naming-individualsecurity/ -/iam-role-sessions

  2. Wenn 2 Data Scientists unterschiedliche Zugriffseinträge verwenden (unterschiedliche IAM-Rolle oder Benutzer), werden sie immer als unterschiedliche Benutzer gezählt.

Zugangseintrag wird erstellt

Erforderliche IAM-Richtlinie für die Rolle eines Datenwissenschaftlers:

  • eks:DescribeCluster

Erforderliche Zugangsrichtlinien

  • AmazonSagemakerHyperpodSpacePolicy- Auf den Namespace beschränkt, sollte DS Leerzeichen erzeugen in

  • AmazonSagemakerHyperpodSpaceTemplatePolicy- ist auf den Namespace „jupyter-k8s-shared“ beschränkt

Private und öffentliche Räume

Wir unterstützen zwei Arten von Sharing-Mustern: „Öffentlich“ und „OwnerOnly“. Sowohl die Felder „AccessType“ als auch „OwnershipType“ verwenden diese beiden Werte.

  • AccessType: Auf öffentliche Bereiche kann jeder zugreifen, der über Berechtigungen im Namespace verfügt. Auf öffentliche Bereiche OwnerOnly können jedoch nur der Ersteller des Bereichs sowie Administratorbenutzer zugreifen. Administratorbenutzer werden anhand der folgenden Kriterien definiert:

  • OwnershipType: Öffentliche Bereiche können modified/deleted von jedem eingerichtet werden, der über Berechtigungen im Namespace verfügt, OwnerOnly entweder modified/deleted vom Ersteller oder vom Administrator.

Admin-Benutzer werden definiert durch:

  1. Teil der system:masters Kubernetes-Gruppe

  2. Teil der Kubernetes-Gruppe, die in der Umgebungsvariablen CLUSTER_ADMIN_GROUP im Helmdiagramm definiert ist.

Die Gruppen eines Benutzers können mithilfe von EKS-Zugriffseinträgen konfiguriert werden. Ein Bereich kann als „Öffentlich“ oder „OwnerOnly“ definiert werden, indem die Spezifikation im Objekt konfiguriert wird:

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