Gestione di team e utenti con Amazon SageMaker e AWS SSO

Ripubblicato da Platone

Seguaci: 0

Amazon Sage Maker Studio è un ambiente di sviluppo integrato (IDE) basato sul Web per l'apprendimento automatico (ML) che consente di creare, addestrare, eseguire il debug, distribuire e monitorare i modelli ML. Ogni utente integrato in Studio ha il proprio set di risorse dedicato, come istanze di calcolo, una home directory su un File system elastico Amazon (Amazon EFS) e un volume dedicato Gestione dell'identità e dell'accesso di AWS (IAM) ruolo di esecuzione.

Una delle sfide più comuni del mondo reale nella configurazione dell'accesso degli utenti per Studio è come gestire più utenti, gruppi e team di data science per l'accesso ai dati e l'isolamento delle risorse.

Molti clienti implementano la gestione degli utenti utilizzando identità federate con Accesso singolo AWS (AWS SSO) e un provider di identità esterno (IdP), come Active Directory (AD) o la directory AWS Managed Microsoft AD. È allineato con l'AWS pratica consigliata dell'utilizzo di credenziali temporanee per accedere agli account AWS.

An Amazon Sage Maker dominio supporta AWS SSO e può essere configurato in AWS SSO modalità di autenticazione. In questo caso, ogni utente AWS SSO autorizzato ha il proprio Profilo utente di Studio. Gli utenti che hanno accesso a Studio hanno un URL di accesso univoco che apre direttamente Studio e accedono con le proprie credenziali AWS SSO. Le organizzazioni gestiscono i propri utenti in AWS SSO anziché nel dominio SageMaker. Puoi assegnare l'accesso al dominio a più utenti contemporaneamente. Puoi utilizzare i profili utente di Studio per ciascun utente per definire le autorizzazioni di sicurezza nei notebook di Studio tramite un ruolo IAM collegato al profilo utente, chiamato ruolo di esecuzione. Questo ruolo controlla le autorizzazioni per le operazioni di SageMaker in base alle sue politiche di autorizzazione IAM.

Nella modalità di autenticazione AWS SSO, c'è sempre una mappatura uno-a-uno tra utenti e profili utente. Il dominio SageMaker gestisce la creazione di profili utente basati sull'ID utente AWS SSO. Non è possibile creare profili utente tramite il Console di gestione AWS. Funziona bene nel caso in cui un utente sia membro di un solo team di data science o se gli utenti hanno requisiti di accesso uguali o molto simili nei loro progetti e team. In un caso d'uso più comune, quando un utente può partecipare a più progetti ML ed essere membro di più team con requisiti di autorizzazione leggermente diversi, l'utente richiede l'accesso a diversi profili utente di Studio con ruoli di esecuzione e criteri di autorizzazione diversi. Poiché non puoi gestire i profili utente indipendentemente da AWS SSO nella modalità di autenticazione AWS SSO, non puoi implementare una mappatura uno-a-molti tra utenti e profili utente di Studio.

Se è necessario stabilire una forte separazione dei contesti di sicurezza, ad esempio per diverse categorie di dati, o è necessario impedire completamente la visibilità di un gruppo di attività e risorse di utenti su un altro, l'approccio consigliato è creare più domini SageMaker. Al momento della stesura di questo documento, puoi creare un solo dominio per account AWS per regione. Per implementare la forte separazione, puoi utilizzare più account AWS con un dominio per account come soluzione alternativa.

La seconda sfida è limitare l'accesso allo Studio IDE solo agli utenti all'interno di una rete aziendale o di un VPC designato. Puoi ottenerlo usando Politiche di controllo degli accessi basate su IAM. In questo caso, il dominio SageMaker deve essere configurato con Modalità di autenticazione IAM, perché i criteri basati sull'identità IAM non sono supportati dal meccanismo di accesso in modalità AWS SSO. Il post Accesso sicuro ad Amazon SageMaker Studio con AWS SSO e un'applicazione SAML risolve questa sfida e mostra come controllare l'accesso di rete a un dominio SageMaker.

