Manajemen tim dan pengguna dengan Amazon SageMaker dan AWS SSO

Studio Amazon SageMaker adalah lingkungan pengembangan terintegrasi (IDE) berbasis web untuk pembelajaran mesin (ML) yang memungkinkan Anda membangun, melatih, men-debug, menerapkan, dan memantau model ML Anda. Setiap pengguna yang terpasang di Studio memiliki kumpulan sumber daya khusus mereka sendiri, seperti instans komputasi, direktori home di dan Sistem File Amazon Elastis (Amazon EFS), dan volume khusus Identitas AWS dan Manajemen Akses (IAM) peran eksekusi.

Salah satu tantangan dunia nyata yang paling umum dalam menyiapkan akses pengguna untuk Studio adalah bagaimana mengelola beberapa pengguna, grup, dan tim ilmu data untuk akses data dan isolasi sumber daya.

Banyak pelanggan menerapkan manajemen pengguna menggunakan identitas gabungan dengan Sistem Masuk Tunggal AWS (AWS SSO) dan penyedia identitas eksternal (IdP), seperti Active Directory (AD) atau direktori AWS Managed Microsoft AD. Ini selaras dengan AWS praktek yang direkomendasikan menggunakan kredensial sementara untuk mengakses akun AWS.

An Amazon SageMaker domain mendukung AWS SSO dan dapat dikonfigurasi di AWS SSO Mode Autentikasi. Dalam hal ini, setiap pengguna AWS SSO yang berhak memilikinya sendiri profil pengguna studio. Pengguna yang diberi akses ke Studio memiliki URL masuk unik yang langsung membuka Studio, dan mereka masuk dengan kredensial AWS SSO mereka. Organisasi mengelola penggunanya di AWS SSO, bukan di domain SageMaker. Anda dapat menetapkan akses beberapa pengguna ke domain secara bersamaan. Anda dapat menggunakan profil pengguna Studio untuk setiap pengguna guna menentukan izin keamanan mereka di notebook Studio melalui peran IAM yang dilampirkan ke profil pengguna, yang disebut peran eksekusi. Peran ini mengontrol izin untuk operasi SageMaker sesuai dengan kebijakan izin IAM-nya.

Dalam mode otentikasi SSO AWS, selalu ada pemetaan satu-ke-satu antara pengguna dan profil pengguna. Domain SageMaker mengelola pembuatan profil pengguna berdasarkan ID pengguna AWS SSO. Anda tidak dapat membuat profil pengguna melalui Konsol Manajemen AWS. Ini berfungsi dengan baik jika satu pengguna adalah anggota hanya dari satu tim ilmu data atau jika pengguna memiliki persyaratan akses yang sama atau sangat mirip di seluruh proyek dan tim mereka. Dalam kasus penggunaan yang lebih umum, ketika pengguna dapat berpartisipasi dalam beberapa proyek ML dan menjadi anggota beberapa tim dengan persyaratan izin yang sedikit berbeda, pengguna memerlukan akses ke profil pengguna Studio yang berbeda dengan peran eksekusi dan kebijakan izin yang berbeda. Karena Anda tidak dapat mengelola profil pengguna secara terpisah dari AWS SSO dalam mode autentikasi AWS SSO, Anda tidak dapat menerapkan pemetaan satu-ke-banyak antara pengguna dan profil pengguna Studio.

Jika Anda perlu membuat pemisahan konteks keamanan yang kuat, misalnya untuk kategori data yang berbeda, atau perlu sepenuhnya mencegah visibilitas satu grup aktivitas dan sumber daya pengguna ke grup lainnya, pendekatan yang disarankan adalah membuat beberapa domain SageMaker. Pada saat penulisan ini, Anda hanya dapat membuat satu domain per akun AWS per Wilayah. Untuk menerapkan pemisahan yang kuat, Anda dapat menggunakan beberapa akun AWS dengan satu domain per akun sebagai solusinya.

