Zarządzanie zespołem i użytkownikami za pomocą Amazon SageMaker i AWS SSO

Studio Amazon SageMaker to internetowe zintegrowane środowisko programistyczne (IDE) do uczenia maszynowego (ML), które umożliwia tworzenie, trenowanie, debugowanie, wdrażanie i monitorowanie modeli ML. Każdy wprowadzony użytkownik w Studio ma swój własny, dedykowany zestaw zasobów, takich jak instancje obliczeniowe, katalog domowy na System plików Amazon Elastic (Amazon EFS) i dedykowany AWS Zarządzanie tożsamością i dostępem (IAM) rola wykonawcza.

Jednym z najczęstszych rzeczywistych wyzwań związanych z konfigurowaniem dostępu użytkowników do programu Studio jest zarządzanie wieloma użytkownikami, grupami i zespołami analizy danych w celu uzyskania dostępu do danych i izolacji zasobów.

Wielu klientów wdraża zarządzanie użytkownikami przy użyciu tożsamości federacyjnych z Jednokrotne logowanie AWS (AWS SSO) i zewnętrzny dostawca tożsamości (IdP), taki jak Active Directory (AD) lub AWS Managed Microsoft AD directory. Jest zgodny z AWS zalecana praktyka używania tymczasowych poświadczeń w celu uzyskania dostępu do kont AWS.

An Amazon Sage Maker domena obsługuje AWS SSO i może być skonfigurowany w AWS SSO Tryb uwierzytelniania. W tym przypadku każdy uprawniony użytkownik AWS SSO ma swoje: Profil użytkownika Studio. Użytkownicy z dostępem do Studio mają unikalny adres URL logowania, który bezpośrednio otwiera Studio, i logują się przy użyciu swoich danych logowania AWS SSO. Organizacje zarządzają swoimi użytkownikami w AWS SSO zamiast w domenie SageMaker. Możesz jednocześnie przyznać dostęp do domeny wielu użytkownikom. Możesz użyć profili użytkowników Studio dla każdego użytkownika, aby zdefiniować jego uprawnienia bezpieczeństwa w notatnikach Studio za pomocą roli uprawnień dołączonej do profilu użytkownika, zwanej rola wykonawcza. Ta rola kontroluje uprawnienia do operacji SageMaker zgodnie z jego zasadami uprawnień.

W trybie uwierzytelniania AWS SSO zawsze istnieje mapowanie jeden do jednego między użytkownikami a profilami użytkowników. Domena SageMaker zarządza tworzeniem profili użytkowników na podstawie identyfikatora użytkownika AWS SSO. Nie możesz tworzyć profili użytkowników za pomocą Konsola zarządzania AWS. Działa to dobrze w przypadku, gdy jeden użytkownik jest członkiem tylko jednego zespołu analityki danych lub jeśli użytkownicy mają takie same lub bardzo podobne wymagania dotyczące dostępu we wszystkich swoich projektach i zespołach. W bardziej powszechnym przypadku użycia, gdy użytkownik może uczestniczyć w wielu projektach ML i być członkiem wielu zespołów z nieco innymi wymaganiami dotyczącymi uprawnień, użytkownik potrzebuje dostępu do różnych profili użytkowników Studio z różnymi rolami wykonywania i zasadami uprawnień. Ponieważ nie możesz zarządzać profilami użytkowników niezależnie od AWS SSO w trybie uwierzytelniania AWS SSO, nie możesz zaimplementować mapowania jeden-do-wielu między użytkownikami a profilami użytkowników Studio.

Jeśli musisz ustanowić silne rozdzielenie kontekstów bezpieczeństwa, na przykład dla różnych kategorii danych, lub musisz całkowicie uniemożliwić widoczność aktywności i zasobów jednej grupy użytkowników dla innej, zalecanym podejściem jest utworzenie wielu domen SageMaker. W chwili pisania tego tekstu możesz utworzyć tylko jedną domenę na konto AWS na region. Aby zaimplementować silną separację, możesz użyć wielu kont AWS z jedną domeną na konto jako obejście.

