Gestion des équipes et des utilisateurs avec Amazon SageMaker et AWS SSO

Republié par Platon

Suiveurs: 0

Amazon SageMakerStudio est un environnement de développement intégré (IDE) basé sur le Web pour l'apprentissage automatique (ML) qui vous permet de créer, d'entraîner, de déboguer, de déployer et de surveiller vos modèles ML. Chaque utilisateur intégré dans Studio dispose de son propre ensemble de ressources dédiées, telles que des instances de calcul, un répertoire d'accueil sur un Système de fichiers Amazon Elastic (Amazon EFS) et un volume dédié Gestion des identités et des accès AWS (IAM) rôle d'exécution.

L'un des défis réels les plus courants lors de la configuration de l'accès des utilisateurs à Studio consiste à gérer plusieurs utilisateurs, groupes et équipes de science des données pour l'accès aux données et l'isolation des ressources.

De nombreux clients implémentent la gestion des utilisateurs à l'aide d'identités fédérées avec Authentification unique AWS (AWS SSO) et un fournisseur d'identité externe (IdP), tel qu'Active Directory (AD) ou un annuaire AWS Managed Microsoft AD. Il est aligné avec l'AWS pratique recommandée d'utiliser des informations d'identification temporaires pour accéder aux comptes AWS.

An Amazon Sage Maker domaine prend en charge AWS SSO et peut être configuré dans AWS SSO Mode d'authentification. Dans ce cas, chaque utilisateur AWS SSO autorisé dispose de son propre Profil utilisateur Studio. Les utilisateurs autorisés à accéder à Studio disposent d'une URL de connexion unique qui ouvre directement Studio, et ils se connectent avec leurs informations d'identification AWS SSO. Les organisations gèrent leurs utilisateurs dans AWS SSO au lieu du domaine SageMaker. Vous pouvez attribuer à plusieurs utilisateurs l'accès au domaine en même temps. Vous pouvez utiliser des profils utilisateur Studio pour chaque utilisateur afin de définir ses autorisations de sécurité dans les blocs-notes Studio via un rôle IAM attaché au profil utilisateur, appelé un rôle d'exécution. Ce rôle contrôle les autorisations pour les opérations SageMaker en fonction de ses politiques d'autorisation IAM.

En mode d'authentification AWS SSO, il existe toujours un mappage un à un entre les utilisateurs et les profils utilisateur. Le domaine SageMaker gère la création de profils utilisateur en fonction de l'ID utilisateur AWS SSO. Vous ne pouvez pas créer de profils utilisateur via le Console de gestion AWS. Cela fonctionne bien dans le cas où un utilisateur est membre d'une seule équipe de science des données ou si les utilisateurs ont des exigences d'accès identiques ou très similaires dans leurs projets et équipes. Dans un cas d'utilisation plus courant, lorsqu'un utilisateur peut participer à plusieurs projets ML et être membre de plusieurs équipes avec des exigences d'autorisation légèrement différentes, l'utilisateur doit accéder à différents profils d'utilisateur Studio avec différents rôles d'exécution et politiques d'autorisation. Étant donné que vous ne pouvez pas gérer les profils utilisateur indépendamment d'AWS SSO en mode d'authentification AWS SSO, vous ne pouvez pas implémenter un mappage un-à-plusieurs entre les utilisateurs et les profils utilisateur Studio.

Si vous avez besoin d'établir une forte séparation des contextes de sécurité, par exemple pour différentes catégories de données, ou si vous avez besoin d'empêcher complètement la visibilité de l'activité et des ressources d'un groupe d'utilisateurs sur un autre, l'approche recommandée consiste à créer plusieurs domaines SageMaker. Au moment d'écrire ces lignes, vous ne pouvez créer qu'un seul domaine par compte AWS et par région. Pour implémenter la séparation forte, vous pouvez utiliser plusieurs comptes AWS avec un domaine par compte comme solution de contournement.