Tantangan kedua adalah untuk membatasi akses ke Studio IDE hanya untuk pengguna dari dalam jaringan perusahaan atau VPC yang ditunjuk. Anda dapat mencapai ini dengan menggunakan Kebijakan kontrol akses berbasis IAM. Dalam hal ini, domain SageMaker harus dikonfigurasi dengan Mode otentikasi IAM, karena kebijakan berbasis identitas IAM tidak didukung oleh mekanisme masuk dalam mode AWS SSO. Postingan Akses aman ke Amazon SageMaker Studio dengan AWS SSO dan aplikasi SAML memecahkan tantangan ini dan menunjukkan cara mengontrol akses jaringan ke domain SageMaker.

Solusi ini mengatasi tantangan manajemen pengguna AWS SSO untuk Studio untuk kasus penggunaan umum beberapa grup pengguna dan pemetaan banyak-ke-banyak antara pengguna dan tim. Solusinya menguraikan cara menggunakan a aplikasi SAML 2.0 khusus sebagai mekanisme untuk memicu autentikasi pengguna untuk Studio dan mendukung beberapa profil pengguna Studio per satu pengguna AWS SSO.

Anda dapat menggunakan pendekatan ini untuk menerapkan portal pengguna khusus dengan aplikasi yang didukung oleh proses otorisasi SAML 2.0. Portal pengguna kustom Anda dapat memiliki fleksibilitas maksimum tentang cara mengelola dan menampilkan aplikasi pengguna. Misalnya, portal pengguna dapat menampilkan beberapa metadata proyek ML untuk memfasilitasi pengidentifikasian aplikasi yang akan diakses.

Anda dapat menemukan kode sumber solusi di . kami Repositori GitHub.

Ikhtisar solusi

Solusinya mengimplementasikan arsitektur berikut.

Komponen arsitektur tingkat tinggi utama adalah sebagai berikut:

1. Penyedia identitas – Pengguna dan grup dikelola di sumber identitas eksternal, misalnya di Azure AD. Penetapan pengguna ke grup AD menentukan izin apa yang dimiliki pengguna tertentu dan tim Studio mana yang mereka akses. Sumber identitas harus disinkronkan dengan AWS SSO.
2. SSO AWS – AWS SSO mengelola pengguna SSO, set izin SSO, dan aplikasi. Solusi ini menggunakan aplikasi SAML 2.0 kustom untuk menyediakan akses ke Studio bagi pengguna AWS SSO yang berhak. Solusi ini juga menggunakan pemetaan atribut SAML untuk mengisi pernyataan SAML dengan data yang relevan dengan akses tertentu, seperti ID pengguna dan tim pengguna. Karena solusinya membuat API SAML, Anda dapat menggunakan pernyataan SAML yang mendukung IdP untuk membuat arsitektur ini. Misalnya, Anda dapat menggunakan Okta atau bahkan aplikasi web Anda sendiri yang menyediakan halaman arahan dengan portal pengguna dan aplikasi. Untuk posting ini, kami menggunakan AWS SSO.
3. Aplikasi SAML 2.0 khusus – Solusinya membuat satu aplikasi per tim Studio dan menetapkan satu atau beberapa aplikasi ke pengguna atau grup pengguna berdasarkan hak. Pengguna dapat mengakses aplikasi ini dari dalam portal pengguna AWS SSO mereka berdasarkan izin yang ditetapkan. Setiap aplikasi dikonfigurasi dengan Gerbang API Amazon URL titik akhir sebagai backend SAML-nya.
4. Domain SageMaker – Solusi menyediakan domain SageMaker di akun AWS dan membuat profil pengguna khusus untuk setiap kombinasi pengguna AWS SSO dan tim Studio tempat pengguna ditetapkan. Domain harus dikonfigurasi di IAM Mode Autentikasi.
5. Profil pengguna studio – Solusinya secara otomatis membuat profil pengguna khusus untuk setiap kombinasi tim pengguna. Misalnya, jika pengguna adalah anggota dari dua tim Studio dan memiliki izin yang sesuai, solusi menyediakan dua profil pengguna terpisah untuk pengguna ini. Setiap profil selalu menjadi milik satu dan hanya satu pengguna. Karena Anda memiliki profil pengguna Studio untuk setiap kemungkinan kombinasi pengguna dan tim, Anda harus mempertimbangkan batas akun Anda untuk profil pengguna sebelum menerapkan pendekatan ini. Misalnya, jika batas Anda adalah 500 profil pengguna, dan setiap pengguna adalah anggota dari dua tim, Anda menggunakan batas itu 2.5 kali lebih cepat, dan sebagai hasilnya, Anda dapat mengikutsertakan 250 pengguna. Dengan jumlah pengguna yang tinggi, sebaiknya terapkan beberapa domain dan akun untuk pemisahan konteks keamanan. Untuk mendemonstrasikan bukti konsep, kami menggunakan dua pengguna, Pengguna 1 dan Pengguna 2, dan dua tim Studio, Tim 1 dan Tim 2. Pengguna 1 milik kedua tim, sedangkan Pengguna 2 hanya milik Tim 2. Pengguna 1 dapat mengakses lingkungan Studio untuk kedua tim, sedangkan Pengguna 2 hanya dapat mengakses lingkungan Studio untuk Tim 2.
6. Peran eksekusi studio – Setiap profil pengguna Studio menggunakan peran eksekusi khusus dengan kebijakan izin dengan tingkat akses yang diperlukan untuk tim tertentu tempat pengguna berada. Peran eksekusi studio menerapkan isolasi izin yang efektif antara pengguna individu dan peran tim mereka. Anda mengelola akses data dan sumber daya untuk setiap peran dan bukan pada tingkat pengguna individu.