Drugim wyzwaniem jest: ograniczyć dostęp do IDE Studio tylko użytkownikom z sieci firmowej lub wyznaczonego VPC. Możesz to osiągnąć, używając Zasady kontroli dostępu oparte na uprawnieniach. W takim przypadku domena SageMaker musi być skonfigurowana za pomocą Tryb uwierzytelniania uprawnień, ponieważ zasady oparte na tożsamości IAM nie są obsługiwane przez mechanizm logowania w trybie logowania jednokrotnego AWS. Poczta Bezpieczny dostęp do Amazon SageMaker Studio z AWS SSO i aplikacją SAML rozwiązuje to wyzwanie i pokazuje, jak kontrolować dostęp sieciowy do domeny SageMaker.

To rozwiązanie jest odpowiedzią na te wyzwania związane z zarządzaniem użytkownikami AWS SSO dla Studio w przypadku typowego przypadku użycia wielu grup użytkowników i mapowania wiele-do-wielu między użytkownikami i zespołami. Rozwiązanie przedstawia, jak używać a niestandardowa aplikacja SAML 2.0 jako mechanizm wyzwalający uwierzytelnianie użytkownika dla Studio i obsługujący wiele profili użytkowników Studio na jednego użytkownika AWS SSO.

Możesz użyć tego podejścia do zaimplementowania niestandardowego portalu użytkownika z aplikacjami wspieranymi przez proces autoryzacji SAML 2.0. Twój niestandardowy portal użytkownika może mieć maksymalną elastyczność w zakresie zarządzania i wyświetlania aplikacji użytkowników. Na przykład portal użytkownika może wyświetlać niektóre metadane projektu ML, aby ułatwić identyfikację aplikacji, do której można uzyskać dostęp.

Kod źródłowy rozwiązania można znaleźć w naszym Repozytorium GitHub.

Omówienie rozwiązania

Rozwiązanie implementuje następującą architekturę.

Główne komponenty architektury wysokiego poziomu to:

1. Dostawca tożsamości – Użytkownicy i grupy są zarządzane w zewnętrznym źródle tożsamości, na przykład w usłudze Azure AD. Przypisania użytkowników do grup AD określają, jakie uprawnienia ma dany użytkownik i do jakiego zespołu Studio ma dostęp. Źródło tożsamości musi być zsynchronizowane z logowaniem jednokrotnym AWS.
2. Jednokrotne logowanie w AWS – AWS SSO zarządza użytkownikami SSO, zestawami uprawnień SSO i aplikacjami. To rozwiązanie wykorzystuje niestandardową aplikację SAML 2.0, aby zapewnić dostęp do Studio uprawnionym użytkownikom AWS SSO. Rozwiązanie wykorzystuje również mapowanie atrybutów SAML do wypełniania potwierdzenia SAML określonymi danymi dotyczącymi dostępu, takimi jak identyfikator użytkownika i zespół użytkowników. Ponieważ rozwiązanie tworzy interfejs API SAML, do utworzenia tej architektury można użyć dowolnego dostawcy tożsamości obsługującego potwierdzenia SAML. Na przykład możesz użyć Okta lub nawet własnej aplikacji internetowej, która udostępnia stronę docelową z portalem użytkownika i aplikacjami. W tym poście używamy AWS SSO.
3. Niestandardowe aplikacje SAML 2.0 – Rozwiązanie tworzy jedną aplikację na zespół Studio i przypisuje jedną lub wiele aplikacji do użytkownika lub grupy użytkowników na podstawie uprawnień. Użytkownicy mogą uzyskiwać dostęp do tych aplikacji z poziomu swojego portalu użytkownika AWS SSO na podstawie przypisanych uprawnień. Każda aplikacja jest skonfigurowana za pomocą Brama Amazon API URL punktu końcowego jako jego backend SAML.
4. Domena SageMakera – Rozwiązanie udostępnia domenę SageMaker na koncie AWS i tworzy dedykowany profil użytkownika dla każdej kombinacji użytkownika AWS SSO i zespołu Studio, do którego użytkownik jest przypisany. Domena musi być skonfigurowana w uprawnieniach Tryb uwierzytelniania.
5. Profile użytkowników Studio – Rozwiązanie automatycznie tworzy dedykowany profil użytkownika dla każdej kombinacji użytkownik-zespół. Jeśli na przykład użytkownik jest członkiem dwóch zespołów Studio i ma odpowiednie uprawnienia, rozwiązanie udostępnia dwa oddzielne profile użytkowników dla tego użytkownika. Każdy profil zawsze należy do jednego i tylko jednego użytkownika. Ponieważ masz profil użytkownika Studio dla każdej możliwej kombinacji użytkownika i zespołu, przed wdrożeniem tego podejścia musisz wziąć pod uwagę limity swojego konta dla profili użytkowników. Na przykład, jeśli Twój limit wynosi 500 profili użytkowników, a każdy użytkownik jest członkiem dwóch zespołów, zużywasz ten limit 2.5 razy szybciej, dzięki czemu możesz wprowadzić 250 użytkowników. W przypadku dużej liczby użytkowników zalecamy wdrożenie wielu domen i kont w celu separacji kontekstu bezpieczeństwa. Aby zademonstrować weryfikację koncepcji, używamy dwóch użytkowników, Użytkownika 1 i Użytkownika 2, oraz dwóch zespołów Studio, Zespołu 1 i Zespołu 2. Użytkownik 1 należy do obu zespołów, podczas gdy Użytkownik 2 należy tylko do Zespołu 2. Użytkownik 1 może uzyskać dostęp do środowisk Studio dla obu zespołów, podczas gdy Użytkownik 2 może uzyskać dostęp tylko do środowiska Studio dla zespołu 2.
6. Role wykonawcze w studiu – Każdy profil użytkownika Studio wykorzystuje dedykowaną rolę wykonawczą z politykami uprawnień z wymaganym poziomem dostępu dla określonego zespołu, do którego należy użytkownik. Role wykonawcze w Studio implementują skuteczną izolację uprawnień między poszczególnymi użytkownikami i ich rolami w zespole. Zarządzasz dostępem do danych i zasobów dla każdej roli, a nie na poziomie pojedynczego użytkownika.

Rozwiązanie implementuje również kontrolę dostępu opartą na atrybutach (ABAC) przy użyciu atrybutów SAML 2.0, tagów w profilach użytkowników Studio i tagów w rolach wykonawczych SageMaker.

W tej konkretnej konfiguracji zakładamy, że użytkownicy AWS SSO nie mają uprawnień do logowania się do konta AWS i nie mają na koncie odpowiednich ról IAM kontrolowanych przez AWS SSO. Każdy użytkownik loguje się do swojego środowiska Studio za pomocą wcześniej podpisanego adresu URL z portalu AWS SSO bez konieczności przechodzenia do konsoli na swoim koncie AWS. W rzeczywistym środowisku może być konieczne skonfigurowanie Zestawy uprawnień logowania jednokrotnego AWS dla użytkowników, aby umożliwić autoryzowanym użytkownikom przejęcie roli uprawnień i zalogowanie się do konta AWS. Na przykład możesz zapewnić uprawnienia roli analityka danych, aby użytkownik mógł wchodzić w interakcje z zasobami konta i mieć poziom dostępu potrzebny do pełnienia swojej roli.

Architektura rozwiązania i przepływ pracy

Poniższy diagram przedstawia pełny proces logowania dla użytkownika AWS SSO.