Le deuxième défi consiste à restreindre l'accès à l'IDE Studio uniquement aux utilisateurs à l'intérieur d'un réseau d'entreprise ou d'un VPC désigné. Vous pouvez y parvenir en utilisant Politiques de contrôle d'accès basées sur IAM. Dans ce cas, le domaine SageMaker doit être configuré avec Mode d'authentification IAM, car les stratégies basées sur l'identité IAM ne sont pas prises en charge par le mécanisme de connexion en mode AWS SSO. La poste Accès sécurisé à Amazon SageMaker Studio avec AWS SSO et une application SAML résout ce défi et montre comment contrôler l'accès réseau à un domaine SageMaker.

Cette solution répond aux défis de la gestion des utilisateurs AWS SSO pour Studio pour un cas d'utilisation courant de plusieurs groupes d'utilisateurs et un mappage plusieurs à plusieurs entre les utilisateurs et les équipes. La solution explique comment utiliser un application SAML 2.0 personnalisée comme mécanisme pour déclencher l'authentification de l'utilisateur pour Studio et prendre en charge plusieurs profils d'utilisateur Studio pour un utilisateur AWS SSO.

Vous pouvez utiliser cette approche pour implémenter un portail utilisateur personnalisé avec des applications soutenues par le processus d'autorisation SAML 2.0. Votre portail utilisateur personnalisé peut avoir une flexibilité maximale sur la façon de gérer et d'afficher les applications utilisateur. Par exemple, le portail utilisateur peut afficher certaines métadonnées du projet ML pour faciliter l'identification d'une application à laquelle accéder.

Vous pouvez trouver le code source de la solution dans notre GitHub référentiel.

Vue d'ensemble de la solution

La solution implémente l'architecture suivante.

Les principaux composants de l'architecture de haut niveau sont les suivants :

Fournisseur d'identité – Les utilisateurs et les groupes sont gérés dans une source d'identité externe, par exemple dans Azure AD. Les affectations d'utilisateurs aux groupes AD définissent les autorisations dont dispose un utilisateur particulier et l'équipe Studio à laquelle il a accès. La source d'identité doit être synchronisée avec AWS SSO.
AWSSSO – AWS SSO gère les utilisateurs SSO, les ensembles d'autorisations SSO et les applications. Cette solution utilise une application SAML 2.0 personnalisée pour fournir un accès à Studio aux utilisateurs AWS SSO autorisés. La solution utilise également le mappage d'attributs SAML pour remplir l'assertion SAML avec des données d'accès spécifiques, telles que l'ID utilisateur et l'équipe d'utilisateurs. Étant donné que la solution crée une API SAML, vous pouvez utiliser n'importe quel fournisseur d'identité prenant en charge les assertions SAML pour créer cette architecture. Par exemple, vous pouvez utiliser Okta ou même votre propre application Web qui fournit une page de destination avec un portail utilisateur et des applications. Pour cet article, nous utilisons AWS SSO.
Applications SAML 2.0 personnalisées – La solution crée une application par équipe Studio et attribue une ou plusieurs applications à un utilisateur ou à un groupe d'utilisateurs en fonction des droits. Les utilisateurs peuvent accéder à ces applications à partir de leur portail utilisateur AWS SSO en fonction des autorisations attribuées. Chaque application est configurée avec le Passerelle d'API Amazon l'URL du point de terminaison comme backend SAML.
Domaine SageMaker – La solution provisionne un domaine SageMaker dans un compte AWS et crée un profil utilisateur dédié pour chaque combinaison d'utilisateur AWS SSO et d'équipe Studio à laquelle l'utilisateur est affecté. Le domaine doit être configuré dans IAM Mode d'authentification.
Profils d'utilisateurs Studio – La solution crée automatiquement un profil utilisateur dédié pour chaque combinaison utilisateur-équipe. Par exemple, si un utilisateur est membre de deux équipes Studio et dispose des autorisations correspondantes, la solution provisionne deux profils utilisateur distincts pour cet utilisateur. Chaque profil appartient toujours à un et un seul utilisateur. Étant donné que vous disposez d'un profil utilisateur Studio pour chaque combinaison possible d'un utilisateur et d'une équipe, vous devez tenir compte des limites de votre compte pour les profils utilisateur avant de mettre en œuvre cette approche. Par exemple, si votre limite est de 500 profils d'utilisateurs et que chaque utilisateur est membre de deux équipes, vous consommez cette limite 2.5 fois plus rapidement et, par conséquent, vous pouvez intégrer 250 utilisateurs. Avec un nombre élevé d'utilisateurs, nous vous recommandons de mettre en œuvre plusieurs domaines et comptes pour la séparation du contexte de sécurité. Pour démontrer la preuve de concept, nous utilisons deux utilisateurs, l'utilisateur 1 et l'utilisateur 2, et deux équipes Studio, l'équipe 1 et l'équipe 2. L'utilisateur 1 appartient aux deux équipes, tandis que l'utilisateur 2 appartient à l'équipe 2 uniquement. L'utilisateur 1 peut accéder aux environnements Studio pour les deux équipes, tandis que l'utilisateur 2 ne peut accéder qu'à l'environnement Studio pour l'équipe 2.
Rôles d'exécution de Studio – Chaque profil d'utilisateur Studio utilise un rôle d'exécution dédié avec des politiques d'autorisation avec le niveau d'accès requis pour l'équipe spécifique à laquelle appartient l'utilisateur. Les rôles d'exécution Studio implémentent une isolation efficace des autorisations entre les utilisateurs individuels et leurs rôles d'équipe. Vous gérez l'accès aux données et aux ressources pour chaque rôle et non au niveau d'un utilisateur individuel.