Solusi ini juga mengimplementasikan kontrol akses berbasis atribut (ABAC) menggunakan atribut SAML 2.0, tag pada profil pengguna Studio, dan tag pada peran eksekusi SageMaker.

Dalam konfigurasi khusus ini, kami berasumsi bahwa pengguna AWS SSO tidak memiliki izin untuk masuk ke akun AWS dan tidak memiliki peran IAM yang dikontrol AWS SSO yang sesuai di akun. Setiap pengguna masuk ke lingkungan Studio mereka melalui URL yang telah ditentukan sebelumnya dari portal AWS SSO tanpa perlu membuka konsol di akun AWS mereka. Di lingkungan dunia nyata, Anda mungkin perlu menyiapkan Set izin AWS SSO bagi pengguna untuk mengizinkan pengguna yang berwenang mengambil peran IAM dan masuk ke akun AWS. Misalnya, Anda dapat memberikan izin peran ilmuwan data kepada pengguna agar dapat berinteraksi dengan sumber daya akun dan memiliki tingkat akses yang mereka butuhkan untuk memenuhi perannya.

Arsitektur solusi dan alur kerja

Diagram berikut menyajikan alur masuk menyeluruh untuk pengguna AWS SSO.

Pengguna AWS SSO memilih aplikasi Studio yang sesuai di portal AWS SSO mereka. AWS SSO menyiapkan pernyataan SAML (1) dengan pemetaan atribut SAML yang dikonfigurasi. Aplikasi SAML kustom dikonfigurasi dengan URL titik akhir API Gateway sebagai Assertion Consumer Service (ACS), dan memerlukan atribut pemetaan yang berisi ID pengguna dan ID tim AWS SSO. Kita gunakan ssouserid dan teamid atribut khusus untuk mengirim semua informasi yang diperlukan ke backend SAML.

API Gateway memanggil API backend SAML. Sebuah AWS Lambda function (2) mengimplementasikan API, mem-parsing respons SAML untuk mengekstrak ID pengguna dan ID tim. Fungsi menggunakannya untuk mengambil konfigurasi khusus tim, seperti peran eksekusi dan ID domain SageMaker. Fungsi tersebut memeriksa apakah profil pengguna yang diperlukan ada di domain, dan membuat yang baru dengan pengaturan konfigurasi yang sesuai jika tidak ada profil. Setelah itu, fungsi menghasilkan URL yang ditentukan Studio untuk profil pengguna Studio tertentu dengan memanggil BuatPresignedDomainUrl API (3) melalui titik akhir VPC API SageMaker. Fungsi Lambda akhirnya mengembalikan URL yang telah ditentukan sebelumnya dengan respons pengalihan HTTP 302 untuk memasukkan pengguna ke Studio.