Questa soluzione affronta queste sfide della gestione degli utenti di AWS SSO per Studio per un caso d'uso comune di più gruppi di utenti e una mappatura molti-a-molti tra utenti e team. La soluzione illustra come utilizzare a applicazione SAML 2.0 personalizzata come meccanismo per attivare l'autenticazione dell'utente per Studio e supportare più profili utente di Studio per un utente AWS SSO.

È possibile utilizzare questo approccio per implementare un portale utente personalizzato con applicazioni supportate dal processo di autorizzazione SAML 2.0. Il tuo portale utente personalizzato può avere la massima flessibilità su come gestire e visualizzare le applicazioni utente. Ad esempio, il portale utente può mostrare alcuni metadati del progetto ML per facilitare l'identificazione di un'applicazione a cui accedere.

Puoi trovare il codice sorgente della soluzione nel ns Repository GitHub.

Panoramica della soluzione

La soluzione implementa la seguente architettura.

I principali componenti dell'architettura di alto livello sono i seguenti:

Fornitore di identità – Utenti e gruppi vengono gestiti in un'origine identità esterna, ad esempio in Azure AD. Le assegnazioni degli utenti ai gruppi AD definiscono quali autorizzazioni ha un determinato utente e a quale team di Studio ha accesso. L'origine dell'identità deve essere sincronizzata con AWS SSO.
SSO dell'AWS – AWS SSO gestisce utenti SSO, set di autorizzazioni SSO e applicazioni. Questa soluzione utilizza un'applicazione SAML 2.0 personalizzata per fornire l'accesso a Studio agli utenti AWS SSO autorizzati. La soluzione utilizza anche la mappatura degli attributi SAML per popolare l'asserzione SAML con dati specifici per l'accesso, come ID utente e team di utenti. Poiché la soluzione crea un'API SAML, puoi utilizzare qualsiasi IdP che supporta le asserzioni SAML per creare questa architettura. Ad esempio, puoi utilizzare Okta o anche la tua applicazione web che fornisce una pagina di destinazione con un portale utente e applicazioni. Per questo post, utilizziamo AWS SSO.
Applicazioni SAML 2.0 personalizzate – La soluzione crea un'applicazione per team di Studio e assegna una o più applicazioni a un utente oa un gruppo di utenti in base alle autorizzazioni. Gli utenti possono accedere a queste applicazioni dal loro portale utente AWS SSO in base alle autorizzazioni assegnate. Ogni applicazione è configurata con il Gateway API Amazon URL dell'endpoint come back-end SAML.
dominio SageMaker – La soluzione effettua il provisioning di un dominio SageMaker in un account AWS e crea un profilo utente dedicato per ogni combinazione di utente AWS SSO e team di Studio a cui è assegnato l'utente. Il dominio deve essere configurato in IAM modalità di autenticazione.
Profili utente di Studio – La soluzione crea automaticamente un profilo utente dedicato per ciascuna combinazione utente-team. Ad esempio, se un utente è membro di due team di Studio e dispone delle autorizzazioni corrispondenti, la soluzione prevede due profili utente separati per questo utente. Ogni profilo appartiene sempre ad uno ed un solo utente. Poiché disponi di un profilo utente di Studio per ogni possibile combinazione di utente e team, devi considerare i limiti del tuo account per i profili utente prima di implementare questo approccio. Ad esempio, se il tuo limite è di 500 profili utente e ogni utente è membro di due team, consumi quel limite 2.5 volte più velocemente e, di conseguenza, puoi inserire 250 utenti. Con un numero elevato di utenti, consigliamo di implementare più domini e account per la separazione del contesto di sicurezza. Per dimostrare la prova del concetto, utilizziamo due utenti, Utente 1 e Utente 2, e due team di Studio, Team 1 e Team 2. L'utente 1 appartiene a entrambi i team, mentre l'utente 2 appartiene solo al Team 2. L'utente 1 può accedere agli ambienti Studio per entrambi i team, mentre l'utente 2 può accedere solo all'ambiente Studio per il team 2.
Ruoli di esecuzione dello studio – Ogni profilo utente di Studio utilizza un ruolo di esecuzione dedicato con criteri di autorizzazione con il livello di accesso richiesto per il team specifico a cui appartiene l'utente. I ruoli di esecuzione di Studio implementano un efficace isolamento delle autorizzazioni tra i singoli utenti e i ruoli del team. Gestisci l'accesso ai dati e alle risorse per ogni ruolo e non a livello di singolo utente.