Użytkownik AWS SSO wybiera odpowiednią aplikację Studio w swoim portalu AWS SSO. Jednokrotne logowanie w AWS przygotowuje asercję SAML (1) ze skonfigurowanymi mapowaniami atrybutów SAML. Niestandardowa aplikacja SAML jest skonfigurowana z adresem URL punktu końcowego bramy interfejsu API jako jej usługą klienta potwierdzenia (ACS) i wymaga atrybutów mapowania zawierających identyfikator użytkownika logowania jednokrotnego AWS i identyfikator zespołu. Używamy ssouserid i teamid niestandardowe atrybuty do wysyłania wszystkich potrzebnych informacji do zaplecza SAML.

API Gateway wywołuje interfejs API zaplecza SAML. jakiś AWS Lambda funkcja (2) implementuje API, analizuje odpowiedź SAML, aby wyodrębnić identyfikator użytkownika i identyfikator zespołu. Funkcja używa ich do pobrania konfiguracji specyficznej dla zespołu, takiej jak rola wykonawcza i identyfikator domeny SageMaker. Funkcja sprawdza, czy w domenie istnieje wymagany profil użytkownika i tworzy nowy z odpowiednimi ustawieniami konfiguracyjnymi, jeśli profil nie istnieje. Następnie funkcja generuje predefiniowany adres URL Studio dla określonego profilu użytkownika Studio, wywołując UtwórzPresignedDomainUrl API (3) za pośrednictwem punktu końcowego SageMaker API VPC. Funkcja Lambda w końcu zwraca wcześniej podpisany adres URL z odpowiedzią przekierowania HTTP 302 w celu zalogowania użytkownika do Studio.

Rozwiązanie implementuje nieprodukcyjną wersję próbną backendu SAML. Funkcja Lambda analizuje asercję SAML i używa tylko atrybutów w <saml2:AttributeStatement> element do skonstruowania CreatePresignedDomainUrl Wywołanie API. W rozwiązaniu produkcyjnym należy użyć odpowiedniej implementacji zaplecza SAML, która musi obejmować weryfikację odpowiedzi SAML, podpisu i certyfikatów, zapobieganie powtarzaniu i przekierowywaniu oraz wszelkie inne funkcje procesu uwierzytelniania SAML. Na przykład możesz użyć Implementacja backendu SAML w python3-saml or Zestaw narzędzi SAML o otwartym kodzie źródłowym OneLogin zaimplementować bezpieczny backend SAML.

Dynamiczne tworzenie profili użytkowników Studio

Rozwiązanie automatycznie tworzy profil użytkownika Studio dla każdej kombinacji użytkowników i zespołów, gdy tylko proces logowania AWS SSO zażąda wstępnie podpisanego adresu URL. W celu sprawdzenia koncepcji i prostoty rozwiązanie tworzy profile użytkowników na podstawie skonfigurowanych metadanych w AWS Szablon 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

Możesz skonfigurować własne zespoły, niestandardowe ustawienia i tagi, dodając je do konfiguracji metadanych dla zasobu AWS CloudFormation GetUserProfileMetadata.

Więcej informacji na temat elementów konfiguracji UserSettings, odnosić się do utwórz_profil_użytkownika w boto3.

Role IAM

Poniższy diagram przedstawia role uprawnień w tym rozwiązaniu.

Role są następujące:

1. Rola wykonawcza studia – Profil użytkownika Studio używa dedykowanej roli wykonawczej Studio z uprawnieniami do danych i zasobów specyficznymi dla każdego zespołu lub grupy użytkowników. Ta rola może również używać tagów do implementacji ABAC dla dostępu do danych i zasobów. Aby uzyskać więcej informacji, zobacz Role Mędrca.
2. Rola wykonania SAML zaplecza Lambda – Ta rola wykonawcza zawiera uprawnienia do wywoływania CreatePresignedDomainUrl API. Możesz skonfigurować politykę uprawnień, aby zawierała dodatkowe kontrole warunkowe za pomocą Condition Klucze. Na przykład, aby zezwolić na dostęp do Studio tylko z określonego zakresu adresów IP w prywatnej sieci firmowej, użyj następującego kodu:

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

   Aby uzyskać więcej przykładów używania warunków w zasadach uprawnień, zobacz Kontroluj dostęp do interfejsu API SageMaker za pomocą zasad opartych na tożsamości.

