Team- und Benutzerverwaltung mit Amazon SageMaker und AWS SSO

Neuauflage von Plato

Verfolger: 0

Amazon SageMaker-Studio ist eine webbasierte integrierte Entwicklungsumgebung (IDE) für maschinelles Lernen (ML), mit der Sie Ihre ML-Modelle erstellen, trainieren, debuggen, bereitstellen und überwachen können. Jeder integrierte Benutzer in Studio verfügt über einen eigenen dedizierten Satz von Ressourcen, z. B. Compute-Instanzen, ein Basisverzeichnis auf einer Amazon Elastic File System (Amazon EFS)-Volume und ein dediziertes AWS Identity and Access Management and (IAM) Ausführungsrolle.

Eine der häufigsten realen Herausforderungen beim Einrichten des Benutzerzugriffs für Studio ist die Verwaltung mehrerer Benutzer, Gruppen und Data-Science-Teams für den Datenzugriff und die Ressourcenisolierung.

Viele Kunden implementieren die Benutzerverwaltung mit föderierten Identitäten mit AWS-Einzelanmeldung (AWS SSO) und einem externen Identitätsanbieter (IdP) wie Active Directory (AD) oder AWS Managed Microsoft AD-Verzeichnis. Es ist mit dem AWS ausgerichtet Empfohlene Praxis der Verwendung temporärer Anmeldeinformationen für den Zugriff auf AWS-Konten.

An Amazon Sage Maker Domain unterstützt AWS SSO und kann in AWS SSO konfiguriert werden Authentifizierungsmodus. In diesem Fall hat jeder berechtigte AWS SSO-Benutzer seine eigene Studio-Benutzerprofil. Benutzer, denen Zugriff auf Studio gewährt wird, haben eine eindeutige Anmelde-URL, die Studio direkt öffnet, und sie melden sich mit ihren AWS SSO-Anmeldeinformationen an. Organisationen verwalten ihre Benutzer in AWS SSO statt in der SageMaker-Domäne. Sie können mehreren Benutzern gleichzeitig Zugriff auf die Domäne zuweisen. Sie können Studio-Benutzerprofile für jeden Benutzer verwenden, um seine Sicherheitsberechtigungen in Studio-Notebooks über eine IAM-Rolle zu definieren, die an das Benutzerprofil angehängt ist und als an bezeichnet wird Ausführungsrolle. Diese Rolle steuert Berechtigungen für SageMaker-Vorgänge gemäß ihren IAM-Berechtigungsrichtlinien.

Im AWS SSO-Authentifizierungsmodus gibt es immer eine Eins-zu-eins-Zuordnung zwischen Benutzern und Benutzerprofilen. Die SageMaker-Domäne verwaltet die Erstellung von Benutzerprofilen basierend auf der AWS SSO-Benutzer-ID. Sie können keine Benutzerprofile über die erstellen AWS-Managementkonsole. Dies funktioniert gut, wenn ein Benutzer Mitglied nur eines Data-Science-Teams ist oder wenn Benutzer in ihren Projekten und Teams dieselben oder sehr ähnliche Zugriffsanforderungen haben. In einem häufigeren Anwendungsfall, wenn ein Benutzer an mehreren ML-Projekten teilnehmen und Mitglied mehrerer Teams mit leicht unterschiedlichen Berechtigungsanforderungen sein kann, benötigt der Benutzer Zugriff auf verschiedene Studio-Benutzerprofile mit unterschiedlichen Ausführungsrollen und Berechtigungsrichtlinien. Da Sie Benutzerprofile nicht unabhängig von AWS SSO im AWS SSO-Authentifizierungsmodus verwalten können, können Sie keine XNUMX:n-Zuordnung zwischen Benutzern und Studio-Benutzerprofilen implementieren.

Wenn Sie eine starke Trennung von Sicherheitskontexten einrichten müssen, z. B. für verschiedene Datenkategorien, oder die Sichtbarkeit der Aktivitäten und Ressourcen einer Gruppe von Benutzern für eine andere vollständig verhindern müssen, besteht die empfohlene Vorgehensweise darin, mehrere SageMaker-Domänen zu erstellen. Zum Zeitpunkt der Erstellung dieses Artikels können Sie nur eine Domäne pro AWS-Konto und Region erstellen. Um die starke Trennung zu implementieren, können Sie als Workaround mehrere AWS-Konten mit einer Domäne pro Konto verwenden.

