Team- og brugerstyring med Amazon SageMaker og AWS SSO

Amazon SageMaker Studio er et webbaseret integreret udviklingsmiljø (IDE) til maskinlæring (ML), der lader dig bygge, træne, fejlsøge, implementere og overvåge dine ML-modeller. Hver indbygget bruger i Studio har deres eget dedikerede sæt ressourcer, såsom computerforekomster, en hjemmemappe på en Amazon Elastic File System (Amazon EFS) volumen, og en dedikeret AWS identitets- og adgangsstyring (IAM) udførelsesrolle.

En af de mest almindelige udfordringer i den virkelige verden ved opsætning af brugeradgang til Studio er, hvordan man administrerer flere brugere, grupper og datavidenskabsteams til dataadgang og ressourceisolering.

Mange kunder implementerer brugerstyring ved hjælp af fødererede identiteter med AWS Single Sign-On (AWS SSO) og en ekstern identitetsudbyder (IdP), såsom Active Directory (AD) eller AWS Managed Microsoft AD-katalog. Det er tilpasset AWS anbefalet praksis at bruge midlertidige legitimationsoplysninger til at få adgang til AWS-konti.

An Amazon SageMaker domæne understøtter AWS SSO og kan konfigureres i AWS SSO godkendelsestilstand. I dette tilfælde har hver berettiget AWS SSO-bruger deres egen Studio brugerprofil. Brugere, der får adgang til Studio, har en unik login-URL, der åbner Studio direkte, og de logger på med deres AWS SSO-legitimationsoplysninger. Organisationer administrerer deres brugere i AWS SSO i stedet for SageMaker-domænet. Du kan tildele flere brugere adgang til domænet på samme tid. Du kan bruge Studio-brugerprofiler for hver bruger til at definere deres sikkerhedstilladelser i Studio-notesbøger via en IAM-rolle knyttet til brugerprofilen, kaldet en udfører rolle. Denne rolle kontrollerer tilladelser til SageMaker-operationer i henhold til dens IAM-tilladelsespolitikker.

I AWS SSO-godkendelsestilstand er der altid en-til-en-mapping mellem brugere og brugerprofiler. SageMaker-domænet administrerer oprettelsen af ​​brugerprofiler baseret på AWS SSO-bruger-id'et. Du kan ikke oprette brugerprofiler via AWS Management Console. Dette fungerer godt i tilfælde, hvor én bruger kun er medlem af ét datavidenskabsteam, eller hvis brugere har de samme eller meget lignende adgangskrav på tværs af deres projekter og teams. I et mere almindeligt tilfælde, når en bruger kan deltage i flere ML-projekter og være medlem af flere teams med lidt forskellige tilladelseskrav, kræver brugeren adgang til forskellige Studio-brugerprofiler med forskellige udførelsesroller og tilladelsespolitikker. Fordi du ikke kan administrere brugerprofiler uafhængigt af AWS SSO i AWS SSO-godkendelsestilstand, kan du ikke implementere en en-til-mange-tilknytning mellem brugere og Studio-brugerprofiler.

Hvis du har brug for at etablere en stærk adskillelse af sikkerhedskontekster, for eksempel for forskellige datakategorier, eller har brug for helt at forhindre synligheden af ​​en gruppe af brugeres aktivitet og ressourcer til en anden, er den anbefalede tilgang at oprette flere SageMaker-domæner. I skrivende stund kan du kun oprette ét domæne pr. AWS-konto pr. region. For at implementere den stærke adskillelse kan du bruge flere AWS-konti med ét domæne pr. konto som en løsning.