La solution implémente également un contrôle d'accès basé sur les attributs (ABAC) à l'aide des attributs SAML 2.0, des balises sur les profils utilisateur Studio et des balises sur les rôles d'exécution SageMaker.

Dans cette configuration particulière, nous supposons que les utilisateurs d'AWS SSO n'ont pas les autorisations pour se connecter au compte AWS et n'ont pas de rôles IAM correspondants contrôlés par AWS SSO dans le compte. Chaque utilisateur se connecte à son environnement Studio via une URL pré-signée à partir d'un portail AWS SSO sans avoir besoin d'accéder à la console de son compte AWS. Dans un environnement réel, vous devrez peut-être configurer Ensembles d'autorisations AWS SSO pour les utilisateurs afin de permettre aux utilisateurs autorisés d'assumer un rôle IAM et de se connecter à un compte AWS. Par exemple, vous pouvez fournir des autorisations de rôle de data scientist pour qu'un utilisateur puisse interagir avec les ressources du compte et disposer du niveau d'accès dont il a besoin pour remplir son rôle.

Architecture de la solution et flux de travail

Le diagramme suivant présente le flux de connexion de bout en bout pour un utilisateur AWS SSO.

Un utilisateur AWS SSO choisit une application Studio correspondante dans son portail AWS SSO. AWS SSO prépare une assertion SAML (1) avec des mappages d'attributs SAML configurés. Une application SAML personnalisée est configurée avec l'URL du point de terminaison API Gateway en tant que service consommateur d'assertion (ACS) et nécessite des attributs de mappage contenant l'ID d'utilisateur et l'ID d'équipe AWS SSO. Nous utilisons ssouserid et les teamid attributs personnalisés pour envoyer toutes les informations nécessaires au backend SAML.

La passerelle API appelle une API backend SAML. Un AWS Lambda la fonction (2) implémente l'API, analyse la réponse SAML pour extraire l'ID utilisateur et l'ID d'équipe. La fonction les utilise pour récupérer une configuration spécifique à l'équipe, telle qu'un rôle d'exécution et un ID de domaine SageMaker. La fonction vérifie si un profil utilisateur requis existe dans le domaine et en crée un nouveau avec les paramètres de configuration correspondants si aucun profil n'existe. Ensuite, la fonction génère une URL pré-signée Studio pour un profil utilisateur Studio spécifique en appelant CreatePresignedDomainUrl API (3) via un point de terminaison VPC API SageMaker. La fonction Lambda renvoie enfin l'URL pré-signée avec une réponse de redirection HTTP 302 pour connecter l'utilisateur à Studio.