La soluzione implementa anche un controllo di accesso basato sugli attributi (ABAC) che utilizza attributi SAML 2.0, tag sui profili utente di Studio e tag sui ruoli di esecuzione di SageMaker.

In questa particolare configurazione, presupponiamo che gli utenti AWS SSO non dispongano delle autorizzazioni per accedere all'account AWS e non abbiano ruoli IAM controllati da AWS SSO corrispondenti nell'account. Ogni utente accede al proprio ambiente Studio tramite un URL prefirmato da un portale AWS SSO senza la necessità di accedere alla console nel proprio account AWS. In un ambiente reale, potrebbe essere necessario eseguire la configurazione Set di autorizzazioni AWS SSO per consentire agli utenti autorizzati di assumere un ruolo IAM e di accedere a un account AWS. Ad esempio, puoi fornire le autorizzazioni del ruolo di data scientist affinché un utente possa interagire con le risorse dell'account e avere il livello di accesso necessario per svolgere il proprio ruolo.

Architettura della soluzione e flusso di lavoro

Il diagramma seguente presenta il flusso di accesso end-to-end per un utente AWS SSO.

Un utente AWS SSO sceglie un'applicazione Studio corrispondente nel proprio portale AWS SSO. AWS SSO prepara un'asserzione SAML (1) con mappature di attributi SAML configurate. Un'applicazione SAML personalizzata è configurata con l'URL dell'endpoint API Gateway come Assertion Consumer Service (ACS) e necessita di attributi di mappatura contenenti l'ID utente AWS SSO e l'ID team. Noi usiamo ssouserid ed teamid attributi personalizzati per inviare tutte le informazioni necessarie al back-end SAML.

Il gateway API chiama un'API back-end SAML. Un AWS Lambda la funzione (2) implementa l'API, analizza la risposta SAML per estrarre l'ID utente e l'ID team. La funzione li usa per recuperare una configurazione specifica del team, come un ruolo di esecuzione e un ID dominio SageMaker. La funzione verifica se nel dominio esiste un profilo utente richiesto e se non esiste un profilo ne crea uno nuovo con le impostazioni di configurazione corrispondenti. Successivamente, la funzione genera tramite chiamata un URL preimpostato da Studio per un profilo utente di Studio specifico CreaPresignedDomainUrl API (3) tramite un endpoint VPC API SageMaker. La funzione Lambda restituisce infine l'URL prefirmato con la risposta di reindirizzamento HTTP 302 per far accedere l'utente a Studio.

La soluzione implementa una versione di esempio non di produzione di un back-end SAML. La funzione Lambda analizza l'asserzione SAML e utilizza solo gli attributi in <saml2:AttributeStatement> elemento per costruire a CreatePresignedDomainUrl Chiamata API. Nella soluzione di produzione, è necessario utilizzare un'implementazione back-end SAML adeguata, che deve includere la convalida di una risposta SAML, una firma e certificati, prevenzione della riproduzione e del reindirizzamento e qualsiasi altra funzionalità di un processo di autenticazione SAML. Ad esempio, puoi usare a python3-saml Implementazione del back-end SAML or Toolkit SAML open source OneLogin per implementare un backend SAML sicuro.