Den anden udfordring er at begrænse adgangen til Studio IDE kun til brugere fra et virksomhedsnetværk eller en udpeget VPC. Du kan opnå dette ved at bruge IAM-baserede adgangskontrolpolitikker. I dette tilfælde skal SageMaker-domænet konfigureres med IAM-godkendelsestilstand, fordi de IAM-identitetsbaserede politikker ikke understøttes af log-in-mekanismen i AWS SSO-tilstand. Posten Sikker adgang til Amazon SageMaker Studio med AWS SSO og en SAML-applikation løser denne udfordring og demonstrerer, hvordan man kontrollerer netværksadgang til et SageMaker-domæne.

Denne løsning løser disse udfordringer ved AWS SSO-brugeradministration for Studio for en fælles brugssituation for flere brugergrupper og en mange-til-mange kortlægning mellem brugere og teams. Løsningen skitserer, hvordan man bruger en tilpasset SAML 2.0-applikation som mekanismen til at udløse brugergodkendelse for Studio og understøtte flere Studio-brugerprofiler pr. én AWS SSO-bruger.

Du kan bruge denne tilgang til at implementere en brugerdefineret brugerportal med applikationer, der understøttes af SAML 2.0-godkendelsesprocessen. Din brugerdefinerede brugerportal kan have maksimal fleksibilitet med hensyn til, hvordan man administrerer og viser brugerapplikationer. For eksempel kan brugerportalen vise nogle ML-projektmetadata for at gøre det lettere at identificere en applikation, der skal tilgås.

Du kan finde løsningens kildekode i vores GitHub repository.

Løsningsoversigt

Løsningen implementerer følgende arkitektur.

De vigtigste arkitekturkomponenter på højt niveau er som følger:

1. Identitetsudbyder – Brugere og grupper administreres i en ekstern identitetskilde, for eksempel i Azure AD. Brugertildelinger til AD-grupper definerer, hvilke tilladelser en bestemt bruger har, og hvilket Studio-team de har adgang til. Identitetskilden skal synkroniseres med AWS SSO.
2. AWS SSO – AWS SSO administrerer SSO-brugere, SSO-tilladelsessæt og applikationer. Denne løsning bruger en tilpasset SAML 2.0-applikation til at give adgang til Studio for berettigede AWS SSO-brugere. Løsningen bruger også SAML-attributkortlægning til at udfylde SAML-påstanden med specifikke adgangsrelevante data, såsom bruger-id og brugerteam. Fordi løsningen opretter en SAML API, kan du bruge enhver IdP, der understøtter SAML påstande, til at oprette denne arkitektur. For eksempel kan du bruge Okta eller endda din egen webapplikation, der giver en landingsside med en brugerportal og applikationer. Til dette indlæg bruger vi AWS SSO.
3. Brugerdefinerede SAML 2.0-applikationer – Løsningen opretter én applikation pr. Studio-team og tildeler en eller flere applikationer til en bruger eller en brugergruppe baseret på rettigheder. Brugere kan få adgang til disse applikationer fra deres AWS SSO-brugerportal baseret på tildelte tilladelser. Hver applikation er konfigureret med Amazon API Gateway slutpunkts-URL som dens SAML-backend.
4. SageMaker domæne – Løsningen leverer et SageMaker-domæne i en AWS-konto og opretter en dedikeret brugerprofil for hver kombination af AWS SSO-bruger og Studio-team, som brugeren er tildelt. Domænet skal konfigureres i IAM godkendelsestilstand.
5. Studio brugerprofiler – Løsningen opretter automatisk en dedikeret brugerprofil for hver bruger-team-kombination. For eksempel, hvis en bruger er medlem af to Studio-teams og har tilsvarende tilladelser, giver løsningen to separate brugerprofiler til denne bruger. Hver profil tilhører altid én og kun én bruger. Fordi du har en Studio-brugerprofil for hver mulig kombination af en bruger og et team, skal du overveje dine kontogrænser for brugerprofiler, før du implementerer denne tilgang. For eksempel, hvis din grænse er 500 brugerprofiler, og hver bruger er medlem af to teams, bruger du denne grænse 2.5 gange hurtigere, og som et resultat kan du indsætte 250 brugere. Med et højt antal brugere anbefaler vi at implementere flere domæner og konti til adskillelse af sikkerhedskontekst. For at demonstrere proof of concept bruger vi to brugere, Bruger 1 og Bruger 2, og to Studio-teams, Team 1 og Team 2. Bruger 1 tilhører begge teams, hvorimod Bruger 2 kun tilhører Team 2. Bruger 1 kan få adgang til Studio-miljøer for begge teams, hvorimod bruger 2 kun kan få adgang til Studio-miljøet for Team 2.
6. Studio eksekveringsroller – Hver Studio-brugerprofil bruger en dedikeret eksekveringsrolle med tilladelsespolitikker med det nødvendige adgangsniveau for det specifikke team, brugeren tilhører. Studio-udførelsesroller implementerer en effektiv tilladelsesisolering mellem individuelle brugere og deres teamroller. Du administrerer data- og ressourceadgang for hver rolle og ikke på et individuelt brugerniveau.

