Team- en gebruikersbeheer met Amazon SageMaker en AWS SSO

Heruitgegeven door Plato

volgers: 0

Amazon SageMaker Studio is een webgebaseerde geïntegreerde ontwikkelomgeving (IDE) voor machine learning (ML) waarmee u uw ML-modellen kunt bouwen, trainen, debuggen, implementeren en bewaken. Elke onboard-gebruiker in Studio heeft zijn eigen speciale set bronnen, zoals rekeninstances, een homedirectory op een Amazon elastisch bestandssysteem (Amazon EFS) volume en een speciaal AWS Identiteits- en toegangsbeheer (IAM) uitvoeringsrol.

Een van de meest voorkomende uitdagingen in de praktijk bij het instellen van gebruikerstoegang voor Studio is het beheren van meerdere gebruikers, groepen en datawetenschapsteams voor gegevenstoegang en isolatie van bronnen.

Veel klanten implementeren gebruikersbeheer met behulp van federatieve identiteiten met: AWS eenmalige aanmelding (AWS SSO) en een externe identiteitsprovider (IdP), zoals Active Directory (AD) of AWS Managed Microsoft AD-directory. Het is afgestemd op de AWS aanbevolen praktijk van het gebruik van tijdelijke inloggegevens om toegang te krijgen tot AWS-accounts.

An Amazon Sage Maker domein ondersteunt AWS SSO en kan worden geconfigureerd in AWS SSO authenticatie modus. In dit geval heeft elke AWS SSO-gebruiker zijn eigen Studio-gebruikersprofiel. Gebruikers die toegang krijgen tot Studio hebben een unieke aanmeldings-URL waarmee Studio rechtstreeks wordt geopend, en ze loggen in met hun AWS SSO-inloggegevens. Organisaties beheren hun gebruikers in AWS SSO in plaats van in het SageMaker-domein. U kunt meerdere gebruikers tegelijkertijd toegang geven tot het domein. U kunt Studio-gebruikersprofielen voor elke gebruiker gebruiken om hun beveiligingsmachtigingen in Studio-notebooks te definiëren via een IAM-rol die aan het gebruikersprofiel is gekoppeld, een zogenaamde uitvoerende rol. Deze rol beheert machtigingen voor SageMaker-bewerkingen volgens het IAM-machtigingsbeleid.

In de AWS SSO-authenticatiemodus is er altijd een-op-een-toewijzing tussen gebruikers en gebruikersprofielen. Het SageMaker-domein beheert het aanmaken van gebruikersprofielen op basis van de AWS SSO-gebruikers-ID. U kunt geen gebruikersprofielen maken via de AWS-beheerconsole. Dit werkt goed in het geval dat een gebruiker lid is van slechts één data science-team of als gebruikers dezelfde of zeer vergelijkbare toegangsvereisten hebben voor hun projecten en teams. In een meer algemeen gebruik, wanneer een gebruiker kan deelnemen aan meerdere ML-projecten en lid kan zijn van meerdere teams met enigszins verschillende machtigingsvereisten, heeft de gebruiker toegang nodig tot verschillende Studio-gebruikersprofielen met verschillende uitvoeringsrollen en machtigingsbeleid. Omdat u gebruikersprofielen niet onafhankelijk van AWS SSO kunt beheren in de AWS SSO-verificatiemodus, kunt u geen een-op-veel-toewijzing tussen gebruikers en Studio-gebruikersprofielen implementeren.

Als u een sterke scheiding van beveiligingscontexten tot stand moet brengen, bijvoorbeeld voor verschillende gegevenscategorieën, of als u de zichtbaarheid van de ene groep gebruikersactiviteit en bronnen voor een andere volledig wilt voorkomen, is de aanbevolen aanpak om meerdere SageMaker-domeinen te maken. Op het moment van schrijven kunt u slechts één domein per AWS-account per regio aanmaken. Om de sterke scheiding door te voeren, kunt u als tijdelijke oplossing meerdere AWS-accounts met één domein per account gebruiken.