3. SageMaker – SageMaker przejmuje w Twoim imieniu rolę wykonawczą Studio, co jest kontrolowane przez odpowiednią politykę zaufania dotyczącą roli wykonawczej. Umożliwia to usłudze dostęp do danych i zasobów oraz wykonywanie działań w Twoim imieniu. Rola wykonawcza Studio musi zawierać politykę zaufania umożliwiającą SageMaker przejęcie tej roli.
4. Rola uprawnień zestawu uprawnień do logowania jednokrotnego w AWS – Możesz przypisać użytkowników AWS SSO do kont AWS w Twojej organizacji AWS przez Zestawy uprawnień logowania jednokrotnego AWS. Zestaw uprawnień to szablon, który definiuje zbiór zasad uprawnień specyficznych dla roli użytkownika. Zarządzasz zestawami uprawnień w AWS SSO, a AWS SSO kontroluje odpowiednie role uprawnień na każdym koncie.
5. Zasady kontroli usług organizacji AWS - Jeśli użyjesz Organizacje AWS, możesz wdrożyć Zasady kontroli usług (SCP) do centralnego kontrolowania maksymalnych dostępnych uprawnień dla wszystkich kont i wszystkich ról uprawnień w Twojej organizacji. Na przykład, aby centralnie uniemożliwić dostęp do Studio za pośrednictwem konsoli, możesz zaimplementować następujący SCP i dołączyć go do kont w domenie SageMaker:

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

Role udostępniane w rozwiązaniach

Połączenia Tworzenie chmury AWS stos dla tego rozwiązania tworzy trzy role wykonawcze Studio używane w domenie SageMaker:

• SageMakerStudioExecutionRoleDefault
• SageMakerStudioExecutionRoleTeam1
• SageMakerStudioExecutionRoleTeam2

Żadna z ról nie ma AmazonSageMakerPełny dostęp dołączona polityka, a każda z nich ma tylko ograniczony zestaw uprawnień. W swoim rzeczywistym środowisku SageMaker musisz zmienić uprawnienia roli w oparciu o swoje specyficzne wymagania.

SageMakerStudioExecutionRoleDefault ma tylko niestandardową politykę SageMakerReadOnlyPolicy załączona z restrykcyjną listą dozwolonych działań.

Obie role zespołowe, SageMakerStudioExecutionRoleTeam1 i SageMakerStudioExecutionRoleTeam2, dodatkowo mają dwie niestandardowe polisy, SageMakerAccessSupportingServicesPolicy i SageMakerStudioDeveloperAccessPolicy, umożliwiających korzystanie z poszczególnych usług i jednej polityki odmowy, SageMakerDeniedServicesPolicy, z jawną odmową w przypadku niektórych wywołań interfejsu API SageMaker.

Zasady dostępu programistów Studio wymuszają ustawienie Team tag równy tej samej wartości, co rola wykonawcza użytkownika dla wywołania dowolnego SageMaker Create* OGIEŃ:

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

Ponadto pozwala na użycie operacji usuwania, zatrzymywania, aktualizacji i uruchamiania tylko na zasobach oznaczonych tym samym tagiem Team, co rola wykonawcza użytkownika:

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

Aby uzyskać więcej informacji na temat ról i zasad, patrz Konfiguracja Amazon SageMaker Studio dla zespołów i grup z pełną izolacją zasobów.

Infrastruktura sieci