Løsningen implementerer også en attributbaseret adgangskontrol (ABAC) ved hjælp af SAML 2.0-attributter, tags på Studio-brugerprofiler og tags på SageMaker-udførelsesroller.

I denne særlige konfiguration antager vi, at AWS SSO-brugere ikke har tilladelser til at logge ind på AWS-kontoen og ikke har tilsvarende AWS SSO-kontrollerede IAM-roller på kontoen. Hver bruger logger ind på deres Studio-miljø via en foruddefineret URL fra en AWS SSO-portal uden at skulle gå til konsollen i deres AWS-konto. I et miljø i den virkelige verden skal du muligvis konfigurere AWS SSO-tilladelsessæt for brugere at tillade de autoriserede brugere at påtage sig en IAM-rolle og at logge ind på en AWS-konto. For eksempel kan du give data scientist-rolletilladelser, så en bruger kan interagere med kontoressourcer og få det adgangsniveau, de har brug for for at udføre deres rolle.

Løsningsarkitektur og arbejdsgang

Følgende diagram viser ende-til-ende-login-flowet for en AWS SSO-bruger.

En AWS SSO-bruger vælger en tilsvarende Studio-applikation i deres AWS SSO-portal. AWS SSO forbereder en SAML-påstand (1) med konfigurerede SAML-attributtilknytninger. En tilpasset SAML-applikation er konfigureret med API Gateway-endepunkt-URL'en som dens Assertion Consumer Service (ACS), og har brug for kortlægningsattributter, der indeholder AWS SSO-bruger-id'et og team-id'et. Vi bruger ssouserid , teamid brugerdefinerede attributter til at sende alle nødvendige oplysninger til SAML-backend.

API-gatewayen kalder en SAML-backend API. An AWS Lambda funktion (2) implementerer API'en, analyserer SAML-svaret for at udtrække bruger-id'et og team-id'et. Funktionen bruger dem til at hente en teamspecifik konfiguration, såsom en eksekveringsrolle og SageMaker-domæne-id. Funktionen kontrollerer, om der findes en påkrævet brugerprofil i domænet, og opretter en ny med de tilsvarende konfigurationsindstillinger, hvis der ikke findes en profil. Bagefter genererer funktionen en Studio foruddefineret URL til en specifik Studio brugerprofil ved at ringe CreatePresignedDomainUrl API (3) via et SageMaker API VPC-slutpunkt. Lambda-funktionen returnerer endelig den forudindstillede URL med HTTP 302-omdirigeringssvar for at logge brugeren ind på Studio.

Løsningen implementerer en ikke-produktionseksempelversion af en SAML-backend. Lambda-funktionen analyserer SAML-påstanden og bruger kun attributter i <saml2:AttributeStatement> element til at konstruere en CreatePresignedDomainUrl API-kald. I din produktionsløsning skal du bruge en korrekt SAML-backend-implementering, som skal omfatte en validering af et SAML-svar, en signatur og certifikater, genafspilning og omdirigeringsforhindring og alle andre funktioner i en SAML-godkendelsesproces. For eksempel kan du bruge en python3-saml SAML-backend implementering or OneLogin open source SAML-værktøjssæt at implementere en sikker SAML-backend.