De tweede uitdaging is om de toegang tot de Studio IDE beperken alleen voor gebruikers van binnen een bedrijfsnetwerk of een aangewezen VPC. U kunt dit bereiken door gebruik te maken van Op IAM gebaseerd beleid voor toegangscontrole. In dit geval moet het SageMaker-domein worden geconfigureerd met: IAM-verificatiemodus, omdat het op IAM-identiteit gebaseerde beleid niet wordt ondersteund door het aanmeldingsmechanisme in de AWS SSO-modus. De post Beveiligde toegang tot Amazon SageMaker Studio met AWS SSO en een SAML-applicatie lost deze uitdaging op en laat zien hoe u de netwerktoegang tot een SageMaker-domein kunt beheren.

Deze oplossing pakt deze uitdagingen aan van AWS SSO-gebruikersbeheer voor Studio voor een gemeenschappelijk gebruik van meerdere gebruikersgroepen en een veel-op-veel-toewijzing tussen gebruikers en teams. De oplossing beschrijft hoe u een aangepaste SAML 2.0-toepassing als het mechanisme om de gebruikersauthenticatie voor Studio te activeren en meerdere Studio-gebruikersprofielen per AWS SSO-gebruiker te ondersteunen.

U kunt deze aanpak gebruiken om een aangepaste gebruikersportal te implementeren met toepassingen die worden ondersteund door het SAML 2.0-autorisatieproces. Uw aangepaste gebruikersportal kan maximale flexibiliteit bieden bij het beheren en weergeven van gebruikerstoepassingen. De gebruikersportal kan bijvoorbeeld enkele ML-projectmetadata tonen om het identificeren van een applicatie voor toegang te vergemakkelijken.

U kunt de broncode van de oplossing vinden in onze GitHub-repository.

Overzicht oplossingen

De oplossing implementeert de volgende architectuur.

De belangrijkste architectuurcomponenten op hoog niveau zijn als volgt:

Identiteitsprovider – Gebruikers en groepen worden beheerd in een externe identiteitsbron, bijvoorbeeld in Azure AD. Gebruikerstoewijzingen aan AD-groepen bepalen welke machtigingen een bepaalde gebruiker heeft en tot welk Studio-team ze toegang hebben. De identiteitsbron moet worden gesynchroniseerd met AWS SSO.
AWS eenmalige aanmelding – AWS SSO beheert SSO-gebruikers, SSO-machtigingensets en applicaties. Deze oplossing maakt gebruik van een aangepaste SAML 2.0-toepassing om toegang tot Studio te bieden aan AWS SSO-gebruikers met rechten. De oplossing maakt ook gebruik van SAML-attribuuttoewijzing om de SAML-bevestiging te vullen met specifieke toegangsrelevante gegevens, zoals gebruikers-ID en gebruikersteam. Omdat de oplossing een SAML-API maakt, kunt u elke IdP gebruiken die SAML-bevestigingen ondersteunt om deze architectuur te maken. U kunt bijvoorbeeld Okta gebruiken of zelfs uw eigen webapplicatie die een landingspagina biedt met een gebruikersportaal en applicaties. Voor dit bericht gebruiken we AWS SSO.
Aangepaste SAML 2.0-toepassingen – De oplossing maakt één applicatie per Studio-team en wijst een of meerdere applicaties toe aan een gebruiker of een gebruikersgroep op basis van rechten. Gebruikers hebben toegang tot deze applicaties vanuit hun AWS SSO-gebruikersportal op basis van toegewezen machtigingen. Elke applicatie is geconfigureerd met de Amazon API-gateway eindpunt-URL als SAML-backend.
SageMaker-domein – De oplossing voorziet een SageMaker-domein in een AWS-account en maakt een speciaal gebruikersprofiel aan voor elke combinatie van AWS SSO-gebruiker en Studio-team waaraan de gebruiker is toegewezen. Het domein moet geconfigureerd zijn in IAM authenticatie modus.
Studio-gebruikersprofielen – De oplossing maakt automatisch een speciaal gebruikersprofiel aan voor elke combinatie van gebruiker en team. Als een gebruiker bijvoorbeeld lid is van twee Studio-teams en overeenkomstige machtigingen heeft, voorziet de oplossing in twee afzonderlijke gebruikersprofielen voor deze gebruiker. Elk profiel is altijd van één en slechts één gebruiker. Omdat u een Studio-gebruikersprofiel hebt voor elke mogelijke combinatie van een gebruiker en een team, moet u rekening houden met uw accountlimieten voor gebruikersprofielen voordat u deze aanpak implementeert. Als uw limiet bijvoorbeeld 500 gebruikersprofielen is en elke gebruiker lid is van twee teams, verbruikt u die limiet 2.5 keer sneller en kunt u 250 gebruikers onboarden. Met een groot aantal gebruikers raden we aan om meerdere domeinen en accounts te implementeren voor scheiding van beveiligingscontexten. Om het proof of concept te demonstreren, gebruiken we twee gebruikers, gebruiker 1 en gebruiker 2, en twee studioteams, team 1 en team 2. Gebruiker 1 behoort tot beide teams, terwijl gebruiker 2 alleen tot team 2 behoort. Gebruiker 1 heeft toegang tot Studio-omgevingen voor beide teams, terwijl gebruiker 2 alleen toegang heeft tot de Studio-omgeving voor Team 2.
Studio-uitvoeringsrollen – Elk Studio-gebruikersprofiel gebruikt een speciale uitvoeringsrol met machtigingsbeleid met het vereiste toegangsniveau voor het specifieke team waartoe de gebruiker behoort. Studio-uitvoeringsrollen implementeren een effectieve isolatie van machtigingen tussen individuele gebruikers en hun teamrollen. U beheert de toegang tot gegevens en bronnen voor elke rol en niet op individueel gebruikersniveau.