Creazione dinamica dei profili utente di Studio

La soluzione crea automaticamente un profilo utente di Studio per ciascuna combinazione utente-team, non appena il processo di accesso AWS SSO richiede un URL prefirmato. Per questa prova di concetto e semplicità, la soluzione crea profili utente basati sui metadati configurati in AWS modello 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

Puoi configurare i tuoi team, le impostazioni personalizzate e i tag aggiungendoli alla configurazione dei metadati per la risorsa AWS CloudFormation GetUserProfileMetadata.

Per ulteriori informazioni sugli elementi di configurazione di UserSettings, fare riferimento a crea_profilo_utente in boto3.

Ruoli IAM

Il diagramma seguente mostra i ruoli IAM in questa soluzione.

I ruoli sono i seguenti:

Ruolo di esecuzione dello studio – Un profilo utente di Studio utilizza un ruolo di esecuzione Studio dedicato con autorizzazioni di dati e risorse specifiche per ogni team o gruppo di utenti. Questo ruolo può anche utilizzare i tag per implementare ABAC per l'accesso ai dati e alle risorse. Per ulteriori informazioni, fare riferimento a Ruoli di SageMaker.

Ruolo di esecuzione Lambda back-end SAML – Questo ruolo di esecuzione contiene l'autorizzazione per chiamare il CreatePresignedDomainUrl API. È possibile configurare il criterio di autorizzazione per includere ulteriori controlli condizionali utilizzando Condition chiavi. Ad esempio, per consentire l'accesso a Studio solo da un determinato intervallo di indirizzi IP all'interno della rete aziendale privata, utilizzare il codice seguente:

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

Per ulteriori esempi su come utilizzare le condizioni nelle policy IAM, fare riferimento a Controlla l'accesso all'API SageMaker utilizzando criteri basati sull'identità.

SageMaker – SageMaker assume il ruolo di esecuzione di Studio per tuo conto, come controllato da una policy di attendibilità corrispondente sul ruolo di esecuzione. Ciò consente al servizio di accedere a dati e risorse ed eseguire azioni per tuo conto. Il ruolo di esecuzione di Studio deve contenere una policy di attendibilità che consenta a SageMaker di assumere questo ruolo.
Ruolo IAM del set di autorizzazioni AWS SSO – Puoi assegnare i tuoi utenti AWS SSO agli account AWS nella tua organizzazione AWS tramite Set di autorizzazioni AWS SSO. Un set di autorizzazioni è un modello che definisce una raccolta di policy IAM specifiche del ruolo utente. Gestisci i set di autorizzazioni in AWS SSO e AWS SSO controlla i ruoli IAM corrispondenti in ogni account.
Politiche di controllo dei servizi delle organizzazioni AWS - Se usi Organizzazioni AWS, puoi implementare Politiche di controllo del servizio (SCP) per controllare centralmente le autorizzazioni massime disponibili per tutti gli account e tutti i ruoli IAM nella tua organizzazione. Ad esempio, per impedire centralmente l'accesso a Studio tramite la console, è possibile implementare il seguente SCP e collegarlo agli account con il dominio SageMaker:
```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "sagemaker:*"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Condition": {
        "NotIpAddress": {
          "aws:VpcSourceIp": "<AuthorizedPrivateSubnet>"
        }
      },
      "Action": [
        "sagemaker:CreatePresignedDomainUrl"
      ],
      "Resource": "*",
      "Effect": "Deny"
    }
  ]
}
```

Ruoli forniti dalla soluzione

I AWS CloudFormazione pila per questa soluzione crea tre ruoli di esecuzione Studio utilizzati nel dominio SageMaker:

SageMakerStudioExecutionRoleDefault
SageMakerStudioExecutionRoleTeam1
SageMakerStudioExecutionRoleTeam2