Dynamisk oprettelse af Studio brugerprofiler

Løsningen opretter automatisk en Studio-brugerprofil for hver bruger-team-kombination, så snart AWS SSO-logonprocessen anmoder om en foruddefineret URL. Til dette bevis på koncept og enkelhed opretter løsningen brugerprofiler baseret på de konfigurerede metadata i AWS SAM skabelon:

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

Du kan konfigurere egne teams, brugerdefinerede indstillinger og tags ved at tilføje dem til metadatakonfigurationen for AWS CloudFormation-ressourcen GetUserProfileMetadata.

For mere information om konfigurationselementer af UserSettings, henvise til create_user_profile i boto3.

IAM roller

Følgende diagram viser IAM-rollerne i denne løsning.

Rollerne er som følger:

1. Studio eksekveringsrolle – En Studio-brugerprofil bruger en dedikeret Studio-udførelsesrolle med data- og ressourcetilladelser, der er specifikke for hvert team eller brugergruppe. Denne rolle kan også bruge tags til at implementere ABAC til data- og ressourceadgang. For mere information, se SageMaker roller.
2. SAML backend Lambda eksekveringsrolle – Denne udførelsesrolle indeholder tilladelse til at kalde CreatePresignedDomainUrl API. Du kan konfigurere tilladelsespolitikken til at inkludere yderligere betingede kontroller ved hjælp af Condition nøgler. For at tillade kun adgang til Studio fra en bestemt række IP-adresser inden for dit private firmanetværk, skal du f.eks. bruge følgende kode:

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

   Se flere eksempler på, hvordan man bruger betingelser i IAM-politikker Styr adgangen til SageMaker API ved at bruge identitetsbaserede politikker.

3. SageMaker – SageMaker påtager sig Studio-udførelsesrollen på dine vegne, som kontrolleret af en tilsvarende tillidspolitik for udførerrollen. Dette giver tjenesten adgang til data og ressourcer og udfører handlinger på dine vegne. Studio-udførelsesrollen skal indeholde en tillidspolitik, der tillader SageMaker at påtage sig denne rolle.
4. AWS SSO-tilladelsessæt IAM-rolle – Du kan tildele dine AWS SSO-brugere til AWS-konti i din AWS-organisation via AWS SSO-tilladelsessæt. Et tilladelsessæt er en skabelon, der definerer en samling af brugerrollespecifikke IAM-politikker. Du administrerer tilladelsessæt i AWS SSO, og AWS SSO styrer de tilsvarende IAM-roller på hver konto.
5. AWS Organisationers servicekontrolpolitikker – Hvis du bruger AWS-organisationer, du kan implementere Servicekontrolpolitikker (SCP'er) til centralt at kontrollere de maksimalt tilgængelige tilladelser for alle konti og alle IAM-roller i din organisation. For eksempel, for centralt at forhindre adgang til Studio via konsollen, kan du implementere følgende SCP og vedhæfte det til konti med SageMaker-domænet:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Action": [
           "sagemaker:*"
         ],
         "Resource": "*",
         "Effect": "Allow"
       },
       {
         "Condition": {
           "NotIpAddress": {
             "aws:VpcSourceIp": "<AuthorizedPrivateSubnet>"
           }
         },
         "Action": [
           "sagemaker:CreatePresignedDomainUrl"
         ],
         "Resource": "*",
         "Effect": "Deny"
       }
     ]
   }

Løsningsklarerede roller

AWS CloudFormation stable for denne løsning opretter tre Studio-udførelsesroller, der bruges i SageMaker-domænet:

• SageMakerStudioExecutionRoleDefault
• SageMakerStudioExecutionRoleTeam1
• SageMakerStudioExecutionRoleTeam2