De oplossing implementeert ook een op attributen gebaseerde toegangscontrole (ABAC) met behulp van SAML 2.0-attributen, tags op Studio-gebruikersprofielen en tags op SageMaker-uitvoeringsrollen.

In deze specifieke configuratie gaan we ervan uit dat AWS SSO-gebruikers geen machtigingen hebben om in te loggen op het AWS-account en geen corresponderende AWS SSO-gecontroleerde IAM-rollen in het account hebben. Elke gebruiker logt in op zijn Studio-omgeving via een vooraf ondertekende URL van een AWS SSO-portal zonder dat hij naar de console in zijn AWS-account hoeft te gaan. In een echte wereld moet u mogelijk instellen AWS SSO-machtigingensets voor gebruikers om de geautoriseerde gebruikers toe te staan een IAM-rol op zich te nemen en zich aan te melden bij een AWS-account. U kunt een gebruiker bijvoorbeeld machtigingen voor de rol van gegevenswetenschapper geven om te kunnen communiceren met accountbronnen en om het toegangsniveau te krijgen dat ze nodig hebben om hun rol te vervullen.

Oplossingsarchitectuur en workflow

In het volgende diagram ziet u de end-to-end-aanmeldingsstroom voor een AWS SSO-gebruiker.

Een AWS SSO-gebruiker kiest een bijbehorende Studio-applicatie in zijn AWS SSO-portal. AWS SSO bereidt een SAML-bevestiging (1) voor met geconfigureerde SAML-kenmerktoewijzingen. Een aangepaste SAML-toepassing is geconfigureerd met de API Gateway-eindpunt-URL als Assertion Consumer Service (ACS) en heeft toewijzingskenmerken nodig die de AWS SSO-gebruikers-ID en team-ID bevatten. We gebruiken ssouserid en teamid aangepaste kenmerken om alle benodigde informatie naar de SAML-backend te sturen.

De API Gateway roept een SAML-backend-API aan. Een AWS Lambda functie (2) implementeert de API, parseert het SAML-antwoord om de gebruikers-ID en team-ID te extraheren. De functie gebruikt ze om een teamspecifieke configuratie op te halen, zoals een uitvoeringsrol en SageMaker-domein-ID. De functie controleert of er een vereist gebruikersprofiel bestaat in het domein en maakt een nieuw profiel aan met de bijbehorende configuratie-instellingen als er geen profiel bestaat. Daarna genereert de functie een door Studio vooraf ondertekende URL voor een specifiek Studio-gebruikersprofiel door aan te roepen: CreatePresignedDomainUrl API (3) via een SageMaker API VPC-eindpunt. De Lambda-functie retourneert uiteindelijk de vooraf ondertekende URL met HTTP 302-omleidingsreactie om de gebruiker aan te melden bij Studio.