La solution implémente une version d'exemple hors production d'un backend SAML. La fonction Lambda analyse l'assertion SAML et utilise uniquement les attributs dans le <saml2:AttributeStatement> élément pour construire un CreatePresignedDomainUrl Appel API. Dans votre solution de production, vous devez utiliser une implémentation de backend SAML appropriée, qui doit inclure une validation d'une réponse SAML, une signature et des certificats, la prévention de la relecture et de la redirection, ainsi que toute autre fonctionnalité d'un processus d'authentification SAML. Par exemple, vous pouvez utiliser un python3-saml implémentation du backend SAML or Boîte à outils SAML open source OneLogin pour implémenter un backend SAML sécurisé.

Création dynamique de profils utilisateurs Studio

La solution crée automatiquement un profil utilisateur Studio pour chaque combinaison utilisateur-équipe, dès que le processus de connexion AWS SSO demande une URL pré-signée. Pour cette preuve de concept et cette simplicité, la solution crée des profils d'utilisateurs basés sur les métadonnées configurées dans AWS Modèle SAM:

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

Vous pouvez configurer vos propres équipes, paramètres personnalisés et balises en les ajoutant à la configuration des métadonnées pour la ressource AWS CloudFormation GetUserProfileMetadata.

Pour plus d'informations sur les éléments de configuration de UserSettings, faire référence à créer_profil_utilisateur dans boto3.

Rôles IAM

Le schéma suivant montre les rôles IAM dans cette solution.

Les rôles sont les suivants :

Rôle d'exécution du studio – Un profil utilisateur Studio utilise un rôle d'exécution Studio dédié avec des autorisations de données et de ressources spécifiques à chaque équipe ou groupe d'utilisateurs. Ce rôle peut également utiliser des balises pour implémenter ABAC pour l'accès aux données et aux ressources. Pour plus d'informations, reportez-vous à Rôles SageMaker.

Rôle d'exécution Lambda du backend SAML – Ce rôle d'exécution contient l'autorisation d'appeler le CreatePresignedDomainUrl API. Vous pouvez configurer la stratégie d'autorisation pour inclure des vérifications conditionnelles supplémentaires à l'aide de Condition clés. Par exemple, pour autoriser l'accès à Studio uniquement à partir d'une plage d'adresses IP désignée au sein de votre réseau d'entreprise privé, utilisez le code suivant :

{
    "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"
        }
    ]
}

Pour plus d'exemples sur l'utilisation des conditions dans les stratégies IAM, consultez Contrôlez l'accès à l'API SageMaker à l'aide de politiques basées sur l'identité.

SageMaker – SageMaker assume le rôle d'exécution de Studio en votre nom, tel que contrôlé par une politique de confiance correspondante sur le rôle d'exécution. Cela permet au service d'accéder aux données et aux ressources, et d'effectuer des actions en votre nom. Le rôle d'exécution Studio doit contenir une politique de confiance permettant à SageMaker d'assumer ce rôle.
Rôle IAM de l'ensemble d'autorisations AWS SSO – Vous pouvez affecter vos utilisateurs AWS SSO à des comptes AWS dans votre organisation AWS via Ensembles d'autorisations AWS SSO. Un ensemble d'autorisations est un modèle qui définit un ensemble de stratégies IAM spécifiques à un rôle d'utilisateur. Vous gérez les ensembles d'autorisations dans AWS SSO, et AWS SSO contrôle les rôles IAM correspondants dans chaque compte.
Stratégies de contrôle des services AWS Organizations - Si tu utilises Organisations AWS, vous pouvez mettre en œuvre Politiques de contrôle des services (SCP) pour contrôler de manière centralisée les autorisations maximales disponibles pour tous les comptes et tous les rôles IAM de votre organisation. Par exemple, pour empêcher de manière centralisée l'accès à Studio via la console, vous pouvez implémenter le SCP suivant et l'attacher aux comptes avec le domaine SageMaker :
```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "sagemaker:*"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Condition": {
        "NotIpAddress": {
          "aws:VpcSourceIp": "<AuthorizedPrivateSubnet>"
        }
      },
      "Action": [
        "sagemaker:CreatePresignedDomainUrl"
      ],
      "Resource": "*",
      "Effect": "Deny"
    }
  ]
}
```

Rôles provisionnés pour la solution