Ingen af ​​rollerne har AmazonSageMakerFullAccess politik vedhæftet, og hver har kun et begrænset sæt tilladelser. I dit SageMaker-miljø i den virkelige verden skal du ændre rollens tilladelser baseret på dine specifikke krav.

SageMakerStudioExecutionRoleDefault har kun den brugerdefinerede politik SageMakerReadOnlyPolicy vedhæftet en restriktiv liste over tilladte handlinger.

Begge teamroller, SageMakerStudioExecutionRoleTeam1 , SageMakerStudioExecutionRoleTeam2, derudover har to brugerdefinerede politikker, SageMakerAccessSupportingServicesPolicy , SageMakerStudioDeveloperAccessPolicy, der tillader brug af bestemte tjenester og én afvisningspolitik, SageMakerDeniedServicesPolicy, med eksplicit afvisning på nogle SageMaker API-kald.

Studio-udvikleradgangspolitikken håndhæver indstillingen af Team tag lig med den samme værdi som brugerens egen udførelsesrolle for at kalde enhver SageMaker Create* API'er:

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

Ydermere tillader det kun brug af slet-, stop-, opdaterings- og startoperationer på ressourcer, der er mærket med det samme Team-tag som brugerens udførelsesrolle:

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

For mere information om roller og politikker, se Konfiguration af Amazon SageMaker Studio for teams og grupper med komplet ressourceisolering.

Netværksinfrastruktur

Løsningen implementerer et fuldt isoleret SageMaker-domænemiljø, hvor al netværkstrafik går igennem AWS PrivateLink forbindelser. Du kan eventuelt aktivere internetadgang fra Studio-notesbøgerne. Løsningen skaber også tre VPC sikkerhedsgrupper at styre trafikken mellem alle løsningskomponenter såsom SAML backend Lambda-funktionen, VPC-endepunkter, og Studio notesbøger.

For dette bevis på koncept og enkelhed skaber løsningen et SageMaker-undernet i et enkelt Tilgængelighedszone. Til din produktionsopsætning skal du bruge flere private undernet på tværs af flere tilgængelighedszoner og sikre, at hvert undernet har en passende størrelse, idet der antages mindst fem IP'er pr. bruger.

Denne løsning sørger for al nødvendig netværksinfrastruktur. CloudFormation skabelonen ./cfn-templates/vpc.yaml indeholder kildekoden.

Implementeringstrin

For at implementere og teste løsningen skal du udføre følgende trin:

1. Implementer løsningens stak via en AWS serverløs applikationsmodel (AWS SAM) skabelon.
2. Opret AWS SSO-brugere, eller brug eksisterende AWS SSO-brugere.
3. Opret tilpassede SAML 2.0-applikationer og tildel AWS SSO-brugere til applikationerne.

Den fulde kildekode til løsningen findes i vores GitHub Repository.

Forudsætninger

For at bruge denne løsning skal AWS kommandolinjegrænseflade (AWS CLI), AWS SAM CLIog Python3.8 eller nyere skal installeres.

Implementeringsproceduren forudsætter, at du har aktiveret AWS SSO og konfigureret til AWS-organisationer på den konto, hvor løsningen er implementeret.

For at konfigurere AWS SSO, se instruktionerne i GitHub.

Muligheder for løsningsimplementering

Du kan vælge mellem flere løsningsimplementeringsmuligheder for at passe bedst til dit eksisterende AWS-miljø. Du kan også vælge mulighederne for netværks- og SageMaker-domæneklargøring. For detaljerede oplysninger om de forskellige implementeringsvalg henvises til README-fil.

Implementer AWS SAM-skabelonen

Udfør følgende trin for at implementere AWS SAM-skabelonen:

1. Klon kildekoden Repository til dit lokale miljø:

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

2. Byg AWS SAM-applikationen:
3. Implementer applikationen:

   sam deploy --guided