Die zweite Herausforderung besteht darin, schränken Sie den Zugriff auf die Studio-IDE ein nur für Benutzer innerhalb eines Unternehmensnetzwerks oder einer bestimmten VPC. Sie können dies erreichen, indem Sie verwenden IAM-basierte Zugriffssteuerungsrichtlinien. In diesem Fall muss die SageMaker-Domäne mit konfiguriert werden IAM-Authentifizierungsmodus, da die identitätsbasierten IAM-Richtlinien vom Anmeldemechanismus im AWS-SSO-Modus nicht unterstützt werden. Die Post Sicherer Zugriff auf Amazon SageMaker Studio mit AWS SSO und einer SAML-Anwendung löst diese Herausforderung und zeigt, wie der Netzwerkzugriff auf eine SageMaker-Domäne gesteuert wird.

Diese Lösung adressiert diese Herausforderungen der AWS SSO-Benutzerverwaltung für Studio für einen allgemeinen Anwendungsfall mit mehreren Benutzergruppen und einer Viele-zu-Viele-Zuordnung zwischen Benutzern und Teams. Die Lösung beschreibt die Verwendung von a benutzerdefinierte SAML 2.0-Anwendung als Mechanismus zum Auslösen der Benutzerauthentifizierung für Studio und zur Unterstützung mehrerer Studio-Benutzerprofile pro AWS SSO-Benutzer.

Sie können diesen Ansatz verwenden, um ein benutzerdefiniertes Benutzerportal mit Anwendungen zu implementieren, die durch den SAML 2.0-Autorisierungsprozess unterstützt werden. Ihr benutzerdefiniertes Benutzerportal kann maximale Flexibilität bei der Verwaltung und Anzeige von Benutzeranwendungen haben. Beispielsweise kann das Benutzerportal einige ML-Projektmetadaten anzeigen, um die Identifizierung einer Anwendung, auf die zugegriffen werden soll, zu erleichtern.

Den Quellcode der Lösung finden Sie in unserer GitHub-Repository.

Lösungsüberblick

Die Lösung implementiert die folgende Architektur.

Die wichtigsten High-Level-Architekturkomponenten sind wie folgt:

Identitätsanbieter – Benutzer und Gruppen werden in einer externen Identitätsquelle verwaltet, beispielsweise in Azure AD. Benutzerzuweisungen zu AD-Gruppen definieren, welche Berechtigungen ein bestimmter Benutzer hat und auf welches Studio-Team er Zugriff hat. Die Identitätsquelle muss mit AWS SSO synchronisiert werden.
AWS-SSO – AWS SSO verwaltet SSO-Benutzer, SSO-Berechtigungssätze und Anwendungen. Diese Lösung verwendet eine benutzerdefinierte SAML 2.0-Anwendung, um berechtigten AWS SSO-Benutzern Zugriff auf Studio zu gewähren. Die Lösung verwendet auch die SAML-Attributzuordnung, um die SAML-Assertion mit bestimmten zugriffsrelevanten Daten wie Benutzer-ID und Benutzerteam zu füllen. Da die Lösung eine SAML-API erstellt, können Sie jeden IdP verwenden, der SAML-Zusicherungen unterstützt, um diese Architektur zu erstellen. Sie können beispielsweise Okta oder sogar Ihre eigene Webanwendung verwenden, die eine Zielseite mit einem Benutzerportal und Anwendungen bereitstellt. Für diesen Beitrag verwenden wir AWS SSO.
Benutzerdefinierte SAML 2.0-Anwendungen – Die Lösung erstellt eine Anwendung pro Studio-Team und weist einem Benutzer oder einer Benutzergruppe basierend auf Berechtigungen eine oder mehrere Anwendungen zu. Benutzer können basierend auf zugewiesenen Berechtigungen von ihrem AWS SSO-Benutzerportal aus auf diese Anwendungen zugreifen. Jede Anwendung wird mit konfiguriert Amazon API-Gateway Endpunkt-URL als SAML-Backend.
SageMaker-Domäne – Die Lösung stellt eine SageMaker-Domäne in einem AWS-Konto bereit und erstellt ein dediziertes Benutzerprofil für jede Kombination aus AWS SSO-Benutzer und Studio-Team, dem der Benutzer zugewiesen ist. Die Domäne muss in IAM konfiguriert werden Authentifizierungsmodus.
Studio-Benutzerprofile – Die Lösung erstellt automatisch ein dediziertes Benutzerprofil für jede Benutzer-Team-Kombination. Wenn ein Benutzer beispielsweise Mitglied in zwei Studio-Teams ist und über entsprechende Berechtigungen verfügt, stellt die Lösung zwei separate Benutzerprofile für diesen Benutzer bereit. Jedes Profil gehört immer nur einem Benutzer. Da Sie für jede mögliche Kombination aus einem Benutzer und einem Team ein Studio-Benutzerprofil haben, müssen Sie Ihre Kontobeschränkungen für Benutzerprofile berücksichtigen, bevor Sie diesen Ansatz implementieren. Wenn Ihr Limit beispielsweise 500 Benutzerprofile beträgt und jeder Benutzer Mitglied zweier Teams ist, verbrauchen Sie dieses Limit 2.5-mal schneller und können daher 250 Benutzer integrieren. Bei einer hohen Anzahl von Benutzern empfehlen wir die Implementierung mehrerer Domänen und Konten zur Trennung des Sicherheitskontexts. Um den Machbarkeitsnachweis zu demonstrieren, verwenden wir zwei Benutzer, Benutzer 1 und Benutzer 2, und zwei Studio-Teams, Team 1 und Team 2. Benutzer 1 gehört zu beiden Teams, während Benutzer 2 nur zu Team 2 gehört. Benutzer 1 kann auf Studio-Umgebungen für beide Teams zugreifen, während Benutzer 2 nur auf die Studio-Umgebung für Team 2 zugreifen kann.
Studio-Ausführungsrollen – Jedes Studio-Benutzerprofil verwendet eine dedizierte Ausführungsrolle mit Berechtigungsrichtlinien mit der erforderlichen Zugriffsebene für das jeweilige Team, dem der Benutzer angehört. Studio-Ausführungsrollen implementieren eine effektive Berechtigungsisolierung zwischen einzelnen Benutzern und ihren Teamrollen. Sie verwalten den Daten- und Ressourcenzugriff für jede Rolle und nicht auf individueller Benutzerebene.