Nessuno dei ruoli ha il AmazonSageMakerFullAccess policy allegata e ognuno ha solo un set limitato di autorizzazioni. Nel tuo ambiente SageMaker reale, devi modificare le autorizzazioni del ruolo in base ai tuoi requisiti specifici.

SageMakerStudioExecutionRoleDefault ha solo la politica personalizzata SageMakerReadOnlyPolicy allegato con un elenco restrittivo di azioni consentite.

Entrambi i ruoli di squadra, SageMakerStudioExecutionRoleTeam1 ed SageMakerStudioExecutionRoleTeam2, dispone inoltre di due criteri personalizzati, SageMakerAccessSupportingServicesPolicy ed SageMakerStudioDeveloperAccessPolicy, consentendo l'utilizzo di servizi particolari e una politica di solo rifiuto, SageMakerDeniedServicesPolicy, con rifiuto esplicito su alcune chiamate API SageMaker.

La politica di accesso per sviluppatori di Studio impone l'impostazione di Team tag uguale allo stesso valore del ruolo di esecuzione dell'utente per chiamare qualsiasi 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"
}

Inoltre, consente di utilizzare le operazioni di eliminazione, arresto, aggiornamento e avvio solo su risorse contrassegnate con lo stesso tag Team del ruolo di esecuzione dell'utente:

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

Per ulteriori informazioni su ruoli e politiche, fare riferimento a Configurazione di Amazon SageMaker Studio per team e gruppi con isolamento completo delle risorse.

Infrastruttura di rete

La soluzione implementa un ambiente di dominio SageMaker completamente isolato con tutto il traffico di rete in transito Collegamento privato AWS connessioni. È possibile abilitare facoltativamente l'accesso a Internet dai notebook Studio. La soluzione ne crea anche tre Gruppi di sicurezza VPC per controllare il traffico tra tutti i componenti della soluzione come la funzione Lambda back-end SAML, endpoint VPC, e quaderni Studio.

Per questa dimostrazione di concetto e semplicità, la soluzione crea una sottorete SageMaker in un'unica soluzione Zona di disponibilità. Per la configurazione di produzione, è necessario utilizzare più sottoreti private in più zone di disponibilità e assicurarsi che ciascuna sottorete abbia le dimensioni appropriate, presupponendo un minimo di cinque IP per utente.

Questa soluzione fornisce tutta l'infrastruttura di rete richiesta. Il modello CloudFormation ./cfn-templates/vpc.yaml contiene il codice sorgente.

Fasi di distribuzione

Per distribuire e testare la soluzione, è necessario completare i seguenti passaggi:

Distribuire lo stack della soluzione tramite un Modello di applicazione serverless AWS (AWS SAM) modello.
Crea utenti AWS SSO o utilizza utenti AWS SSO esistenti.
Crea applicazioni SAML 2.0 personalizzate e assegna utenti AWS SSO alle applicazioni.

Il codice sorgente completo per la soluzione è fornito nel nostro GitHub deposito.

Prerequisiti

Per utilizzare questa soluzione, il Interfaccia della riga di comando di AWS (AWS CLI), CLI di AWS SAMe Python 3.8 o successivo deve essere installato.

La procedura di distribuzione presuppone che tu abbia abilitato AWS SSO e configurato per il Organizzazioni AWS nell'account in cui è distribuita la soluzione.

Per configurare AWS SSO, fare riferimento alle istruzioni in GitHub.

Opzioni di distribuzione della soluzione

Puoi scegliere tra diverse opzioni di distribuzione della soluzione per adattarla al meglio al tuo ambiente AWS esistente. Puoi anche selezionare la rete e le opzioni di provisioning del dominio SageMaker. Per informazioni dettagliate sulle diverse scelte di distribuzione, fare riferimento a File README.

Distribuisci il modello AWS SAM

Per distribuire il modello AWS SAM, completa i seguenti passaggi:

Clona il codice sorgente deposito al tuo ambiente locale:

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