Solusinya mengimplementasikan versi sampel non-produksi dari backend SAML. Fungsi Lambda mem-parsing pernyataan SAML dan hanya menggunakan atribut di <saml2:AttributeStatement> elemen untuk membangun a CreatePresignedDomainUrl panggilan API. Dalam solusi produksi, Anda harus menggunakan implementasi backend SAML yang tepat, yang harus menyertakan validasi respons SAML, tanda tangan, dan sertifikat, pencegahan pemutaran ulang dan pengalihan, dan fitur lain dari proses autentikasi SAML. Misalnya, Anda dapat menggunakan implementasi backend SAML python3-saml or Toolkit SAML sumber terbuka OneLogin untuk menerapkan backend SAML yang aman.

Pembuatan dinamis profil pengguna Studio

Solusinya secara otomatis membuat profil pengguna Studio untuk setiap kombinasi tim pengguna, segera setelah proses masuk AWS SSO meminta URL yang telah ditandatangani sebelumnya. Untuk bukti konsep dan kesederhanaan ini, solusinya membuat profil pengguna berdasarkan metadata yang dikonfigurasi di AWS template 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

Anda dapat mengonfigurasi tim sendiri, pengaturan khusus, dan tag dengan menambahkannya ke konfigurasi metadata untuk sumber daya AWS CloudFormation GetUserProfileMetadata.

Untuk informasi lebih lanjut tentang elemen konfigurasi dari UserSettings, mengacu pada buat_pengguna_profil di boto3.

Peran IAM

Diagram berikut menunjukkan peran IAM dalam solusi ini.

Peran-peran tersebut adalah sebagai berikut:

1. Peran eksekusi studio – Profil pengguna Studio menggunakan peran eksekusi Studio khusus dengan izin data dan sumber daya khusus untuk setiap tim atau grup pengguna. Peran ini juga dapat menggunakan tag untuk menerapkan ABAC untuk akses data dan sumber daya. Untuk informasi lebih lanjut, lihat Peran SageMaker.
2. Peran eksekusi Lambda backend SAML – Peran eksekusi ini berisi izin untuk memanggil CreatePresignedDomainUrl API. Anda dapat mengonfigurasi kebijakan izin untuk menyertakan pemeriksaan bersyarat tambahan menggunakan Condition kunci. Misalnya, untuk mengizinkan akses ke Studio hanya dari rentang alamat IP yang ditentukan dalam jaringan perusahaan pribadi Anda, gunakan kode berikut:

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

   Untuk contoh selengkapnya tentang cara menggunakan ketentuan dalam kebijakan IAM, lihat Kontrol Akses ke SageMaker API dengan Menggunakan Kebijakan Berbasis Identitas.

3. SageMaker – SageMaker mengasumsikan peran eksekusi Studio atas nama Anda, sebagaimana dikendalikan oleh kebijakan kepercayaan terkait pada peran eksekusi. Ini memungkinkan layanan untuk mengakses data dan sumber daya, dan melakukan tindakan atas nama Anda. Peran eksekusi Studio harus berisi kebijakan kepercayaan yang memungkinkan SageMaker mengambil peran ini.
4. Izin AWS SSO mengatur peran IAM – Anda dapat menetapkan pengguna AWS SSO Anda ke akun AWS di organisasi AWS Anda melalui Set izin AWS SSO. Kumpulan izin adalah template yang mendefinisikan kumpulan kebijakan IAM khusus peran pengguna. Anda mengelola kumpulan izin di AWS SSO, dan AWS SSO mengontrol peran IAM yang sesuai di setiap akun.
5. Kebijakan Kontrol Layanan Organisasi AWS - Jika Anda menggunakan Organisasi AWS, Anda dapat menerapkan Kebijakan Kontrol Layanan (SCP) untuk mengontrol secara terpusat izin maksimum yang tersedia untuk semua akun dan semua peran IAM di organisasi Anda. Misalnya, untuk mencegah akses ke Studio melalui konsol secara terpusat, Anda dapat menerapkan SCP berikut dan melampirkannya ke akun dengan domain SageMaker:

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

Peran yang disediakan solusi

Grafik Formasi AWS Cloud tumpukan untuk solusi ini membuat tiga peran eksekusi Studio yang digunakan di domain SageMaker:

• SageMakerStudioExecutionRoleDefault
• SageMakerStudioExecutionRoleTeam1
• SageMakerStudioExecutionRoleTeam2

Tidak ada peran yang memiliki AmazonSageMakerAkses Penuh kebijakan terlampir, dan masing-masing hanya memiliki satu set izin terbatas. Di lingkungan SageMaker dunia nyata, Anda perlu mengubah izin peran berdasarkan kebutuhan spesifik Anda.