Rozwiązanie implementuje w pełni izolowane środowisko domeny SageMaker, przez które przechodzi cały ruch sieciowy Prywatny link AWS znajomości. Możesz opcjonalnie włączyć dostęp do Internetu z notatników Studio. Rozwiązanie tworzy również trzy Grupy bezpieczeństwa VPC do kontroli ruchu pomiędzy wszystkimi komponentami rozwiązania takimi jak funkcja Lambda backendu SAML, punkty końcowe VPC, i zeszyty studyjne.

W celu sprawdzenia koncepcji i prostoty rozwiązanie tworzy podsieć SageMaker w jednym Strefa dostępności. W przypadku konfiguracji produkcyjnej należy użyć wielu prywatnych podsieci w wielu strefach dostępności i upewnić się, że każda podsieć ma odpowiedni rozmiar, przy założeniu co najmniej pięciu adresów IP na użytkownika.

To rozwiązanie zapewnia całą wymaganą infrastrukturę sieciową. Szablon CloudFormation ./cfn-templates/vpc.yaml zawiera kod źródłowy.

Etapy wdrażania

Aby wdrożyć i przetestować rozwiązanie, musisz wykonać następujące kroki:

1. Wdróż stos rozwiązania za pomocą AWS Serverless Model aplikacji (AWS SAM).
2. Utwórz użytkowników AWS SSO lub użyj istniejących użytkowników AWS SSO.
3. Twórz niestandardowe aplikacje SAML 2.0 i przypisuj do nich użytkowników logowania jednokrotnego AWS.

Pełny kod źródłowy rozwiązania znajduje się w naszym serwisie GitHub składnica.

Wymagania wstępne

Aby skorzystać z tego rozwiązania, Interfejs wiersza poleceń AWS (interfejs wiersza poleceń AWS), CLI AWS SAM, Python3.8 lub nowszy musi być zainstalowane.

Procedura wdrażania zakłada, że ​​włączono logowanie jednokrotne w AWS i skonfigurowano dla Organizacje AWS na koncie, na którym wdrożono rozwiązanie.

Aby skonfigurować AWS SSO, zapoznaj się z instrukcjami w GitHub.

Opcje wdrażania rozwiązania

Możesz wybierać spośród kilku opcji wdrażania rozwiązania, aby najlepiej dopasować je do istniejącego środowiska AWS. Możesz także wybrać opcje udostępniania sieci i domeny SageMaker. Aby uzyskać szczegółowe informacje na temat różnych opcji wdrażania, zobacz Plik README.

Wdróż szablon AWS SAM

Aby wdrożyć szablon AWS SAM, wykonaj następujące kroki:

1. Sklonuj kod źródłowy składnica do lokalnego środowiska:

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

2. Zbuduj aplikację AWS SAM:
3. Wdróż aplikację:

   sam deploy --guided

4. Podaj parametry stosu zgodnie z istniejącym środowiskiem i pożądanymi opcjami wdrażania, takimi jak istniejące VPC, istniejące podsieci prywatne i publiczne oraz istniejąca domena SageMaker, zgodnie z opisem w Opcje wdrażania rozwiązania rozdział pliku README.

Możesz pozostawić wszystkie parametry bez wartości domyślnych, aby udostępnić nowe zasoby sieciowe i nową domenę SageMaker. Zapoznaj się ze szczegółowym użyciem parametrów w README plik, jeśli chcesz zmienić ustawienia domyślne.

Poczekaj na zakończenie wdrażania stosu. Kompleksowe wdrożenie, w tym udostępnienie wszystkich zasobów sieciowych i domeny SageMaker, zajmuje około 20 minut.

Aby zobaczyć dane wyjściowe stosu, uruchom następujące polecenie w terminalu:

export STACK_NAME=<SAM stack name>

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

Utwórz użytkowników SSO

Postępuj zgodnie z instrukcjami, aby dodaj użytkowników AWS SSO aby utworzyć dwóch użytkowników o nazwach Użytkownik1 i Użytkownik2 lub użyć dowolnych dwóch istniejących użytkowników AWS SSO do przetestowania rozwiązania. Upewnij się, że używasz logowania jednokrotnego AWS w tym samym regionie AWS, w którym wdrożono rozwiązanie.