Die Lösung implementiert auch eine attributbasierte Zugriffskontrolle (ABAC) mit SAML 2.0-Attributen, Tags für Studio-Benutzerprofile und Tags für SageMaker-Ausführungsrollen.

In dieser speziellen Konfiguration gehen wir davon aus, dass AWS SSO-Benutzer keine Berechtigungen zum Anmelden beim AWS-Konto haben und keine entsprechenden AWS SSO-gesteuerten IAM-Rollen im Konto haben. Jeder Benutzer meldet sich über eine vorsignierte URL von einem AWS-SSO-Portal bei seiner Studio-Umgebung an, ohne die Konsole in seinem AWS-Konto aufrufen zu müssen. In einer realen Umgebung müssen Sie möglicherweise eine Einrichtung vornehmen AWS SSO-Berechtigungssätze für Benutzer, um autorisierten Benutzern zu erlauben, eine IAM-Rolle anzunehmen und sich bei einem AWS-Konto anzumelden. Beispielsweise können Sie einem Benutzer Berechtigungen für die Data Scientist-Rolle erteilen, damit er mit Kontoressourcen interagieren kann und über die Zugriffsebene verfügt, die er zum Erfüllen seiner Rolle benötigt.

Lösungsarchitektur und Workflow

Das folgende Diagramm zeigt den End-to-End-Anmeldeablauf für einen AWS SSO-Benutzer.

Ein AWS SSO-Benutzer wählt eine entsprechende Studio-Anwendung in seinem AWS SSO-Portal aus. AWS SSO bereitet eine SAML-Assertion (1) mit konfigurierten SAML-Attributzuordnungen vor. Eine benutzerdefinierte SAML-Anwendung wird mit der API Gateway-Endpunkt-URL als Assertion Consumer Service (ACS) konfiguriert und benötigt Zuordnungsattribute, die die AWS SSO-Benutzer-ID und Team-ID enthalten. Wir gebrauchen ssouserid und teamid benutzerdefinierte Attribute, um alle erforderlichen Informationen an das SAML-Backend zu senden.

Das API Gateway ruft eine SAML-Backend-API auf. Ein AWS Lambda Funktion (2) implementiert die API, analysiert die SAML-Antwort, um die Benutzer-ID und die Team-ID zu extrahieren. Die Funktion verwendet sie, um eine teamspezifische Konfiguration wie eine Ausführungsrolle und eine SageMaker-Domänen-ID abzurufen. Die Funktion prüft, ob ein erforderliches Benutzerprofil in der Domäne vorhanden ist, und erstellt ein neues mit den entsprechenden Konfigurationseinstellungen, wenn kein Profil vorhanden ist. Anschließend generiert die Funktion durch Aufrufen eine von Studio vorsignierte URL für ein bestimmtes Studio-Benutzerprofil CreatePresignedDomainUrl API (3) über einen SageMaker-API-VPC-Endpunkt. Die Lambda-Funktion gibt schließlich die vorsignierte URL mit der HTTP 302-Umleitungsantwort zurück, um den Benutzer bei Studio anzumelden.