De oplossing implementeert een niet-productievoorbeeldversie van een SAML-backend. De Lambda-functie parseert de SAML-bevestiging en gebruikt alleen attributen in de <saml2:AttributeStatement> element om a . te construeren CreatePresignedDomainUrl API-aanroep. In uw productieoplossing moet u een juiste SAML-backend-implementatie gebruiken, die een validatie van een SAML-reactie, een handtekening en certificaten, replay- en omleidingspreventie en alle andere functies van een SAML-authenticatieproces moet omvatten. U kunt bijvoorbeeld een python3-saml SAML-backend-implementatie or OneLogin open-source SAML-toolkit om een veilige SAML-backend te implementeren.

Dynamische creatie van Studio-gebruikersprofielen

De oplossing maakt automatisch een Studio-gebruikersprofiel aan voor elke combinatie van gebruiker en team, zodra het AWS SSO-aanmeldingsproces om een vooraf ondertekende URL vraagt. Voor deze proof of concept en eenvoud creëert de oplossing gebruikersprofielen op basis van de geconfigureerde metadata in de AWS SAM-sjabloon:

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

U kunt eigen teams, aangepaste instellingen en tags configureren door ze toe te voegen aan de metadataconfiguratie voor de AWS CloudFormation-resource GetUserProfileMetadata.

Voor meer informatie over configuratie-elementen van: UserSettings, verwijzen naar create_user_profile in boto3.

IAM-rollen

Het volgende diagram toont de IAM-rollen in deze oplossing.

De rollen zijn als volgt:

Studio uitvoeringsrol – Een Studio-gebruikersprofiel gebruikt een speciale Studio-uitvoeringsrol met gegevens en resourcemachtigingen die specifiek zijn voor elk team of elke gebruikersgroep. Deze rol kan ook tags gebruiken om ABAC te implementeren voor toegang tot gegevens en bronnen. Voor meer informatie, zie: SageMaker-rollen.

SAML-backend Lambda-uitvoeringsrol – Deze uitvoeringsrol bevat toestemming om de . aan te roepen CreatePresignedDomainUrl API. U kunt het machtigingsbeleid configureren om extra voorwaardelijke controles op te nemen met Condition sleutels. Als u bijvoorbeeld alleen toegang tot Studio wilt verlenen vanaf een aangewezen reeks IP-adressen binnen uw privé-bedrijfsnetwerk, gebruikt u de volgende 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"
        }
    ]
}

Raadpleeg voor meer voorbeelden over het gebruik van voorwaarden in IAM-beleid: Beheer de toegang tot de SageMaker API met behulp van op identiteit gebaseerd beleid.

SageMaker – SageMaker neemt namens u de Studio-uitvoeringsrol op zich, zoals bepaald door een bijbehorend vertrouwensbeleid voor de uitvoeringsrol. Hierdoor kan de service toegang krijgen tot gegevens en bronnen en namens u acties uitvoeren. De Studio-uitvoeringsrol moet een vertrouwensbeleid bevatten dat SageMaker in staat stelt deze rol op zich te nemen.
AWS SSO-machtigingen instellen IAM-rol – U kunt uw AWS SSO-gebruikers toewijzen aan AWS-accounts in uw AWS-organisatie via AWS SSO-machtigingensets. Een machtigingenset is een sjabloon die een verzameling gebruikersrolspecifieke IAM-beleidsregels definieert. U beheert machtigingensets in AWS SSO en AWS SSO beheert de bijbehorende IAM-rollen in elk account.