Le AWS CloudFormation empiler pour cette solution crée trois rôles d'exécution Studio utilisés dans le domaine SageMaker :

SageMakerStudioExecutionRoleDefault
SageMakerStudioExecutionRoleTeam1
SageMakerStudioExecutionRoleTeam2

Aucun des rôles n'a le AmazonSageMakerFullAccess stratégie attachée, et chacune ne dispose que d'un ensemble limité d'autorisations. Dans votre environnement SageMaker réel, vous devez modifier les autorisations du rôle en fonction de vos besoins spécifiques.

SageMakerStudioExecutionRoleDefault n'a que la politique personnalisée SageMakerReadOnlyPolicy attaché avec une liste restrictive des actions autorisées.

Les deux rôles d'équipe, SageMakerStudioExecutionRoleTeam1 et les SageMakerStudioExecutionRoleTeam2, disposent en outre de deux stratégies personnalisées, SageMakerAccessSupportingServicesPolicy et les SageMakerStudioDeveloperAccessPolicy, permettant l'utilisation de services particuliers et une règle de refus uniquement, SageMakerDeniedServicesPolicy, avec un refus explicite sur certains appels d'API SageMaker.

La politique d'accès des développeurs Studio applique le paramètre de Team tag égal à la même valeur que le propre rôle d'exécution de l'utilisateur pour appeler n'importe quel 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"
}

De plus, il permet d'utiliser les opérations de suppression, d'arrêt, de mise à jour et de démarrage uniquement sur les ressources marquées avec la même balise Team que le rôle d'exécution de l'utilisateur :

{
    "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"
}

Pour plus d'informations sur les rôles et les politiques, reportez-vous à Configuration d'Amazon SageMaker Studio pour les équipes et les groupes avec isolation complète des ressources.

Infrastructure de réseau

La solution implémente un environnement de domaine SageMaker entièrement isolé avec tout le trafic réseau passant par Lien privé AWS Connexions. Vous pouvez éventuellement activer l'accès à Internet à partir des ordinateurs portables Studio. La solution crée également trois Groupes de sécurité VPC pour contrôler le trafic entre tous les composants de la solution tels que la fonction Lambda du backend SAML, points de terminaison VPC, et cahiers Studio.

Pour cette preuve de concept et cette simplicité, la solution crée un sous-réseau SageMaker en un seul Zone de disponibilité. Pour votre configuration de production, vous devez utiliser plusieurs sous-réseaux privés sur plusieurs zones de disponibilité et vous assurer que chaque sous-réseau est correctement dimensionné, en supposant un minimum de cinq adresses IP par utilisateur.

Cette solution provisionne toute l'infrastructure réseau requise. Le modèle CloudFormation ./cfn-templates/vpc.yaml contient le code source.

Étapes de déploiement

Pour déployer et tester la solution, vous devez effectuer les étapes suivantes :

Déployer la pile de la solution via un Modèle d'application sans serveur AWS (AWS SAM) modèle.
Créez des utilisateurs AWS SSO ou utilisez des utilisateurs AWS SSO existants.
Créez des applications SAML 2.0 personnalisées et affectez des utilisateurs AWS SSO aux applications.

Le code source complet de la solution est fourni dans notre GitHub dépôt.

Pré-requis

Pour utiliser cette solution, le Interface de ligne de commande AWS (AWS CLI), CLI AWS SAMet une Python3.8 ou version ultérieure doit être installé.

La procédure de déploiement suppose que vous avez activé AWS SSO et configuré pour le Organisations AWS dans le compte où la solution est déployée.

Pour configurer AWS SSO, reportez-vous aux instructions dans GitHub.

Options de déploiement de la solution

Vous pouvez choisir parmi plusieurs options de déploiement de solution pour avoir la meilleure solution pour votre environnement AWS existant. Vous pouvez également sélectionner les options de provisionnement du réseau et du domaine SageMaker. Pour des informations détaillées sur les différents choix de déploiement, reportez-vous au Fichier README.

Déployer le modèle AWS SAM

Pour déployer le modèle AWS SAM, procédez comme suit :

Cloner le code source dépôt à votre environnement local :

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