Twórz niestandardowe aplikacje SAML 2.0

Aby utworzyć wymagane niestandardowe aplikacje SAML 2.0 dla Zespołu 1 i Zespołu 2, wykonaj następujące czynności:

1. Otwórz konsolę AWS SSO na koncie zarządzania AWS swojej organizacji AWS, w tym samym regionie, w którym wdrożono stos rozwiązań.
2. Dodaj Zastosowania w okienku nawigacji.
3. Dodaj Dodaj nową aplikację.
4. Dodaj Dodaj niestandardową aplikację SAML 2.0.
5. W razie zamówieenia projektu Wyświetlana nazwa, wpisz nazwę aplikacji, na przykład SageMaker Studio Team 1.
6. Pozostawiać URL początkowy aplikacji i Stan przekaźnika pusty.
7. Dodaj Jeśli nie masz pliku metadanych, możesz ręcznie wprowadzić wartości metadanych.
8. W razie zamówieenia projektu Adres URL aplikacji ACS, wprowadź adres URL podany w SAMLBackendEndpoint klucz wyjścia stosu AWS SAM.
9. W razie zamówieenia projektu Odbiorcy aplikacji SAML, wprowadź adres URL podany w SAMLAudience klucz wyjścia stosu AWS SAM.
10. Dodaj Zapisz zmiany.
    
11. Nawiguj do Mapowania atrybutów patka.
12. Ustaw Temat do E-mail i utworzony do adres e-mail.
13. Dodaj następujące nowe atrybuty:
    1. ssouserid Ustawić ${user:AD_GUID}
    2. teamid Ustawić Team1 or Team2, odpowiednio, dla każdej aplikacji
       
14. Dodaj Zapisz zmiany.
15. Na Przypisani użytkownicy kartę, wybierz Przypisz użytkowników.
16. Wybierz Użytkownik 1 dla aplikacji Zespół 1 i Użytkownik 1 i Użytkownik 2 dla aplikacji Zespół 2.
17. Dodaj Przypisz użytkowników.
    

Przetestuj rozwiązanie

Aby przetestować rozwiązanie, wykonaj następujące czynności:

1. Przejdź do portalu użytkownika AWS SSO https://<Identity Store ID>.awsapps.com/start i podpisz jako Użytkownik 1.
   W portalu widoczne są dwie aplikacje SageMaker.
   
2. Dodaj Zespół SageMaker Studio 1.
   Przekierujemy Cię do instancji Studio zespołu 1 w nowym oknie przeglądarki.
   Przy pierwszym uruchomieniu programu SageMaker tworzy aplikację JupyterServer. Ten proces trwa kilka minut.
   
3. W Studio, na filet menu, wybierz Nowości i terminal aby uruchomić nowy terminal.
4. W wierszu poleceń terminala wpisz następujące polecenie:

   aws sts get-caller-identity

   Polecenie zwraca rolę wykonawczą Studio.
   

   W naszej konfiguracji ta rola musi być inna dla każdego zespołu. Możesz również sprawdzić, czy każdy użytkownik w każdej instancji Studio ma swój własny katalog domowy na zamontowanym woluminie Amazon EFS.

5. Wróć do portalu AWS SSO, nadal zalogowany jako Użytkownik 1, i wybierz Zespół SageMaker Studio 2.
   Nastąpi przekierowanie do instancji Team 2 Studio.
   Proces uruchamiania może ponownie zająć kilka minut, ponieważ SageMaker uruchamia nową aplikację JupyterServer dla Użytkownika 2.
6. Zaloguj się jako użytkownik 2 w portalu AWS SSO.
   Użytkownik 2 ma przypisaną tylko jedną aplikację: SageMaker Studio Team 2.
   