Servicebeheerbeleid van AWS-organisaties - Als je gebruikt AWS-organisaties, u kunt implementeren Servicecontrolebeleid (SCP's) om centraal de maximaal beschikbare machtigingen voor alle accounts en alle IAM-rollen in uw organisatie te beheren. Om bijvoorbeeld centraal toegang tot Studio via de console te voorkomen, kunt u het volgende SCP implementeren en koppelen aan de accounts met het SageMaker-domein:

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

Door de oplossing geleverde rollen

De AWS CloudFormatie stack voor deze oplossing worden drie Studio-uitvoeringsrollen gemaakt die worden gebruikt in het SageMaker-domein:

SageMakerStudioExecutionRoleDefault
SageMakerStudioExecutionRoleTeam1
SageMakerStudioExecutionRoleTeam2

Geen van de rollen heeft de AmazonSageMakerFullAccess beleid bijgevoegd, en elk heeft slechts een beperkte set machtigingen. In uw echte SageMaker-omgeving moet u de machtigingen van de rol aanpassen op basis van uw specifieke vereisten.

SageMakerStudioExecutionRoleDefault heeft alleen het aangepaste beleid SageMakerReadOnlyPolicy bijgevoegd met een beperkende lijst van toegestane acties.

Beide teamrollen, SageMakerStudioExecutionRoleTeam1 en SageMakerStudioExecutionRoleTeam2, hebben bovendien twee aangepaste beleidsregels, SageMakerAccessSupportingServicesPolicy en SageMakerStudioDeveloperAccessPolicy, waardoor het gebruik van bepaalde services en één alleen-weigeren-beleid mogelijk is, SageMakerDeniedServicesPolicy, met expliciete weigering op sommige SageMaker API-aanroepen.

Het Studio-toegangsbeleid voor ontwikkelaars dwingt de instelling van de: Team tag gelijk aan dezelfde waarde als de eigen uitvoeringsrol van de gebruiker voor het aanroepen van een 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"
}

Bovendien staat het het gebruik van verwijder-, stop-, update- en startbewerkingen alleen toe op resources die zijn getagd met dezelfde Team-tag als de uitvoeringsrol van de gebruiker:

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

Voor meer informatie over rollen en beleid, raadpleeg Amazon SageMaker Studio configureren voor teams en groepen met volledige bronisolatie.

Netwerk infrastructuur

De oplossing implementeert een volledig geïsoleerde SageMaker-domeinomgeving waar al het netwerkverkeer doorheen gaat AWS PrivéLink verbindingen. U kunt optioneel internettoegang inschakelen vanuit de Studio-notebooks. De oplossing creëert ook drie VPC-beveiligingsgroepen om het verkeer tussen alle oplossingscomponenten te regelen, zoals de SAML-backend Lambda-functie, VPC-eindpunten, en Studio-notebooks.

Voor dit proof of concept en eenvoud creëert de oplossing een SageMaker-subnet in een enkele Beschikbaarheidszone. Voor uw productie-installatie moet u meerdere privésubnetten in meerdere beschikbaarheidszones gebruiken en ervoor zorgen dat elk subnet de juiste grootte heeft, uitgaande van minimaal vijf IP's per gebruiker.

Deze oplossing voorziet in alle vereiste netwerkinfrastructuur. De CloudFormation-sjabloon ./cfn-templates/vpc.yaml bevat de broncode.

Implementatiestappen

Om de oplossing te implementeren en te testen, moet u de volgende stappen uitvoeren:

Implementeer de stack van de oplossing via een AWS serverloos toepassingsmodel (AWS SAM) -sjabloon.
Maak AWS SSO-gebruikers of gebruik bestaande AWS SSO-gebruikers.
Maak aangepaste SAML 2.0-applicaties en wijs AWS SSO-gebruikers toe aan de applicaties.

De volledige broncode voor de oplossing staat in onze GitHub bewaarplaats.

Voorwaarden

Om deze oplossing te gebruiken, de AWS-opdrachtregelinterface (AWS-CLI), AWS SAM CLI en Python3.8 of hoger moet geïnstalleerd worden.

De implementatieprocedure gaat ervan uit dat u AWS SSO hebt ingeschakeld en geconfigureerd voor de AWS-organisaties in het account waar de oplossing wordt geïmplementeerd.

Raadpleeg de instructies in . om AWS SSO in te stellen GitHub.

Opties voor implementatie van oplossingen

U kunt kiezen uit verschillende implementatie-opties voor oplossingen om de beste oplossing te vinden voor uw bestaande AWS-omgeving. U kunt ook de opties voor netwerk- en SageMaker-domeinregistratie selecteren. Voor gedetailleerde informatie over de verschillende implementatiekeuzes raadpleegt u de LEESMIJ-bestand.

De AWS SAM-sjabloon implementeren

Voer de volgende stappen uit om de AWS SAM-sjabloon te implementeren:

Kloon de broncode bewaarplaats naar uw lokale omgeving:

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