Créez l'application AWS SAM :
Déployez l'application :
```
sam deploy --guided
```
Fournissez des paramètres de pile en fonction de votre environnement existant et des options de déploiement souhaitées, telles que le VPC existant, les sous-réseaux privés et publics existants et le domaine SageMaker existant, comme indiqué dans le Options de déploiement de la solution chapitre du fichier README.

Vous pouvez laisser tous les paramètres à leurs valeurs par défaut pour provisionner de nouvelles ressources réseau et un nouveau domaine SageMaker. Reportez-vous à l'utilisation détaillée des paramètres dans le README fichier si vous devez modifier des paramètres par défaut.

Attendez que le déploiement de la pile soit terminé. Le déploiement de bout en bout, y compris le provisionnement de toutes les ressources réseau et d'un domaine SageMaker, prend environ 20 minutes.

Pour voir la sortie de la pile, exécutez la commande suivante dans le terminal :

export STACK_NAME=<SAM stack name>

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

Créer des utilisateurs SSO

Suivez les instructions pour ajouter des utilisateurs AWS SSO pour créer deux utilisateurs avec les noms User1 et User2 ou utilisez deux de vos utilisateurs AWS SSO existants pour tester la solution. Assurez-vous d'utiliser AWS SSO dans la même région AWS dans laquelle vous avez déployé la solution.

Créer des applications SAML 2.0 personnalisées

Pour créer les applications SAML 2.0 personnalisées requises pour l'équipe 1 et l'équipe 2, procédez comme suit :

Ouvrez la console AWS SSO dans le compte de gestion AWS de votre organisation AWS, dans la même région où vous avez déployé la pile de solutions.
Selectionnez Applications dans le volet de navigation.
Selectionnez Ajouter une nouvelle application.
Selectionnez Ajouter une application SAML 2.0 personnalisée.
Pour Pseudo, entrez un nom d'application, par exemple SageMaker Studio Team 1.
Laisser URL de démarrage de l'application et les État du relais vide.
Selectionnez Si vous n'avez pas de fichier de métadonnées, vous pouvez entrer manuellement vos valeurs de métadonnées.
Pour URL ACS de l'application, entrez l'URL fournie dans le SAMLBackendEndpoint clé de la sortie de la pile AWS SAM.
Pour Public SAML de l'application, entrez l'URL fournie dans le SAMLAudience clé de la sortie de la pile AWS SAM.
Selectionnez Enregistrer les modifications.
Accédez à la Mappages d'attributs languette.
Met le Sujet à email et les Format à adresse e-mail.
Ajoutez les nouveaux attributs suivants :
1. ssouserid ajuster à ${user:AD_GUID}
2. teamid ajuster à Team1 or Team2, respectivement, pour chaque application
Selectionnez Enregistrer les modifications.
Sur le Utilisateurs affectés onglet, choisissez Attribuer des utilisateurs.
Choisissez Utilisateur 1 pour l'application Équipe 1 et Utilisateur 1 et Utilisateur 2 pour l'application Équipe 2.
Selectionnez Attribuer des utilisateurs.

Testez la solution

Pour tester la solution, procédez comme suit :

Accéder au portail utilisateur AWS SSO https://<Identity Store ID>.awsapps.com/start et signez en tant qu'utilisateur 1.
Deux applications SageMaker sont affichées dans le portail.
Selectionnez Équipe SageMaker Studio 1.
Vous êtes redirigé vers l'instance Studio pour l'équipe 1 dans une nouvelle fenêtre de navigateur.
La première fois que vous démarrez Studio, SageMaker crée une application JupyterServer. Ce processus prend quelques minutes.
En Studio, sur le Déposez votre dernière attestation menu, choisissez Nouveauté et les terminal pour démarrer un nouveau terminal.
Dans la ligne de commande du terminal, saisissez la commande suivante :
```
aws sts get-caller-identity
```
La commande renvoie le rôle d'exécution Studio.