Die Lösung implementiert eine Nicht-Produktions-Beispielversion eines SAML-Backends. Die Lambda-Funktion analysiert die SAML-Assertion und verwendet nur Attribute in der <saml2:AttributeStatement> Element zur Konstruktion von a CreatePresignedDomainUrl API-Aufruf. In Ihrer Produktionslösung müssen Sie eine ordnungsgemäße SAML-Backend-Implementierung verwenden, die eine Validierung einer SAML-Antwort, eine Signatur und Zertifikate, die Verhinderung von Wiedergabe und Umleitung sowie alle anderen Funktionen eines SAML-Authentifizierungsprozesses umfassen muss. Sie können zum Beispiel a verwenden python3-saml SAML-Backend-Implementierung or OneLogin Open-Source-SAML-Toolkit um ein sicheres SAML-Backend zu implementieren.

Dynamische Erstellung von Studio-Benutzerprofilen

Die Lösung erstellt automatisch ein Studio-Benutzerprofil für jede Benutzer-Team-Kombination, sobald der AWS SSO-Anmeldeprozess eine vorsignierte URL anfordert. Für diesen Machbarkeitsnachweis und diese Einfachheit erstellt die Lösung Benutzerprofile basierend auf den konfigurierten Metadaten in AWS SAM-Vorlage:

Metadata:
  Team1:
    DomainId: !GetAtt SageMakerDomain.Outputs.SageMakerDomainId
    SessionExpiration: 43200
    Tags:
      - Key: Team
        Value: Team1
    UserSettings:
      ExecutionRole: !GetAtt IAM.Outputs.SageMakerStudioExecutionRoleTeam1Arn
  Team2:
    DomainId !GetAtt SageMakerDomain.Outputs.SageMakerDomainId
    SessionExpiration: 43200
    Tags:
      - Key: Team
        Value: Team2
    UserSettings:
      ExecutionRole: !GetAtt IAM.Outputs.SageMakerStudioExecutionRoleTeam2Arn

Sie können eigene Teams, benutzerdefinierte Einstellungen und Tags konfigurieren, indem Sie sie zur Metadatenkonfiguration für die AWS CloudFormation-Ressource hinzufügen GetUserProfileMetadata.

Weitere Informationen zu Konfigurationselementen von UserSettings, beziehen auf create_user_profile in boto3.

IAM-Rollen

Das folgende Diagramm zeigt die IAM-Rollen in dieser Lösung.

Die Rollen sind wie folgt:

Ausführungsrolle des Studios – Ein Studio-Benutzerprofil verwendet eine dedizierte Studio-Ausführungsrolle mit spezifischen Daten- und Ressourcenberechtigungen für jedes Team oder jede Benutzergruppe. Diese Rolle kann auch Tags verwenden, um ABAC für den Daten- und Ressourcenzugriff zu implementieren. Weitere Informationen finden Sie unter SageMaker-Rollen.

SAML-Backend-Lambda-Ausführungsrolle – Diese Ausführungsrolle enthält die Berechtigung zum Aufrufen der CreatePresignedDomainUrl API. Sie können die Berechtigungsrichtlinie so konfigurieren, dass zusätzliche bedingte Prüfungen mit eingeschlossen werden Condition Schlüssel. Um beispielsweise den Zugriff auf Studio nur von einem bestimmten Bereich von IP-Adressen innerhalb Ihres privaten Unternehmensnetzwerks zuzulassen, verwenden Sie den folgenden Code:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sagemaker:CreatePresignedDomainUrl"
            ],
            "Resource": "arn:aws:sagemaker:<Region>:<Account_id>:user-profile/*/*",
            "Effect": "Allow"
        },
        {
            "Condition": {
                "NotIpAddress": {
                    "aws:VpcSourceIp": "10.100.10.0/24"
                }
            },
            "Action": [
                "sagemaker:*"
            ],
            "Resource": "arn:aws:sagemaker:<Region>:<Account_id>:user-profile/*/*",
            "Effect": "Deny"
        }
    ]
}

Weitere Beispiele zur Verwendung von Bedingungen in IAM-Richtlinien finden Sie unter Steuern Sie den Zugriff auf die SageMaker-API mithilfe identitätsbasierter Richtlinien.