Crea l'applicazione AWS SAM:
Distribuire l'applicazione:
```
sam deploy --guided
```
Fornisci i parametri dello stack in base al tuo ambiente esistente e alle opzioni di distribuzione desiderate, come il VPC esistente, le sottoreti private e pubbliche esistenti e il dominio SageMaker esistente, come discusso nella Opzioni di distribuzione della soluzione capitolo del file README.

Puoi lasciare tutti i parametri ai valori predefiniti per fornire nuove risorse di rete e un nuovo dominio SageMaker. Fare riferimento all'utilizzo dettagliato dei parametri in README file se è necessario modificare le impostazioni predefinite.

Attendi fino al completamento della distribuzione dello stack. La distribuzione end-to-end, incluso il provisioning di tutte le risorse di rete e di un dominio SageMaker, richiede circa 20 minuti.

Per vedere l'output dello stack, eseguire il seguente comando nel terminale:

export STACK_NAME=<SAM stack name>

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

Crea utenti SSO

Segui le istruzioni per aggiungi utenti AWS SSO per creare due utenti con i nomi Utente1 e Utente2 o utilizzare due qualsiasi degli utenti AWS SSO esistenti per testare la soluzione. Assicurati di utilizzare AWS SSO nella stessa regione AWS in cui hai distribuito la soluzione.

Crea applicazioni SAML 2.0 personalizzate

Per creare le applicazioni SAML 2.0 personalizzate richieste per il Team 1 e per il Team 2, completare i seguenti passaggi:

Apri la console AWS SSO nell'account di gestione AWS della tua organizzazione AWS, nella stessa regione in cui hai distribuito lo stack di soluzioni.
Scegli Applicazioni nel pannello di navigazione.
Scegli Aggiungi una nuova applicazione.
Scegli Aggiungi un'applicazione SAML 2.0 personalizzata.
Nel Nome visualizzato, immettere il nome di un'applicazione, ad esempio SageMaker Studio Team 1.
Lasciare URL di inizio dell'applicazione ed Stato relè vuoto.
Scegli Se non disponi di un file di metadati, puoi inserire manualmente i valori dei metadati.
Nel URL ACS dell'applicazione, inserisci l'URL fornito in SAMLBackendEndpoint chiave dell'output dello stack AWS SAM.
Nel Pubblico SAML dell'applicazione, inserisci l'URL fornito in SAMLAudience chiave dell'output dello stack AWS SAM.
Scegli Salvare le modifiche.
Passare alla Mappature degli attributi scheda.
Impostare il Oggetto a email ed Formato a indirizzo email.
Aggiungi i seguenti nuovi attributi:
1. ssouserid impostato ${user:AD_GUID}
2. teamid impostato Team1 or Team2, rispettivamente, per ciascuna applicazione
Scegli Salvare le modifiche.
Sulla Utenti assegnati scheda, scegliere Assegna utenti.
Scegliere Utente 1 per l'applicazione Team 1 e sia Utente 1 che Utente 2 per l'applicazione Team 2.
Scegli Assegna utenti.

Prova la soluzione

Per testare la soluzione, completare i seguenti passaggi:

Vai al portale utente di AWS SSO https://<Identity Store ID>.awsapps.com/start e firma come Utente 1.
Nel portale vengono visualizzate due applicazioni SageMaker.
Scegli Team di SageMaker Studio 1.
Verrai reindirizzato all'istanza di Studio per il Team 1 in una nuova finestra del browser.
La prima volta che avvii Studio, SageMaker crea un'applicazione JupyterServer. Questo processo richiede pochi minuti.
In Studio, il Compila il menù, scegliere New ed terminal per avviare un nuovo terminale.
Nella riga di comando del terminale, immettere il seguente comando:
```
aws sts get-caller-identity
```
Il comando restituisce il ruolo di esecuzione di Studio.