SageMakerStudioExecutionRoleDefault hanya memiliki kebijakan kustom SageMakerReadOnlyPolicy dilampirkan dengan daftar pembatasan tindakan yang diizinkan.

Kedua peran tim, SageMakerStudioExecutionRoleTeam1 dan SageMakerStudioExecutionRoleTeam2, selain itu memiliki dua kebijakan bea cukai, SageMakerAccessSupportingServicesPolicy dan SageMakerStudioDeveloperAccessPolicy, memungkinkan penggunaan layanan tertentu dan satu kebijakan penolakan saja, SageMakerDeniedServicesPolicy, dengan penolakan eksplisit pada beberapa panggilan API SageMaker.

Kebijakan akses pengembang Studio memberlakukan pengaturan dari Team tag yang sama dengan nilai yang sama dengan peran eksekusi pengguna sendiri untuk memanggil SageMaker apa pun Create* Lebah:

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

Selain itu, memungkinkan penggunaan hapus, hentikan, perbarui, dan mulai operasi hanya pada sumber daya yang diberi tag dengan tag Tim yang sama dengan peran eksekusi pengguna:

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

Untuk informasi lebih lanjut tentang peran dan kebijakan, lihat Mengonfigurasi Amazon SageMaker Studio untuk tim dan grup dengan isolasi sumber daya lengkap.

Infrastruktur jaringan

Solusinya menerapkan lingkungan domain SageMaker yang sepenuhnya terisolasi dengan semua lalu lintas jaringan yang melalui Tautan Pribadi AWS koneksi. Anda dapat secara opsional mengaktifkan akses internet dari notebook Studio. Solusinya juga menciptakan tiga Grup keamanan VPC untuk mengontrol lalu lintas antara semua komponen solusi seperti fungsi Lambda backend SAML, titik akhir VPC, dan buku catatan Studio.

Untuk bukti konsep dan kesederhanaan ini, solusinya membuat subnet SageMaker dalam satu Zona Ketersediaan. Untuk penyiapan produksi, Anda harus menggunakan beberapa subnet pribadi di beberapa Availability Zone dan memastikan bahwa setiap subnet berukuran tepat, dengan asumsi minimum lima IP per pengguna.

Solusi ini menyediakan semua infrastruktur jaringan yang diperlukan. Template CloudFormation ./cfn-templates/vpc.yaml berisi kode sumber.

Langkah-langkah penerapan

Untuk menerapkan dan menguji solusi, Anda harus menyelesaikan langkah-langkah berikut:

1. Terapkan tumpukan solusi melalui an Model Aplikasi Tanpa Server AWS (AWS SAM).
2. Buat pengguna AWS SSO, atau gunakan pengguna AWS SSO yang ada.
3. Buat aplikasi SAML 2.0 kustom dan tetapkan pengguna AWS SSO ke aplikasi.

Kode sumber lengkap untuk solusi disediakan di GitHub kami gudang.

Prasyarat

Untuk menggunakan solusi ini, Antarmuka Baris Perintah AWS (AWS CLI), CLI AWS SAM, dan Python3.8 atau lebih baru harus dipasang.

Prosedur penerapan mengasumsikan bahwa Anda mengaktifkan AWS SSO dan mengonfigurasi untuk Organisasi AWS di akun tempat solusi diterapkan.

Untuk menyiapkan AWS SSO, lihat instruksi di GitHub.

Opsi penerapan solusi

Anda dapat memilih dari beberapa opsi penerapan solusi agar paling sesuai dengan lingkungan AWS Anda yang ada. Anda juga dapat memilih jaringan dan opsi penyediaan domain SageMaker. Untuk informasi mendetail tentang pilihan penerapan yang berbeda, lihat: File README.

Terapkan template AWS SAM

Untuk menerapkan template AWS SAM, selesaikan langkah-langkah berikut:

1. Mengkloning kode sumber gudang ke lingkungan lokal Anda:

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

2. Bangun aplikasi AWS SAM:
3. Terapkan aplikasi:

   sam deploy --guided