SageMaker – SageMaker übernimmt die Studio-Ausführungsrolle in Ihrem Namen, wie durch eine entsprechende Vertrauensrichtlinie für die Ausführungsrolle gesteuert. Dadurch kann der Dienst auf Daten und Ressourcen zugreifen und Aktionen in Ihrem Namen ausführen. Die Studio-Ausführungsrolle muss eine Vertrauensrichtlinie enthalten, die es SageMaker ermöglicht, diese Rolle zu übernehmen.
AWS SSO-Berechtigungssatz-IAM-Rolle – Sie können Ihre AWS SSO-Benutzer AWS-Konten in Ihrer AWS-Organisation über zuweisen AWS SSO-Berechtigungssätze. Ein Berechtigungssatz ist eine Vorlage, die eine Sammlung von benutzerrollenspezifischen IAM-Richtlinien definiert. Sie verwalten Berechtigungssätze in AWS SSO und AWS SSO steuert die entsprechenden IAM-Rollen in jedem Konto.
AWS Organizations Service Control-Richtlinien - Wenn du benutzt AWS-Organisationen, Sie können implementieren Richtlinien zur Dienststeuerung (SCPs), um die maximal verfügbaren Berechtigungen für alle Konten und alle IAM-Rollen in Ihrer Organisation zentral zu steuern. Um beispielsweise den Zugriff auf Studio zentral über die Konsole zu verhindern, können Sie die folgende SCP implementieren und an die Konten mit der SageMaker-Domäne anhängen:
```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "sagemaker:*"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Condition": {
        "NotIpAddress": {
          "aws:VpcSourceIp": "<AuthorizedPrivateSubnet>"
        }
      },
      "Action": [
        "sagemaker:CreatePresignedDomainUrl"
      ],
      "Resource": "*",
      "Effect": "Deny"
    }
  ]
}
```

Von der Lösung bereitgestellte Rollen

Das AWS CloudFormation Stapel für diese Lösung werden drei Studio-Ausführungsrollen erstellt, die in der SageMaker-Domäne verwendet werden:

SageMakerStudioExecutionRoleDefault
SageMakerStudioExecutionRoleTeam1
SageMakerStudioExecutionRoleTeam2

Keine der Rollen haben die AmazonSageMakerFullAccess Richtlinie angehängt, und jeder hat nur einen begrenzten Satz von Berechtigungen. In Ihrer realen SageMaker-Umgebung müssen Sie die Berechtigungen der Rolle basierend auf Ihren spezifischen Anforderungen ändern.

SageMakerStudioExecutionRoleDefault hat nur die benutzerdefinierte Richtlinie SageMakerReadOnlyPolicy angehängt mit einer restriktiven Liste erlaubter Aktionen.

Beide Teamrollen, SageMakerStudioExecutionRoleTeam1 und SageMakerStudioExecutionRoleTeam2, haben zusätzlich zwei benutzerdefinierte Richtlinien, SageMakerAccessSupportingServicesPolicy und SageMakerStudioDeveloperAccessPolicy, die die Nutzung bestimmter Dienste und eine Nur-Verweigern-Richtlinie ermöglicht, SageMakerDeniedServicesPolicy, mit expliziter Verweigerung bei einigen SageMaker-API-Aufrufen.

Die Studio-Entwicklerzugriffsrichtlinie erzwingt die Einstellung der Team -Tag gleich dem gleichen Wert wie die eigene Ausführungsrolle des Benutzers zum Aufrufen von SageMaker Create* API:

{
    "Condition": {
        "ForAnyValue:StringEquals": {
            "aws:TagKeys": [
                "Team"
            ]
        },
        "StringEqualsIfExists": {
            "aws:RequestTag/Team": "${aws:PrincipalTag/Team}"
        }
    },
    "Action": [
        "sagemaker:Create*"
    ],
    "Resource": [
        "arn:aws:sagemaker:*:<ACCOUNT_ID>:*"
    ],
    "Effect": "Allow",
    "Sid": "AmazonSageMakerCreate"
}

Darüber hinaus ermöglicht es die Verwendung von Lösch-, Stopp-, Aktualisierungs- und Startvorgängen nur für Ressourcen, die mit demselben Team-Tag wie die Ausführungsrolle des Benutzers gekennzeichnet sind:

{
    "Condition": {
        "StringEquals": {
            "aws:PrincipalTag/Team": "${sagemaker:ResourceTag/Team}"
        }
    },
    "Action": [
        "sagemaker:Delete*",
        "sagemaker:Stop*",
        "sagemaker:Update*",
        "sagemaker:Start*",
        "sagemaker:DisassociateTrialComponent",
        "sagemaker:AssociateTrialComponent",
        "sagemaker:BatchPutMetrics"
    ],
    "Resource": [
        "arn:aws:sagemaker:*:<ACCOUNT_ID>:*"
    ],
    "Effect": "Allow",
    "Sid": "AmazonSageMakerUpdateDeleteExecutePolicy"
}