4. Angiv stakparametre i henhold til dit eksisterende miljø og ønskede implementeringsmuligheder, såsom eksisterende VPC, eksisterende private og offentlige undernet og eksisterende SageMaker-domæne, som diskuteret i Muligheder for løsningsimplementering kapitel i README-filen.

Du kan lade alle parametre være på deres standardværdier for at klargøre nye netværksressourcer og et nyt SageMaker-domæne. Se detaljeret parameterbrug i README fil, hvis du har brug for at ændre nogen standardindstillinger.

Vent, indtil stakimplementeringen er fuldført. End-to-end-implementeringen inklusive klargøring af alle netværksressourcer og et SageMaker-domæne tager omkring 20 minutter.

For at se stak-output skal du køre følgende kommando i terminalen:

export STACK_NAME=<SAM stack name>

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

Opret SSO-brugere

Følg instruktionerne til tilføje AWS SSO-brugere at oprette to brugere med navnene Bruger1 og Bruger2 eller bruge to af dine eksisterende AWS SSO-brugere til at teste løsningen. Sørg for, at du bruger AWS SSO i den samme AWS-region, hvor du implementerede løsningen.

Opret tilpassede SAML 2.0-applikationer

For at oprette de nødvendige tilpassede SAML 2.0-applikationer til Team 1 og Team 2 skal du udføre følgende trin:

1. Åbn AWS SSO-konsollen i AWS-administrationskontoen for din AWS-organisation i den samme region, hvor du implementerede løsningsstakken.
2. Vælg Applikationer i navigationsruden.
3. Vælg Tilføj en ny applikation.
4. Vælg Tilføj en tilpasset SAML 2.0-applikation.
5. Til Visningsnavn, indtast f.eks. et programnavn SageMaker Studio Team 1.
6. Forlade Appens start-URL , Relætilstand tom.
7. Vælg Hvis du ikke har en metadatafil, kan du manuelt indtaste dine metadataværdier.
8. Til Applikations ACS URL, skal du indtaste den URL, der er angivet i SAMLBackendEndpoint nøglen til AWS SAM stak-output.
9. Til Application SAML-publikum, skal du indtaste den URL, der er angivet i SAMLAudience nøglen til AWS SAM stak-output.
10. Vælg Gem ændringer.
    
11. Naviger til Attributkortlægninger fane.
12. Indstil Emne til e-mail , dannet til email adresse.
13. Tilføj følgende nye attributter:
    1. ssouserid indstillet til ${user:AD_GUID}
    2. teamid indstillet til Team1 or Team2for hver ansøgning
       
14. Vælg Gem ændringer.
15. På Tildelte brugere fanebladet, vælg Tildel brugere.
16. Vælg Bruger 1 til Team 1-applikationen og både Bruger 1 og Bruger 2 til Team 2-applikationen.
17. Vælg Tildel brugere.
    

Test løsningen

For at teste løsningen skal du udføre følgende trin:

1. Gå til AWS SSO brugerportal https://<Identity Store ID>.awsapps.com/start og underskriv som bruger 1.
   To SageMaker-applikationer er vist i portalen.
   
2. Vælg SageMaker Studio Team 1.
   Du bliver omdirigeret til Studio-instansen for Team 1 i et nyt browservindue.
   Første gang du starter Studio, opretter SageMaker en JupyterServer-applikation. Denne proces tager få minutter.
   
3. I Studio, på File (Felt) menu, vælg Ny , terminal for at starte en ny terminal.
4. Indtast følgende kommando på terminalens kommandolinje:

   aws sts get-caller-identity

   Kommandoen returnerer Studio-udførelsesrollen.
   

   I vores setup skal denne rolle være forskellig for hvert hold. Du kan også kontrollere, at hver bruger i hver forekomst af Studio har deres egen hjemmemappe på en monteret Amazon EFS-diskenhed.