4. Berikan parameter tumpukan sesuai dengan lingkungan Anda yang ada dan opsi penerapan yang diinginkan, seperti VPC yang ada, subnet pribadi dan publik yang ada, dan domain SageMaker yang ada, seperti yang dibahas di bagian Opsi penerapan solusi bab dari file README.

Anda dapat membiarkan semua parameter pada nilai defaultnya untuk menyediakan sumber daya jaringan baru dan domain SageMaker baru. Lihat penggunaan parameter terperinci di README file jika Anda perlu mengubah pengaturan default.

Tunggu hingga penyebaran tumpukan selesai. Penyebaran ujung ke ujung termasuk penyediaan semua sumber daya jaringan dan domain SageMaker membutuhkan waktu sekitar 20 menit.

Untuk melihat keluaran tumpukan, jalankan perintah berikut di terminal:

export STACK_NAME=<SAM stack name>

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

Buat pengguna SSO

Ikuti petunjuk untuk tambahkan pengguna AWS SSO untuk membuat dua pengguna dengan nama User1 dan User2 atau menggunakan dua pengguna AWS SSO yang ada untuk menguji solusinya. Pastikan Anda menggunakan AWS SSO di Wilayah AWS yang sama tempat Anda menerapkan solusi.

Buat aplikasi SAML 2.0 khusus

Untuk membuat aplikasi SAML 2.0 kustom yang diperlukan untuk Tim 1 dan Tim 2, selesaikan langkah-langkah berikut:

1. Buka konsol AWS SSO di akun manajemen AWS organisasi AWS Anda, di Wilayah yang sama tempat Anda menerapkan tumpukan solusi.
2. Pilih Aplikasi di panel navigasi.
3. Pilih Tambahkan aplikasi baru.
4. Pilih Tambahkan aplikasi SAML 2.0 khusus.
5. Untuk Nama tampilan, masukkan nama aplikasi, misalnya SageMaker Studio Team 1.
6. Meninggalkan URL mulai aplikasi dan Keadaan relai kosong.
7. Pilih Jika Anda tidak memiliki file metadata, Anda dapat memasukkan nilai metadata secara manual.
8. Untuk URL ACS Aplikasi, masukkan URL yang disediakan di SAMLBackendEndpoint kunci keluaran tumpukan AWS SAM.
9. Untuk Audiens SAML aplikasi, masukkan URL yang disediakan di SAMLAudience kunci keluaran tumpukan AWS SAM.
10. Pilih Simpan perubahan.
    
11. Arahkan ke folder Pemetaan atribut Tab.
12. Mengatur Subjek untuk e-mail dan dibentuk untuk alamat email.
13. Tambahkan atribut baru berikut:
    1. ssouserid mulai ${user:AD_GUID}
    2. teamid mulai Team1 or Team2, masing-masing, untuk setiap aplikasi
       
14. Pilih Simpan perubahan.
15. pada Pengguna yang ditetapkan tab, pilih Tetapkan pengguna.
16. Pilih Pengguna 1 untuk aplikasi Tim 1 dan Pengguna 1 dan Pengguna 2 untuk aplikasi Tim 2.
17. Pilih Tetapkan pengguna.
    

Uji solusinya

Untuk menguji solusi, selesaikan langkah-langkah berikut:

1. Buka portal pengguna AWS SSO https://<Identity Store ID>.awsapps.com/start dan tanda tangani sebagai Pengguna 1.
   Dua aplikasi SageMaker ditampilkan di portal.
   
2. Pilih Tim Studio SageMaker 1.
   Anda dialihkan ke instance Studio untuk Tim 1 di jendela browser baru.
   Pertama kali Anda memulai Studio, SageMaker membuat aplikasi JupyterServer. Proses ini memakan waktu beberapa menit.
   
3. Di Studio, di File menu, pilih New dan terminal untuk memulai terminal baru.
4. Di baris perintah terminal, masukkan perintah berikut:

   aws sts get-caller-identity

   Perintah mengembalikan peran eksekusi Studio.
   

   Dalam pengaturan kami, peran ini harus berbeda untuk setiap tim. Anda juga dapat memeriksa apakah setiap pengguna di setiap instans Studio memiliki direktori beranda mereka sendiri pada volume Amazon EFS yang terpasang.