Weitere Informationen zu Rollen und Richtlinien finden Sie unter siehe Konfigurieren von Amazon SageMaker Studio für Teams und Gruppen mit vollständiger Ressourcenisolierung.

Netzwerkinfrastruktur

Die Lösung implementiert eine vollständig isolierte SageMaker-Domänenumgebung, in der der gesamte Netzwerkverkehr durchgeht AWS PrivateLink Verbindungen. Optional können Sie den Internetzugang von den Studio-Notebooks aus aktivieren. Die Lösung schafft auch drei VPC-Sicherheitsgruppen um den Datenverkehr zwischen allen Lösungskomponenten wie der SAML-Backend-Lambda-Funktion zu steuern, VPC-Endpunkte, und Studio-Notizbücher.

Für diesen Machbarkeitsnachweis und diese Einfachheit erstellt die Lösung ein SageMaker-Subnetz in einem einzigen Verfügbarkeitszone. Für Ihre Produktionseinrichtung müssen Sie mehrere private Subnetze über mehrere Availability Zones hinweg verwenden und sicherstellen, dass jedes Subnetz die richtige Größe hat, wobei von mindestens fünf IPs pro Benutzer auszugehen ist.

Diese Lösung stellt die gesamte erforderliche Netzwerkinfrastruktur bereit. Die CloudFormation-Vorlage ./cfn-templates/vpc.yaml enthält den Quellcode.

Bereitstellungsschritte

Um die Lösung bereitzustellen und zu testen, müssen Sie die folgenden Schritte ausführen:

Stellen Sie den Stack der Lösung über eine bereit AWS Serverless-Anwendungsmodell (AWS SAM) Vorlage.
Erstellen Sie AWS SSO-Benutzer oder verwenden Sie vorhandene AWS SSO-Benutzer.
Erstellen Sie benutzerdefinierte SAML 2.0-Anwendungen und weisen Sie den Anwendungen AWS SSO-Benutzer zu.

Den vollständigen Quellcode für die Lösung finden Sie in unserem GitHub Quelle.

Voraussetzungen:

Um diese Lösung zu verwenden, die AWS-Befehlszeilenschnittstelle (AWS-CLI), AWS SAM-CLI und Python3.8 oder höher muss installiert werden.

Das Bereitstellungsverfahren geht davon aus, dass Sie AWS SSO aktiviert und für die konfiguriert haben AWS-Organisationen in dem Konto, in dem die Lösung bereitgestellt wird.

Informationen zum Einrichten von AWS SSO finden Sie in den Anweisungen in GitHub.

Lösungsbereitstellungsoptionen

Sie können aus mehreren Lösungsbereitstellungsoptionen wählen, um die beste Lösung für Ihre vorhandene AWS-Umgebung zu finden. Sie können auch die Bereitstellungsoptionen für das Netzwerk und die SageMaker-Domäne auswählen. Ausführliche Informationen zu den verschiedenen Bereitstellungsoptionen finden Sie unter README-Datei.

Stellen Sie die AWS SAM-Vorlage bereit

Führen Sie die folgenden Schritte aus, um die AWS SAM-Vorlage bereitzustellen:

Klonen Sie den Quellcode Quelle an Ihr lokales Umfeld:

git clone https://github.com/aws-samples/users-and-team-management-with-amazon-sagemaker-and-aws-sso.git

Erstellen Sie die AWS SAM-Anwendung:
Stellen Sie die Anwendung bereit:
```
sam deploy --guided
```
Stellen Sie Stack-Parameter entsprechend Ihrer vorhandenen Umgebung und den gewünschten Bereitstellungsoptionen bereit, wie z. B. vorhandene VPC, vorhandene private und öffentliche Subnetze und vorhandene SageMaker-Domäne, wie in beschrieben Lösungsbereitstellungsoptionen Kapitel der README-Datei.

Sie können alle Parameter auf ihren Standardwerten belassen, um neue Netzwerkressourcen und eine neue SageMaker-Domäne bereitzustellen. Siehe detaillierte Parameterverwendung in der README Datei, wenn Sie Standardeinstellungen ändern müssen.

Warten Sie, bis die Stack-Bereitstellung abgeschlossen ist. Die End-to-End-Bereitstellung einschließlich Bereitstellung aller Netzwerkressourcen und einer SageMaker-Domäne dauert etwa 20 Minuten.