Dans notre configuration, ce rôle doit être différent pour chaque équipe. Vous pouvez également vérifier que chaque utilisateur de chaque instance de Studio dispose de son propre répertoire personnel sur un volume Amazon EFS monté.
Revenez au portail AWS SSO, toujours connecté en tant qu'utilisateur 1, et choisissez Équipe SageMaker Studio 2.
Vous êtes redirigé vers une instance Team 2 Studio.
Le processus de démarrage peut à nouveau prendre plusieurs minutes, car SageMaker démarre une nouvelle application JupyterServer pour l'utilisateur 2.
Connectez-vous en tant qu'utilisateur 2 sur le portail AWS SSO.
L'utilisateur 2 n'a qu'une seule application assignée : SageMaker Studio Team 2.

Si vous démarrez une instance de Studio via cette application utilisateur, vous pouvez vérifier qu'elle utilise le même rôle d'exécution SageMaker que l'instance Team 1 de l'utilisateur 2. Cependant, chaque instance de Studio est complètement isolée. L'utilisateur 2 a son propre répertoire personnel sur un volume Amazon EFS et sa propre instance de l'application JupyterServer. Vous pouvez le vérifier en créant un dossier et des fichiers pour chacun des utilisateurs et voir que le répertoire personnel de chaque utilisateur est isolé.

Vous pouvez maintenant vous connecter à la console SageMaker et constater que trois profils utilisateur ont été créés.

Vous venez de mettre en place une solution de preuve de concept pour gérer plusieurs utilisateurs et équipes avec Studio.

Nettoyer

Pour éviter des frais, vous devez supprimer toutes les ressources provisionnées et générées par le projet de votre compte AWS. Utilisez la commande CLI SAM suivante pour supprimer la pile CloudFormation de la solution :

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

Pour des raisons de sécurité et pour éviter la perte de données, le montage Amazon EFS et le contenu associé au domaine Studio déployé dans cette solution ne sont pas supprimés. Le VPC et les sous-réseaux associés au domaine SageMaker restent dans votre compte AWS. Pour obtenir des instructions sur la suppression du système de fichiers et du VPC, reportez-vous à Suppression d'un système de fichiers Amazon EFS et les Travailler avec des VPC, Respectivement.

Pour supprimer l'application SAML personnalisée, procédez comme suit :

Ouvrez la console AWS SSO dans le compte de gestion AWS SSO.
Selectionnez Applications.
Sélectionnez Équipe SageMaker Studio 1.
Sur le Actions menu, choisissez Effacer.
Répétez ces étapes pour Équipe SageMaker Studio 2.

Conclusion

Cette solution a démontré comment vous pouvez créer un environnement flexible et personnalisable à l'aide de profils utilisateur AWS SSO et Studio pour prendre en charge votre propre structure d'organisation. Les prochaines étapes d'amélioration possibles vers une solution prête pour la production pourraient être :

Mettre en œuvre la gestion automatisée des profils utilisateur Studio en tant que microservice dédié pour prendre en charge un flux de travail de provisionnement de profil automatisé et pour gérer les métadonnées et la configuration des profils utilisateur, par exemple dans Amazon DynamoDB.
Utilisez le même mécanisme dans un cas plus général de plusieurs domaines SageMaker et plusieurs comptes AWS. Le même backend SAML peut vendre une URL pré-signée correspondante redirigeant vers une combinaison profil utilisateur-domaine-compte selon votre logique personnalisée basée sur les droits de l'utilisateur et la configuration de l'équipe.
Implémentez un mécanisme de synchronisation entre votre IdP et AWS SSO et automatisez la création d'applications SAML 2.0 personnalisées.
Mettre en œuvre une gestion évolutive des accès aux données et aux ressources avec contrôle d'accès basé sur les attributs (ABAC).

Si vous avez des commentaires ou des questions, veuillez les laisser dans les commentaires.

Lectures complémentaires

Documentation

Blog

À propos de l’auteur

Evgueni Ilyin est un architecte de solutions chez AWS. Il a plus de 20 ans d'expérience à tous les niveaux de développement de logiciels et d'architecture de solutions et a utilisé des langages de programmation allant de COBOL et Assembler à .NET, Java et Python. Il développe et code des solutions cloud natives en mettant l'accent sur le big data, l'analyse et l'ingénierie des données.