Bouw de AWS SAM-applicatie:
Implementeer de applicatie:
```
sam deploy --guided
```
Geef stackparameters op volgens uw bestaande omgeving en gewenste implementatieopties, zoals bestaande VPC, bestaande privé- en openbare subnetten en bestaand SageMaker-domein, zoals besproken in de Opties voor implementatie van oplossingen hoofdstuk van het README-bestand.

U kunt alle parameters op hun standaardwaarden laten staan om nieuwe netwerkbronnen en een nieuw SageMaker-domein in te richten. Raadpleeg het gedetailleerde parametergebruik in de README bestand als u standaardinstellingen moet wijzigen.

Wacht tot de stackimplementatie is voltooid. De end-to-end implementatie, inclusief het inrichten van alle netwerkbronnen en een SageMaker-domein, duurt ongeveer 20 minuten.

Voer de volgende opdracht in de terminal uit om de stapeluitvoer te zien:

export STACK_NAME=<SAM stack name>

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

SSO-gebruikers maken

Volg de instructies om AWS SSO-gebruikers toevoegen om twee gebruikers aan te maken met de namen Gebruiker1 en Gebruiker2 of gebruik twee van uw bestaande AWS SSO-gebruikers om de oplossing te testen. Zorg ervoor dat u AWS SSO gebruikt in dezelfde AWS-regio waarin u de oplossing hebt geïmplementeerd.

Maak aangepaste SAML 2.0-applicaties

Voer de volgende stappen uit om de vereiste aangepaste SAML 2.0-applicaties voor Team 1 en voor Team 2 te maken:

Open de AWS SSO-console in het AWS-beheeraccount van uw AWS-organisatie, in dezelfde regio waar u de oplossingstack hebt geïmplementeerd.
Kies Toepassingen in het navigatievenster.
Kies Een nieuwe toepassing toevoegen.
Kies Een aangepaste SAML 2.0-toepassing toevoegen.
Voor Gebruikersnaam, voer bijvoorbeeld een toepassingsnaam in SageMaker Studio Team 1.
Verlof Start-URL van toepassing en relais staat: leeg.
Kies Als je geen metadatabestand hebt, kun je handmatig je metadatawaarden invoeren.
Voor Applicatie ACS-URL, voer de URL in die is opgegeven in de SAMLBackendEndpoint sleutel van de AWS SAM-stackuitvoer.
Voor SAML-doelgroep van toepassing, voer de URL in die is opgegeven in de SAMLAudience sleutel van de AWS SAM-stackuitvoer.
Kies Wijzigingen opslaan.
Navigeer naar de Attribuuttoewijzingen Tab.
Kies het Onderwerp naar email en Formaat naar e-mailadres.
Voeg de volgende nieuwe attributen toe:
1. ssouserid ingesteld op ${user:AD_GUID}
2. teamid ingesteld op Team1 or Team2, respectievelijk, voor elke toepassing
Kies Wijzigingen opslaan.
Op de Toegewezen gebruikers tabblad, kies Wijs gebruikers toe.
Kies Gebruiker 1 voor de Team 1-applicatie en zowel Gebruiker 1 als Gebruiker 2 voor de Team 2-applicatie.
Kies Wijs gebruikers toe.

Test de oplossing

Voer de volgende stappen uit om de oplossing te testen:

Ga naar het AWS SSO-gebruikersportaal https://<Identity Store ID>.awsapps.com/start en meld u aan als Gebruiker 1.
In de portal worden twee SageMaker-toepassingen weergegeven.
Kies SageMaker Studio-team 1.
U wordt doorgestuurd naar de Studio-instantie voor Team 1 in een nieuw browservenster.
De eerste keer dat u Studio start, maakt SageMaker een JupyterServer-toepassing. Dit proces duurt enkele minuten.
In Studio, op de Dien in menu, kies New en terminal om een nieuwe terminal te starten.
Voer in de terminalopdrachtregel de volgende opdracht in:
```
aws sts get-caller-identity
```
De opdracht retourneert de Studio-uitvoeringsrol.