Führen Sie den folgenden Befehl im Terminal aus, um die Stack-Ausgabe anzuzeigen:

export STACK_NAME=<SAM stack name>

aws cloudformation describe-stacks 
--stack-name $STACK_NAME
--output table 
--query "Stacks[0].Outputs[*].[OutputKey, OutputValue]"

Erstellen Sie SSO-Benutzer

Folgen Sie den Anweisungen zu Fügen Sie AWS SSO-Benutzer hinzu um zwei Benutzer mit den Namen User1 und User2 zu erstellen, oder verwenden Sie zwei beliebige Ihrer vorhandenen AWS SSO-Benutzer, um die Lösung zu testen. Stellen Sie sicher, dass Sie AWS SSO in derselben AWS-Region verwenden, in der Sie die Lösung bereitgestellt haben.

Erstellen Sie benutzerdefinierte SAML 2.0-Anwendungen

Führen Sie die folgenden Schritte aus, um die erforderlichen benutzerdefinierten SAML 2.0-Anwendungen für Team 1 und Team 2 zu erstellen:

Öffnen Sie die AWS SSO-Konsole im AWS-Verwaltungskonto Ihrer AWS-Organisation in derselben Region, in der Sie den Lösungs-Stack bereitgestellt haben.
Auswählen Anwendungen im Navigationsbereich.
Auswählen Fügen Sie eine neue Anwendung hinzu.
Auswählen Fügen Sie eine benutzerdefinierte SAML 2.0-Anwendung hinzu.
Aussichten für Angezeigter Name, geben Sie beispielsweise einen Anwendungsnamen ein SageMaker Studio Team 1.
Verlassen Start-URL der Anwendung und Relaiszustand leer.
Auswählen Wenn Sie keine Metadatendatei haben, können Sie Ihre Metadatenwerte manuell eingeben.
Aussichten für ACS-URL der Anwendung, geben Sie die URL ein, die in bereitgestellt wird SAMLBackendEndpoint Schlüssel der AWS SAM-Stack-Ausgabe.
Aussichten für Anwendungs-SAML-Zielgruppe, geben Sie die URL ein, die in bereitgestellt wird SAMLAudience Schlüssel der AWS SAM-Stack-Ausgabe.
Auswählen Änderungen speichern.
Navigieren Sie zu der Attributzuordnungen Tab.
Setze die Betreff zu E-Mail und Format zu E-Mail-Addresse.
Fügen Sie die folgenden neuen Attribute hinzu:
1. ssouserid einstellen ${user:AD_GUID}
2. teamid einstellen Team1 or Team2, jeweils für jede Anwendung
Auswählen Änderungen speichern.
Auf dem Zugewiesene Benutzer Tab, wählen Sie Benutzer zuweisen.
Wählen Sie Benutzer 1 für die Anwendung Team 1 und sowohl Benutzer 1 als auch Benutzer 2 für die Anwendung Team 2.
Auswählen Benutzer zuweisen.

Testen Sie die Lösung

Führen Sie die folgenden Schritte aus, um die Lösung zu testen:

Gehen Sie zum AWS SSO-Benutzerportal https://<Identity Store ID>.awsapps.com/start und melden Sie sich als Benutzer 1 an.
Im Portal werden zwei SageMaker-Anwendungen angezeigt.
Auswählen SageMaker Studio-Team 1.
Sie werden in einem neuen Browserfenster zur Studio-Instanz für Team 1 umgeleitet.
Wenn Sie Studio zum ersten Mal starten, erstellt SageMaker eine JupyterServer-Anwendung. Dieser Vorgang dauert einige Minuten.
Im Studio, auf der Reichen Sie das Menü, wählen Sie Neu und Terminal um ein neues Terminal zu starten.
Geben Sie in der Terminal-Befehlszeile den folgenden Befehl ein:
```
aws sts get-caller-identity
```
Der Befehl gibt die Studio-Ausführungsrolle zurück.

In unserem Setup muss diese Rolle für jedes Team unterschiedlich sein. Sie können auch überprüfen, ob jeder Benutzer in jeder Instanz von Studio sein eigenes Home-Verzeichnis auf einem gemounteten Amazon EFS-Volume hat.
Kehren Sie zum AWS SSO-Portal zurück, immer noch als Benutzer 1 angemeldet, und wählen Sie aus SageMaker Studio-Team 2.
Sie werden zu einer Team 2 Studio-Instanz umgeleitet.
Der Startvorgang kann wieder einige Minuten dauern, da SageMaker eine neue JupyterServer-Anwendung für Benutzer 2 startet.
Melden Sie sich als Benutzer 2 im AWS SSO-Portal an.
Benutzer 2 ist nur eine Anwendung zugewiesen: SageMaker Studio Team 2.