Jeśli uruchomisz instancję Studio za pomocą tej aplikacji użytkownika, możesz sprawdzić, czy używa ona tej samej roli wykonawczej SageMaker, co instancja Team 1 użytkownika 2. Jednak każda instancja Studio jest całkowicie izolowana. Użytkownik 2 ma swój własny katalog domowy na wolumenie Amazon EFS i własną instancję aplikacji JupyterServer. Możesz to sprawdzić, tworząc folder i kilka plików dla każdego użytkownika i sprawdzając, czy katalog domowy każdego użytkownika jest odizolowany.

Teraz możesz zalogować się do konsoli SageMaker i zobaczyć, że zostały utworzone trzy profile użytkowników.

Właśnie wdrożyłeś rozwiązanie sprawdzające koncepcję, aby zarządzać wieloma użytkownikami i zespołami za pomocą Studio.

Sprzątać

Aby uniknąć opłat, musisz usunąć wszystkie zasoby udostępnione i wygenerowane przez projekt ze swojego konta AWS. Użyj następującego polecenia SAM CLI, aby usunąć stos rozwiązania CloudFormation:

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

Ze względów bezpieczeństwa i aby zapobiec utracie danych, mount Amazon EFS i zawartość powiązana z domeną Studio wdrożoną w tym rozwiązaniu nie są usuwane. VPC i podsieci powiązane z domeną SageMaker pozostają na Twoim koncie AWS. Aby uzyskać instrukcje dotyczące usuwania systemu plików i VPC, zobacz Usuwanie systemu plików Amazon EFS i Pracuj z VPC, Odpowiednio.

Aby usunąć niestandardową aplikację SAML, wykonaj następujące czynności:

1. Otwórz konsolę AWS SSO na koncie zarządzania AWS SSO.
2. Dodaj Zastosowania.
3. Wybierz Zespół SageMaker Studio 1.
4. Na Akcje menu, wybierz Usunąć.
5. Powtórz te kroki dla Zespół SageMaker Studio 2.

Wnioski

To rozwiązanie pokazało, jak można stworzyć elastyczne i konfigurowalne środowisko przy użyciu profili użytkowników AWS SSO i Studio, aby wspierać własną strukturę organizacji. Kolejnymi możliwymi krokami ulepszeń w kierunku rozwiązania gotowego do produkcji mogą być:

• Wdróż zautomatyzowane zarządzanie profilami użytkowników Studio jako dedykowaną mikrousługę, aby wspierać zautomatyzowany przepływ pracy udostępniania profili oraz obsługiwać metadane i konfigurację profili użytkowników, na przykład w Amazon DynamoDB.
• Użyj tego samego mechanizmu w bardziej ogólnym przypadku wielu domen SageMaker i wielu kont AWS. Ten sam backend SAML może dostarczać odpowiedni wcześniej podpisany adres URL przekierowujący do kombinacji profil użytkownika-domena-konto zgodnie z niestandardową logiką opartą na uprawnieniach użytkowników i konfiguracji zespołu.
• Zaimplementuj mechanizm synchronizacji między swoim dostawcą tożsamości a logowaniem jednokrotnym AWS i zautomatyzuj tworzenie niestandardowych aplikacji SAML 2.0.
• Implementuj skalowalne zarządzanie dostępem do danych i zasobów za pomocą kontrola dostępu oparta na atrybutach (ABAK).

Jeśli masz jakieś uwagi lub pytania, zostaw je w komentarzach.

Dalsze czytanie

Dokumenty

Blogach

O autorze

Jewgienij Iljin jest architektem rozwiązań w AWS. Ma ponad 20-letnie doświadczenie w pracy na wszystkich poziomach tworzenia oprogramowania i architektury rozwiązań. Używał języków programowania od COBOL i Assembler po .NET, Java i Python. Tworzy i koduje rozwiązania natywne w chmurze ze szczególnym uwzględnieniem big data, analityki i inżynierii danych.