5. Kembali ke portal AWS SSO, masih login sebagai Pengguna 1, dan pilih Tim Studio SageMaker 2.
   Anda dialihkan ke instance Team 2 Studio.
   Proses mulai lagi dapat memakan waktu beberapa menit, karena SageMaker memulai aplikasi JupyterServer baru untuk Pengguna 2.
6. Masuk sebagai Pengguna 2 di portal AWS SSO.
   Pengguna 2 hanya memiliki satu aplikasi yang ditetapkan: SageMaker Studio Team 2.
   

Jika Anda memulai instance Studio melalui aplikasi pengguna ini, Anda dapat memverifikasi bahwa ia menggunakan peran eksekusi SageMaker yang sama dengan instance Tim 1 Pengguna 2. Namun, setiap instance Studio benar-benar terisolasi. Pengguna 2 memiliki direktori home mereka sendiri pada volume Amazon EFS dan instance aplikasi JupyterServer sendiri. Anda dapat memverifikasi ini dengan membuat folder dan beberapa file untuk setiap pengguna dan melihat bahwa direktori home setiap pengguna diisolasi.

Sekarang Anda dapat masuk ke konsol SageMaker dan melihat bahwa ada tiga profil pengguna yang dibuat.

Anda baru saja menerapkan solusi bukti konsep untuk mengelola banyak pengguna dan tim dengan Studio.

Membersihkan

Untuk menghindari biaya, Anda harus menghapus semua sumber daya yang disediakan dan dihasilkan proyek dari akun AWS Anda. Gunakan perintah SAM CLI berikut untuk menghapus tumpukan solusi CloudFormation:

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

Untuk alasan keamanan dan untuk mencegah kehilangan data, pemasangan Amazon EFS dan konten yang terkait dengan domain Studio yang diterapkan dalam solusi ini tidak dihapus. VPC dan subnet yang terkait dengan domain SageMaker tetap berada di akun AWS Anda. Untuk instruksi menghapus sistem file dan VPC, lihat Menghapus sistem file Amazon EFS dan Bekerja dengan VPC, Masing-masing.

Untuk menghapus aplikasi SAML kustom, selesaikan langkah-langkah berikut:

1. Buka konsol AWS SSO di akun manajemen AWS SSO.
2. Pilih Aplikasi.
3. Pilih Tim Studio SageMaker 1.
4. pada tindakan menu, pilih Remove.
5. Ulangi langkah ini untuk Tim Studio SageMaker 2.

Kesimpulan

Solusi ini menunjukkan bagaimana Anda dapat membuat lingkungan yang fleksibel dan dapat disesuaikan menggunakan profil pengguna AWS SSO dan Studio untuk mendukung struktur organisasi Anda sendiri. Kemungkinan langkah perbaikan berikutnya menuju solusi siap produksi adalah:

• Menerapkan manajemen profil pengguna Studio otomatis sebagai layanan mikro khusus untuk mendukung alur kerja penyediaan profil otomatis dan untuk menangani metadata dan konfigurasi untuk profil pengguna, misalnya di Amazon DynamoDB.
• Gunakan mekanisme yang sama dalam kasus yang lebih umum dari beberapa domain SageMaker dan beberapa akun AWS. Backend SAML yang sama dapat menjual URL pratanda terkait yang mengalihkan ke kombinasi profil-domain-akun pengguna sesuai dengan logika kustom Anda berdasarkan hak pengguna dan penyiapan tim.
• Terapkan mekanisme sinkronisasi antara IdP dan AWS SSO Anda dan otomatisasi pembuatan aplikasi SAML 2.0 kustom.
• Terapkan manajemen akses sumber daya dan data yang dapat diskalakan dengan kontrol akses berbasis atribut (ABAC).

Jika Anda memiliki umpan balik atau pertanyaan, silakan tinggalkan di komentar.

Bacaan lebih lanjut

Dokumentasi

Postingan Blog

tentang Penulis

Evgeniy Ilyin adalah Arsitek Solusi di AWS. Dia memiliki lebih dari 20 tahun pengalaman bekerja di semua tingkat pengembangan perangkat lunak dan arsitektur solusi dan telah menggunakan bahasa pemrograman dari COBOL dan Assembler hingga .NET, Java, dan Python. Dia mengembangkan dan mengkodekan solusi cloud native dengan fokus pada big data, analytics, dan data engineering.