Wenn Sie eine Instanz von Studio über diese Benutzeranwendung starten, können Sie überprüfen, ob sie dieselbe SageMaker-Ausführungsrolle verwendet wie die Instanz von Team 1 von Benutzer 2. Jede Studio-Instanz ist jedoch vollständig isoliert. Benutzer 2 hat sein eigenes Home-Verzeichnis auf einem Amazon EFS-Volume und eine eigene Instanz der JupyterServer-Anwendung. Sie können dies überprüfen, indem Sie für jeden Benutzer einen Ordner und einige Dateien erstellen und sehen, dass das Home-Verzeichnis jedes Benutzers isoliert ist.

Jetzt können Sie sich bei der SageMaker-Konsole anmelden und sehen, dass drei Benutzerprofile erstellt wurden.

Sie haben gerade eine Proof-of-Concept-Lösung implementiert, um mehrere Benutzer und Teams mit Studio zu verwalten.

Aufräumen

Um Gebühren zu vermeiden, müssen Sie alle vom Projekt bereitgestellten und generierten Ressourcen aus Ihrem AWS-Konto entfernen. Verwenden Sie den folgenden SAM-CLI-Befehl, um den Lösungs-CloudFormation-Stack zu löschen:

sam delete delete-stack --stack-name <stack name of SAM stack>

Aus Sicherheitsgründen und um Datenverlust zu vermeiden, werden die Amazon EFS-Bereitstellung und der Inhalt, der mit der in dieser Lösung bereitgestellten Studio-Domäne verknüpft ist, nicht gelöscht. Die mit der SageMaker-Domäne verknüpfte VPC und Subnetze verbleiben in Ihrem AWS-Konto. Anweisungen zum Löschen des Dateisystems und der VPC finden Sie unter Löschen eines Amazon EFS-Dateisystems und Arbeiten Sie mit VPCs, Bzw.

Führen Sie die folgenden Schritte aus, um die benutzerdefinierte SAML-Anwendung zu löschen:

Öffnen Sie die AWS SSO-Konsole im AWS SSO-Verwaltungskonto.
Auswählen Anwendungen.
Auswählen SageMaker Studio-Team 1.
Auf dem Aktionen Menü, wählen Sie Entfernen.
Wiederholen Sie diese Schritte für SageMaker Studio-Team 2.

Zusammenfassung

Diese Lösung hat gezeigt, wie Sie mithilfe von AWS SSO- und Studio-Benutzerprofilen eine flexible und anpassbare Umgebung erstellen können, um Ihre eigene Organisationsstruktur zu unterstützen. Die nächsten möglichen Verbesserungsschritte hin zu einer serienreifen Lösung könnten sein:

Implementieren Sie die automatisierte Studio-Benutzerprofilverwaltung als dedizierten Microservice, um einen automatisierten Profilbereitstellungs-Workflow zu unterstützen und Metadaten und Konfigurationen für Benutzerprofile zu handhaben, beispielsweise in Amazon DynamoDB.
Verwenden Sie denselben Mechanismus in einem allgemeineren Fall mehrerer SageMaker-Domänen und mehrerer AWS-Konten. Dasselbe SAML-Backend kann eine entsprechende vorsignierte URL verkaufen, die gemäß Ihrer benutzerdefinierten Logik basierend auf Benutzerberechtigungen und Team-Setup zu einer Kombination aus Benutzerprofil, Domäne und Konto umleitet.
Implementieren Sie einen Synchronisierungsmechanismus zwischen Ihrem IdP und AWS SSO und automatisieren Sie die Erstellung benutzerdefinierter SAML 2.0-Anwendungen.
Implementieren Sie ein skalierbares Daten- und Ressourcenzugriffsmanagement mit Attributbasierte Zugriffskontrolle (ABAC).

Wenn Sie Feedback oder Fragen haben, hinterlassen Sie diese bitte in den Kommentaren.

Weiterführende Literatur

Dokumentation

Blog

Über den Autor

Jewgenij Iljin ist Lösungsarchitekt bei AWS. Er verfügt über mehr als 20 Jahre Erfahrung auf allen Ebenen der Softwareentwicklung und Lösungsarchitektur und hat Programmiersprachen von COBOL und Assembler bis zu .NET, Java und Python verwendet. Er entwickelt und codiert Cloud-native Lösungen mit den Schwerpunkten Big Data, Analytics und Data Engineering.