5. Vend tilbage til AWS SSO-portalen, stadig logget som bruger 1, og vælg SageMaker Studio Team 2.
   Du bliver omdirigeret til en Team 2 Studio-instans.
   Startprocessen kan igen tage flere minutter, fordi SageMaker starter en ny JupyterServer-applikation til Bruger 2.
6. Signer som bruger 2 i AWS SSO-portalen.
   Bruger 2 har kun én applikation tildelt: SageMaker Studio Team 2.
   

Hvis du starter en instans af Studio via denne brugerapplikation, kan du bekræfte, at den bruger den samme SageMaker-udførelsesrolle som Bruger 1's Team 2-instans. Hver Studio-instans er dog fuldstændig isoleret. Bruger 2 har deres egen hjemmemappe på en Amazon EFS-diskenhed og egen forekomst af JupyterServer-applikationen. Du kan bekræfte dette ved at oprette en mappe og nogle filer for hver af brugerne og se, at hver brugers hjemmemappe er isoleret.

Nu kan du logge ind på SageMaker-konsollen og se, at der er oprettet tre brugerprofiler.

Du har lige implementeret en proof of concept-løsning til at administrere flere brugere og teams med Studio.

Ryd op

For at undgå gebyrer skal du fjerne alle projektleverede og genererede ressourcer fra din AWS-konto. Brug følgende SAM CLI-kommando til at slette løsningens CloudFormation-stak:

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

Af sikkerhedsmæssige årsager og for at forhindre tab af data slettes Amazon EFS-monteringen og indholdet forbundet med Studio-domænet, der er implementeret i denne løsning. VPC og undernet, der er knyttet til SageMaker-domænet, forbliver på din AWS-konto. For instruktioner til sletning af filsystemet og VPC, se Sletning af et Amazon EFS-filsystem , Arbejde med VPC'er, henholdsvis.

For at slette den tilpassede SAML-applikation skal du udføre følgende trin:

1. Åbn AWS SSO-konsollen i AWS SSO-administrationskontoen.
2. Vælg Applikationer.
3. Type SageMaker Studio Team 1.
4. På handlinger menu, vælg Fjern.
5. Gentag disse trin for SageMaker Studio Team 2.

Konklusion

Denne løsning demonstrerede, hvordan du kan skabe et fleksibelt og tilpasseligt miljø ved hjælp af AWS SSO og Studio brugerprofiler til at understøtte din egen organisationsstruktur. De næste mulige forbedringstrin hen imod en produktionsklar løsning kunne være:

• Implementer automatiseret Studio-brugerprofilstyring som en dedikeret mikrotjeneste for at understøtte en automatiseret profilprovisioneringsworkflow og til at håndtere metadata og konfiguration af brugerprofiler, f.eks. Amazon DynamoDB.
• Brug den samme mekanisme i et mere generelt tilfælde af flere SageMaker-domæner og flere AWS-konti. Den samme SAML-backend kan levere en tilsvarende foruddefineret URL-omdirigering til en kombination af brugerprofil-domæne-konto i henhold til din brugerdefinerede logik baseret på brugerrettigheder og teamopsætning.
• Implementer en synkroniseringsmekanisme mellem din IdP og AWS SSO, og automatiser oprettelsen af ​​tilpassede SAML 2.0-applikationer.
• Implementer skalerbar data- og ressourceadgangsstyring med attributbaseret adgangskontrol (ABAC).

Hvis du har feedback eller spørgsmål, bedes du efterlade dem i kommentarerne.

Yderligere læsning

Dokumentation

Blogindlæg

Om forfatteren

Yevgeniy Ilyin er Solutions Architect hos AWS. Han har over 20 års erfaring med at arbejde på alle niveauer af softwareudvikling og løsningsarkitektur og har brugt programmeringssprog fra COBOL og Assembler til .NET, Java og Python. Han udvikler og koder cloud native løsninger med fokus på big data, analytics og data engineering.