In onze opzet moet deze rol voor elk team anders zijn. U kunt ook controleren of elke gebruiker in elke instantie van Studio zijn eigen thuismap heeft op een gekoppeld Amazon EFS-volume.
Keer terug naar de AWS SSO-portal, nog steeds aangemeld als Gebruiker 1, en kies SageMaker Studio-team 2.
U wordt doorgestuurd naar een Team 2 Studio-instantie.
Het startproces kan weer enkele minuten duren, omdat SageMaker een nieuwe JupyterServer-toepassing voor gebruiker 2 start.
Meld u aan als gebruiker 2 in de AWS SSO-portal.
Aan gebruiker 2 is slechts één applicatie toegewezen: SageMaker Studio Team 2.

Als u een instantie van Studio start via deze gebruikerstoepassing, kunt u controleren of deze dezelfde SageMaker-uitvoeringsrol gebruikt als de Team 1-instantie van gebruiker 2. Elke Studio-instantie is echter volledig geïsoleerd. Gebruiker 2 heeft zijn eigen thuismap op een Amazon EFS-volume en een eigen exemplaar van de JupyterServer-toepassing. U kunt dit controleren door voor elk van de gebruikers een map en enkele bestanden te maken en te zien dat de thuismap van elke gebruiker is geïsoleerd.

Nu kunt u zich aanmelden bij de SageMaker-console en zien dat er drie gebruikersprofielen zijn gemaakt.

Je hebt zojuist een proof-of-concept-oplossing geïmplementeerd om meerdere gebruikers en teams met Studio te beheren.

Opruimen

Om kosten te voorkomen, moet u alle door het project geleverde en gegenereerde resources uit uw AWS-account verwijderen. Gebruik de volgende SAM CLI-opdracht om de oplossing CloudFormation-stack te verwijderen:

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

Om veiligheidsredenen en om gegevensverlies te voorkomen, worden de Amazon EFS-koppeling en de inhoud die is gekoppeld aan het Studio-domein dat in deze oplossing is geïmplementeerd, niet verwijderd. De VPC en subnetten die zijn gekoppeld aan het SageMaker-domein blijven in uw AWS-account. Voor instructies om het bestandssysteem en VPC te verwijderen, zie: Een Amazon EFS-bestandssysteem verwijderen en Werken met VPC's, Respectievelijk.

Voer de volgende stappen uit om de aangepaste SAML-toepassing te verwijderen:

Open de AWS SSO-console in het AWS SSO-beheeraccount.
Kies Toepassingen.
kies SageMaker Studio-team 1.
Op de Acties menu, kies verwijderen.
Herhaal deze stappen voor: SageMaker Studio-team 2.

Conclusie

Deze oplossing demonstreerde hoe u een flexibele en aanpasbare omgeving kunt creëren met AWS SSO en Studio-gebruikersprofielen ter ondersteuning van uw eigen organisatiestructuur. De volgende mogelijke verbeterstappen naar een productieklare oplossing kunnen zijn:

Implementeer geautomatiseerd Studio-gebruikersprofielbeheer als een speciale microservice om een geautomatiseerde workflow voor profielregistratie te ondersteunen en om metadata en configuratie voor gebruikersprofielen te verwerken, bijvoorbeeld in Amazon DynamoDB.
Gebruik hetzelfde mechanisme in een meer algemeen geval van meerdere SageMaker-domeinen en meerdere AWS-accounts. Dezelfde SAML-backend kan een overeenkomstige vooraf ondertekende URL verkopen die wordt omgeleid naar een combinatie van gebruikersprofiel-domein-account volgens uw aangepaste logica op basis van gebruikersrechten en teamconfiguratie.
Implementeer een synchronisatiemechanisme tussen uw IdP en AWS SSO en automatiseer het maken van aangepaste SAML 2.0-applicaties.
Implementeer schaalbaar data- en resourcetoegangsbeheer met: op attributen gebaseerde toegangscontrole (ABAC).

Als je feedback of vragen hebt, laat ze dan achter in de comments.

Verdere lezing

Documentatie

Artikelen

Over de auteur

Jevgeni Iljin is Solutions Architect bij AWS. Hij heeft meer dan 20 jaar ervaring in het werken op alle niveaus van softwareontwikkeling en oplossingsarchitectuur en heeft programmeertalen gebruikt van COBOL en Assembler tot .NET, Java en Python. Hij ontwikkelt en codeert cloud-native oplossingen met een focus op big data, analytics en data engineering.