Nella nostra configurazione, questo ruolo deve essere diverso per ogni squadra. Puoi anche verificare che ogni utente in ogni istanza di Studio abbia la propria home directory su un volume Amazon EFS montato.
Torna al portale AWS SSO, ancora registrato come Utente 1, e scegli Team di SageMaker Studio 2.
Verrai reindirizzato a un'istanza di Team 2 Studio.
Il processo di avvio può richiedere nuovamente diversi minuti, poiché SageMaker avvia una nuova applicazione JupyterServer per l'utente 2.
Firma come Utente 2 nel portale AWS SSO.
L'utente 2 ha una sola applicazione assegnata: SageMaker Studio Team 2.

Se avvii un'istanza di Studio tramite questa applicazione utente, puoi verificare che utilizzi lo stesso ruolo di esecuzione di SageMaker dell'istanza Team 1 dell'utente 2. Tuttavia, ogni istanza di Studio è completamente isolata. L'utente 2 ha la propria home directory su un volume Amazon EFS e una propria istanza dell'applicazione JupyterServer. Puoi verificarlo creando una cartella e alcuni file per ciascuno degli utenti e vedere che la home directory di ogni utente è isolata.

Ora puoi accedere alla console SageMaker e vedere che sono stati creati tre profili utente.

Hai appena implementato una soluzione proof of concept per gestire più utenti e team con Studio.

ripulire

Per evitare addebiti, devi rimuovere tutte le risorse fornite e generate dal progetto dal tuo account AWS. Utilizzare il seguente comando CLI SAM per eliminare lo stack CloudFormation della soluzione:

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

Per motivi di sicurezza e per prevenire la perdita di dati, il montaggio di Amazon EFS e il contenuto associato al dominio Studio distribuito in questa soluzione non vengono eliminati. Il VPC e le sottoreti associate al dominio SageMaker rimangono nel tuo account AWS. Per istruzioni sull'eliminazione del file system e del VPC, fare riferimento a Eliminazione di un file system Amazon EFS ed Lavora con i VPC, Rispettivamente.

Per eliminare l'applicazione SAML personalizzata, completare i seguenti passaggi:

Apri la console AWS SSO nell'account di gestione AWS SSO.
Scegli Applicazioni.
Seleziona Team di SageMaker Studio 1.
Sulla Azioni menù, scegliere Rimuovere.
Ripetere questi passaggi per Team di SageMaker Studio 2.

Conclusione

Questa soluzione ha dimostrato come creare un ambiente flessibile e personalizzabile utilizzando i profili utente AWS SSO e Studio per supportare la propria struttura organizzativa. I prossimi possibili passi di miglioramento verso una soluzione pronta per la produzione potrebbero essere:

Implementare la gestione automatizzata dei profili utente di Studio come microservizio dedicato per supportare un flusso di lavoro di provisioning automatico dei profili e per gestire i metadati e la configurazione per i profili utente, ad esempio in Amazon DynamoDB.
Utilizza lo stesso meccanismo in un caso più generale di più domini SageMaker e più account AWS. Lo stesso back-end SAML può vendere un URL prefirmato corrispondente reindirizzando a una combinazione profilo utente-dominio-account in base alla logica personalizzata basata sui diritti utente e sulla configurazione del team.
Implementa un meccanismo di sincronizzazione tra il tuo IdP e AWS SSO e automatizza la creazione di applicazioni SAML 2.0 personalizzate.
Implementare dati scalabili e gestione dell'accesso alle risorse con controllo degli accessi basato sugli attributi (ABAC).

Se hai commenti o domande, lasciali nei commenti.

Ulteriori letture

Documentazione

Blog post

L'autore

Evgenij Il'in è un Solutions Architect presso AWS. Ha oltre 20 anni di esperienza lavorando a tutti i livelli di sviluppo software e architettura di soluzioni e ha utilizzato linguaggi di programmazione da COBOL e Assembler a .NET, Java e Python. Sviluppa e codifica soluzioni cloud native concentrandosi su big data, analisi e ingegneria dei dati.