การจัดการทีมและผู้ใช้ด้วย Amazon SageMaker และ AWS SSO

สตูดิโอ Amazon SageMaker เป็นสภาพแวดล้อมการพัฒนาแบบรวมบนเว็บ (IDE) สำหรับการเรียนรู้ของเครื่อง (ML) ที่ช่วยให้คุณสร้าง ฝึก แก้จุดบกพร่อง ปรับใช้ และตรวจสอบโมเดล ML ของคุณ ผู้ใช้ที่เข้าร่วมแต่ละคนใน Studio มีชุดทรัพยากรเฉพาะของตนเอง เช่น อินสแตนซ์การประมวลผล โฮมไดเร็กทอรีบน an ระบบไฟล์ Amazon Elastic (Amazon EFS) และเฉพาะ AWS Identity และการจัดการการเข้าถึง (IAM) บทบาทการดำเนินการ

หนึ่งในความท้าทายในชีวิตจริงที่พบบ่อยที่สุดในการตั้งค่าการเข้าถึงของผู้ใช้สำหรับ Studio คือวิธีจัดการผู้ใช้ กลุ่ม และทีมวิทยาศาสตร์ข้อมูลหลายคนสำหรับการเข้าถึงข้อมูลและการแยกทรัพยากร

ลูกค้าจำนวนมากใช้การจัดการผู้ใช้โดยใช้ข้อมูลประจำตัวที่ติดต่อกับภายนอกด้วย การลงชื่อเพียงครั้งเดียวของ AWS (AWS SSO) และผู้ให้บริการข้อมูลประจำตัวภายนอก (IdP) เช่น Active Directory (AD) หรือไดเรกทอรี AWS Managed Microsoft AD สอดคล้องกับ AWS แนวปฏิบัติที่แนะนำ ของการใช้ข้อมูลประจำตัวชั่วคราวในการเข้าถึงบัญชี AWS

An อเมซอน SageMaker โดเมน รองรับ AWS SSO และสามารถกำหนดค่าได้ใน AWS SSO โหมดการรับรองความถูกต้อง ในกรณีนี้ ผู้ใช้ AWS SSO ที่มีสิทธิ์แต่ละคนจะมี โปรไฟล์ผู้ใช้สตูดิโอ. ผู้ใช้ที่ได้รับสิทธิ์เข้าถึง Studio จะมี URL การลงชื่อเข้าใช้ที่ไม่ซ้ำกันซึ่งเปิด Studio โดยตรง และลงชื่อเข้าใช้ด้วยข้อมูลประจำตัว AWS SSO องค์กรจัดการผู้ใช้ใน AWS SSO แทนโดเมน SageMaker คุณสามารถกำหนดให้ผู้ใช้หลายคนเข้าถึงโดเมนได้พร้อมกัน คุณสามารถใช้โปรไฟล์ผู้ใช้ Studio สำหรับผู้ใช้แต่ละรายเพื่อกำหนดสิทธิ์ด้านความปลอดภัยในสมุดบันทึก Studio ผ่านบทบาท IAM ที่แนบกับโปรไฟล์ผู้ใช้ที่เรียกว่า บทบาทการดำเนินการ. บทบาทนี้ควบคุมการอนุญาตสำหรับการดำเนินการ SageMaker ตามนโยบายการอนุญาต IAM

ในโหมดการตรวจสอบสิทธิ์ AWS SSO จะมีการแมปแบบหนึ่งต่อหนึ่งระหว่างผู้ใช้และโปรไฟล์ผู้ใช้เสมอ โดเมน SageMaker จัดการการสร้างโปรไฟล์ผู้ใช้ตาม ID ผู้ใช้ AWS SSO คุณไม่สามารถสร้างโปรไฟล์ผู้ใช้ผ่านทาง คอนโซลการจัดการ AWS. วิธีนี้ใช้ได้ผลดีในกรณีที่ผู้ใช้รายหนึ่งเป็นสมาชิกของทีมวิทยาศาสตร์ข้อมูลเพียงทีมเดียว หรือหากผู้ใช้มีข้อกำหนดในการเข้าถึงเหมือนกันหรือคล้ายกันมากในโครงการและทีมของตน ในกรณีการใช้งานทั่วไป เมื่อผู้ใช้สามารถมีส่วนร่วมในโครงการ ML หลายโครงการและเป็นสมาชิกของหลายทีมที่มีข้อกำหนดการอนุญาตที่แตกต่างกันเล็กน้อย ผู้ใช้จำเป็นต้องเข้าถึงโปรไฟล์ผู้ใช้ Studio ที่แตกต่างกันโดยมีบทบาทการดำเนินการและนโยบายการอนุญาตที่แตกต่างกัน เนื่องจากคุณไม่สามารถจัดการโปรไฟล์ผู้ใช้อย่างอิสระจาก AWS SSO ในโหมดการตรวจสอบสิทธิ์ AWS SSO คุณจึงใช้การแมปแบบหนึ่งต่อหลายระหว่างผู้ใช้และโปรไฟล์ผู้ใช้ Studio ไม่ได้

หากคุณต้องการแยกบริบทการรักษาความปลอดภัยอย่างเข้มงวด เช่น สำหรับหมวดหมู่ข้อมูลที่แตกต่างกัน หรือจำเป็นต้องป้องกันไม่ให้มีการเปิดเผยกิจกรรมและทรัพยากรของผู้ใช้กลุ่มหนึ่งไปยังอีกกลุ่มหนึ่งโดยสิ้นเชิง แนวทางที่แนะนำคือการสร้างโดเมน SageMaker หลายโดเมน ในขณะที่เขียนบทความนี้ คุณสามารถสร้างได้เพียงโดเมนเดียวเท่านั้นต่อบัญชี AWS ต่อภูมิภาค คุณสามารถใช้บัญชี AWS หลายบัญชีกับหนึ่งโดเมนต่อบัญชีเพื่อแก้ไขปัญหาชั่วคราวได้

ความท้าทายที่สองคือการ จำกัดการเข้าถึง Studio IDE เฉพาะผู้ใช้จากภายในเครือข่ายองค์กรหรือ VPC ที่กำหนด คุณสามารถทำสิ่งนี้ได้โดยใช้ นโยบายการควบคุมการเข้าถึงตาม IAM. ในกรณีนี้ ต้องกำหนดค่าโดเมน SageMaker ด้วย โหมดการตรวจสอบสิทธิ์ IAMเนื่องจากกลไกการลงชื่อเข้าใช้ในโหมด AWS SSO ไม่รองรับนโยบายตามข้อมูลระบุตัวตนของ IAM โพสต์ เข้าถึง Amazon SageMaker Studio ได้อย่างปลอดภัยด้วย AWS SSO และแอปพลิเคชัน SAML แก้ปัญหานี้และสาธิตวิธีควบคุมการเข้าถึงเครือข่ายไปยังโดเมน SageMaker

โซลูชันนี้จัดการกับความท้าทายเหล่านี้ของการจัดการผู้ใช้ AWS SSO สำหรับ Studio สำหรับกรณีการใช้งานทั่วไปของกลุ่มผู้ใช้หลายกลุ่มและการแมปแบบกลุ่มต่อกลุ่มระหว่างผู้ใช้และทีม โซลูชันจะสรุปวิธีใช้ a แอปพลิเคชัน SAML 2.0 แบบกำหนดเอง เป็นกลไกในการทริกเกอร์การตรวจสอบสิทธิ์ผู้ใช้สำหรับ Studio และรองรับโปรไฟล์ผู้ใช้ Studio หลายโปรไฟล์ต่อผู้ใช้ AWS SSO หนึ่งราย

คุณสามารถใช้วิธีนี้เพื่อปรับใช้พอร์ทัลผู้ใช้แบบกำหนดเองกับแอปพลิเคชันที่ได้รับการสนับสนุนโดยกระบวนการให้สิทธิ์ SAML 2.0 พอร์ทัลผู้ใช้ที่กำหนดเองของคุณสามารถมีความยืดหยุ่นสูงสุดในการจัดการและแสดงแอปพลิเคชันของผู้ใช้ ตัวอย่างเช่น พอร์ทัลผู้ใช้สามารถแสดงข้อมูลเมตาของโปรเจ็กต์ ML เพื่ออำนวยความสะดวกในการระบุแอปพลิเคชันที่จะเข้าถึง

คุณสามารถค้นหาซอร์สโค้ดของโซลูชันได้ใน พื้นที่เก็บข้อมูล GitHub.

ภาพรวมโซลูชัน

โซลูชันนี้ใช้สถาปัตยกรรมต่อไปนี้

ส่วนประกอบสถาปัตยกรรมระดับสูงที่สำคัญมีดังนี้:

1. ผู้ให้บริการข้อมูลประจำตัว – ผู้ใช้และกลุ่มได้รับการจัดการในแหล่งข้อมูลประจำตัวภายนอก เช่น ใน Azure AD การกำหนดผู้ใช้ให้กับกลุ่ม AD จะกำหนดสิทธิ์ที่ผู้ใช้แต่ละคนมี และทีม Studio ที่พวกเขามีสิทธิ์เข้าถึง แหล่งที่มาของข้อมูลประจำตัวต้องซิงโครไนซ์กับ AWS SSO
2. AWS SSO – AWS SSO จัดการผู้ใช้ SSO ชุดสิทธิ์ SSO และแอปพลิเคชัน โซลูชันนี้ใช้แอปพลิเคชัน SAML 2.0 ที่กำหนดเองเพื่อให้สิทธิ์เข้าถึง Studio สำหรับผู้ใช้ AWS SSO ที่มีสิทธิ์ โซลูชันยังใช้การแมปแอตทริบิวต์ SAML เพื่อเติมการยืนยัน SAML ด้วยข้อมูลเฉพาะที่เกี่ยวข้องกับการเข้าถึง เช่น ID ผู้ใช้และทีมผู้ใช้ เนื่องจากโซลูชันสร้าง SAML API คุณสามารถใช้ IdP ใดๆ ที่สนับสนุนการยืนยัน SAML เพื่อสร้างสถาปัตยกรรมนี้ได้ ตัวอย่างเช่น คุณสามารถใช้ Okta หรือแม้แต่เว็บแอปพลิเคชันของคุณเองซึ่งมีหน้า Landing Page ที่มีพอร์ทัลผู้ใช้และแอปพลิเคชัน สำหรับโพสต์นี้ เราใช้ AWS SSO
3. แอปพลิเคชัน SAML 2.0 แบบกำหนดเอง – โซลูชันสร้างหนึ่งแอปพลิเคชันต่อทีม Studio และกำหนดหนึ่งหรือหลายแอปพลิเคชันให้กับผู้ใช้หรือกลุ่มผู้ใช้ตามการให้สิทธิ์ ผู้ใช้สามารถเข้าถึงแอปพลิเคชันเหล่านี้ได้จากภายในพอร์ทัลผู้ใช้ AWS SSO ตามสิทธิ์ที่ได้รับมอบหมาย แต่ละแอปพลิเคชันได้รับการกำหนดค่าด้วย Amazon API Gateway Amazon URL ปลายทางเป็นแบ็กเอนด์ SAML
4. โดเมน SageMaker – โซลูชันจัดเตรียมโดเมน SageMaker ในบัญชี AWS และสร้างโปรไฟล์ผู้ใช้เฉพาะสำหรับแต่ละชุดของผู้ใช้ AWS SSO และทีม Studio ที่ผู้ใช้ได้รับมอบหมาย ต้องกำหนดค่าโดเมนใน IAM โหมดการรับรองความถูกต้อง
5. โปรไฟล์ผู้ใช้สตูดิโอ – โซลูชันจะสร้างโปรไฟล์ผู้ใช้เฉพาะสำหรับชุดผู้ใช้และทีมแต่ละชุดโดยอัตโนมัติ ตัวอย่างเช่น หากผู้ใช้เป็นสมาชิกของทีม Studio สองทีมและมีสิทธิ์ที่เกี่ยวข้อง โซลูชันจะจัดเตรียมโปรไฟล์ผู้ใช้แยกกันสองโปรไฟล์สำหรับผู้ใช้รายนี้ แต่ละโปรไฟล์เป็นของผู้ใช้งานเพียงคนเดียวเสมอ เนื่องจากคุณมีโปรไฟล์ผู้ใช้ Studio สำหรับชุดค่าผสมที่เป็นไปได้ของผู้ใช้และทีม คุณต้องพิจารณาขีดจำกัดบัญชีของคุณสำหรับโปรไฟล์ผู้ใช้ก่อนที่จะใช้แนวทางนี้ ตัวอย่างเช่น หากขีดจำกัดของคุณคือ 500 โปรไฟล์ผู้ใช้ และผู้ใช้แต่ละรายเป็นสมาชิกของสองทีม คุณจะใช้ขีดจำกัดนั้นเร็วขึ้น 2.5 เท่า และด้วยเหตุนี้ คุณจึงสามารถเริ่มต้นใช้งานผู้ใช้ได้ 250 ราย ด้วยผู้ใช้จำนวนมาก เราขอแนะนำให้ใช้หลายโดเมนและบัญชีเพื่อแยกบริบทการรักษาความปลอดภัย เพื่อแสดงการพิสูจน์แนวคิด เราใช้ผู้ใช้สองคน ผู้ใช้ 1 และผู้ใช้ 2 และทีม Studio สองทีม ทีม 1 และทีม 2 ผู้ใช้ 1 เป็นของทั้งสองทีม ในขณะที่ผู้ใช้ 2 อยู่ในทีม 2 เท่านั้น ผู้ใช้ 1 สามารถเข้าถึงสภาพแวดล้อม Studio สำหรับทั้งสองทีม ในขณะที่ผู้ใช้ 2 สามารถเข้าถึงเฉพาะสภาพแวดล้อม Studio สำหรับทีม 2
6. บทบาทการดำเนินการในสตูดิโอ – โปรไฟล์ผู้ใช้ Studio แต่ละโปรไฟล์ใช้บทบาทการดำเนินการเฉพาะพร้อมนโยบายการอนุญาตที่มีระดับการเข้าถึงที่จำเป็นสำหรับทีมเฉพาะที่ผู้ใช้เป็นสมาชิก บทบาทการดำเนินการของ Studio ใช้การแยกสิทธิ์ที่มีประสิทธิภาพระหว่างผู้ใช้แต่ละรายและบทบาทของทีม คุณจัดการข้อมูลและการเข้าถึงทรัพยากรสำหรับแต่ละบทบาท ไม่ใช่ในระดับผู้ใช้แต่ละราย

โซลูชันยังใช้การควบคุมการเข้าถึงตามแอตทริบิวต์ (ABAC) โดยใช้แอตทริบิวต์ SAML 2.0 แท็กในโปรไฟล์ผู้ใช้ Studio และแท็กบนบทบาทการดำเนินการของ SageMaker

ในการกำหนดค่าเฉพาะนี้ เราถือว่าผู้ใช้ AWS SSO ไม่มีสิทธิ์ลงชื่อเข้าใช้บัญชี AWS และไม่มีบทบาท IAM ที่ควบคุมโดย AWS SSO ในบัญชี ผู้ใช้แต่ละรายลงชื่อเข้าใช้สภาพแวดล้อม Studio ของตนผ่าน URL ที่กำหนดไว้ล่วงหน้าจากพอร์ทัล AWS SSO โดยไม่ต้องไปที่คอนโซลในบัญชี AWS ในสภาพแวดล้อมจริง คุณอาจต้องตั้งค่า ชุดการอนุญาต AWS SSO สำหรับผู้ใช้เพื่อให้ผู้ใช้ที่ได้รับอนุญาตรับบทบาท IAM และลงชื่อเข้าใช้บัญชี AWS ตัวอย่างเช่น คุณสามารถให้สิทธิ์ในบทบาทของนักวิทยาศาสตร์ข้อมูลเพื่อให้ผู้ใช้สามารถโต้ตอบกับทรัพยากรของบัญชีและมีระดับการเข้าถึงที่จำเป็นสำหรับการปฏิบัติตามบทบาทของตน

สถาปัตยกรรมโซลูชันและเวิร์กโฟลว์

ไดอะแกรมต่อไปนี้แสดงขั้นตอนการลงชื่อเข้าใช้แบบ end-to-end สำหรับผู้ใช้ AWS SSO

ผู้ใช้ AWS SSO เลือกแอปพลิเคชัน Studio ที่เกี่ยวข้องในพอร์ทัล AWS SSO AWS SSO เตรียมการยืนยัน SAML (1) พร้อมการแมปแอตทริบิวต์ SAML ที่กำหนดค่าไว้ แอปพลิเคชัน SAML ที่กำหนดเองได้รับการกำหนดค่าด้วย URL ปลายทางของเกตเวย์ API เป็น Assertion Consumer Service (ACS) และต้องมีแอตทริบิวต์การแมปที่มี ID ผู้ใช้ AWS SSO และรหัสทีม เราใช้ ssouserid และ teamid แอตทริบิวต์ที่กำหนดเองเพื่อส่งข้อมูลที่จำเป็นทั้งหมดไปยังแบ็กเอนด์ SAML

API Gateway เรียกใช้ SAML แบ็กเอนด์ API หนึ่ง AWS แลมบ์ดา ฟังก์ชัน (2) ใช้ API แยกวิเคราะห์การตอบสนอง SAML เพื่อแยก ID ผู้ใช้และรหัสทีม ฟังก์ชันนี้ใช้เพื่อเรียกการกำหนดค่าเฉพาะทีม เช่น บทบาทการดำเนินการและ ID โดเมน SageMaker ฟังก์ชันจะตรวจสอบว่ามีโปรไฟล์ผู้ใช้ที่จำเป็นอยู่ในโดเมนหรือไม่ และสร้างโปรไฟล์ใหม่ด้วยการตั้งค่าการกำหนดค่าที่สอดคล้องกันหากไม่มีโปรไฟล์อยู่ หลังจากนั้น ฟังก์ชันจะสร้าง URL ที่กำหนดไว้ล่วงหน้าของ Studio สำหรับโปรไฟล์ผู้ใช้ Studio เฉพาะโดยการเรียก สร้าง PresignedDomainUrl API (3) ผ่านจุดปลาย SageMaker API VPC ในที่สุด ฟังก์ชัน Lambda จะส่งคืน URL ที่กำหนดไว้ล่วงหน้าพร้อมการตอบสนองการเปลี่ยนเส้นทาง HTTP 302 เพื่อลงชื่อเข้าใช้ Studio ให้ผู้ใช้

โซลูชันนี้ใช้แบ็กเอนด์ SAML เวอร์ชันตัวอย่างที่ไม่ได้ใช้งานจริง ฟังก์ชันแลมบ์ดาแยกวิเคราะห์การยืนยัน SAML และใช้เฉพาะแอตทริบิวต์ใน <saml2:AttributeStatement> องค์ประกอบในการสร้าง a CreatePresignedDomainUrl การเรียก API ในโซลูชันที่ใช้งานจริงของคุณ คุณต้องใช้การใช้งานแบ็กเอนด์ SAML ที่เหมาะสม ซึ่งต้องมีการตรวจสอบการตอบกลับ SAML ลายเซ็นและใบรับรอง การป้องกันการเล่นซ้ำและการเปลี่ยนเส้นทาง และคุณลักษณะอื่นๆ ของกระบวนการตรวจสอบสิทธิ์ SAML ตัวอย่างเช่น คุณสามารถใช้ a python3-saml การใช้งานแบ็กเอนด์ SAML or OneLogin ชุดเครื่องมือ SAML โอเพ่นซอร์ส เพื่อใช้แบ็กเอนด์ SAML ที่ปลอดภัย

การสร้างโปรไฟล์ผู้ใช้ Studio แบบไดนามิก

โซลูชันจะสร้างโปรไฟล์ผู้ใช้ Studio โดยอัตโนมัติสำหรับชุดผู้ใช้และทีมแต่ละชุด ทันทีที่กระบวนการลงชื่อเข้าใช้ AWS SSO ขอ URL ที่กำหนดไว้ล่วงหน้า สำหรับการพิสูจน์แนวคิดและความเรียบง่ายนี้ โซลูชันจะสร้างโปรไฟล์ผู้ใช้ตามข้อมูลเมตาที่กำหนดค่าไว้ใน AWS เทมเพลต 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

คุณสามารถกำหนดค่าทีมของตัวเอง การตั้งค่าแบบกำหนดเอง และแท็กโดยเพิ่มไปยังการกำหนดค่าข้อมูลเมตาสำหรับทรัพยากร AWS CloudFormation GetUserProfileMetadata.

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับองค์ประกอบการกำหนดค่าของ UserSettings, เอ่ยถึง create_user_profile ใน boto3.

บทบาท IAM

ไดอะแกรมต่อไปนี้แสดงบทบาท IAM ในโซลูชันนี้

บทบาทมีดังนี้:

1. บทบาทการดำเนินการในสตูดิโอ – โปรไฟล์ผู้ใช้ Studio ใช้บทบาทการดำเนินการของ Studio โดยเฉพาะพร้อมสิทธิ์ข้อมูลและทรัพยากรเฉพาะสำหรับแต่ละทีมหรือกลุ่มผู้ใช้ บทบาทนี้ยังสามารถใช้แท็กเพื่อปรับใช้ ABAC สำหรับการเข้าถึงข้อมูลและทรัพยากร สำหรับข้อมูลเพิ่มเติม โปรดดูที่ บทบาทของ SageMaker.
2. บทบาทการดำเนินการแบ็กเอนด์ของแลมบ์ดา SAML – บทบาทการดำเนินการนี้ได้รับอนุญาตให้เรียก CreatePresignedDomainUrl เอพีไอ คุณสามารถกำหนดค่านโยบายการอนุญาตเพื่อรวมการตรวจสอบตามเงื่อนไขเพิ่มเติมโดยใช้ Condition กุญแจ ตัวอย่างเช่น หากต้องการอนุญาตการเข้าถึง Studio จากช่วงที่อยู่ IP ที่กำหนดภายในเครือข่ายองค์กรส่วนตัวของคุณเท่านั้น ให้ใช้รหัสต่อไปนี้:

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

   สำหรับตัวอย่างเพิ่มเติมเกี่ยวกับวิธีใช้เงื่อนไขในนโยบาย IAM โปรดดูที่ ควบคุมการเข้าถึง SageMaker API โดยใช้นโยบายตามข้อมูลประจำตัว

3. SageMaker – SageMaker รับบทบาทการดำเนินการของ Studio ในนามของคุณ ตามที่ควบคุมโดยนโยบายความเชื่อถือที่เกี่ยวข้องในบทบาทการดำเนินการ ซึ่งช่วยให้บริการเข้าถึงข้อมูลและทรัพยากร และดำเนินการในนามของคุณ บทบาทการดำเนินการของ Studio ต้องมีนโยบายความเชื่อถือที่อนุญาตให้ SageMaker รับบทบาทนี้
4. การอนุญาต AWS SSO กำหนดบทบาท IAM – คุณสามารถกำหนดผู้ใช้ AWS SSO ของคุณให้กับบัญชี AWS ในองค์กร AWS ของคุณได้ผ่าน ชุดการอนุญาต AWS SSO. ชุดสิทธิ์คือเทมเพลตที่กำหนดชุดนโยบาย IAM เฉพาะบทบาทของผู้ใช้ คุณจัดการชุดสิทธิ์ใน AWS SSO และ AWS SSO จะควบคุมบทบาท IAM ที่เกี่ยวข้องในแต่ละบัญชี
5. นโยบายการควบคุมบริการสำหรับองค์กรของ AWS – ถ้าคุณใช้ องค์กร AWS คุณสามารถนำไปใช้ นโยบายควบคุมการบริการ (SCP) เพื่อควบคุมการอนุญาตสูงสุดที่มีอยู่จากส่วนกลางสำหรับทุกบัญชีและบทบาท IAM ทั้งหมดในองค์กรของคุณ ตัวอย่างเช่น เพื่อป้องกันการเข้าถึง Studio จากส่วนกลางผ่านคอนโซล คุณสามารถใช้ SCP ต่อไปนี้และแนบไปกับบัญชีที่มีโดเมน SageMaker:

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

โซลูชันที่จัดเตรียมบทบาท

พื้นที่ การก่อตัวของ AWS Cloud กอง สำหรับโซลูชันนี้จะสร้างบทบาทการดำเนินการของ Studio สามบทบาทที่ใช้ในโดเมน SageMaker:

• SageMakerStudioExecutionRoleDefault
• SageMakerStudioExecutionRoleTeam1
• SageMakerStudioExecutionRoleTeam2

ไม่มีบทบาทใดที่มี AmazonSageMakerFullAccess แนบนโยบายและแต่ละชุดมีสิทธิ์จำกัดเท่านั้น ในสภาพแวดล้อมจริงของ SageMaker คุณต้องแก้ไขการอนุญาตของบทบาทตามความต้องการเฉพาะของคุณ

SageMakerStudioExecutionRoleDefault มีเพียงนโยบายที่กำหนดเอง SageMakerReadOnlyPolicy แนบมากับรายการการกระทำที่จำกัด

ทั้งบทบาททีม SageMakerStudioExecutionRoleTeam1 และ SageMakerStudioExecutionRoleTeam2, นอกจากนี้ยังมีสองนโยบายที่กำหนดเอง, SageMakerAccessSupportingServicesPolicy และ SageMakerStudioDeveloperAccessPolicyอนุญาตให้ใช้บริการเฉพาะและนโยบายปฏิเสธเท่านั้น SageMakerDeniedServicesPolicyโดยมีการปฏิเสธอย่างชัดเจนในการเรียก SageMaker API บางรายการ

นโยบายการเข้าถึงของนักพัฒนา Studio บังคับใช้การตั้งค่าของ Team แท็กเท่ากับค่าเดียวกับบทบาทการดำเนินการของผู้ใช้เองสำหรับการเรียก SageMaker . ใดๆ Create* ไฟ:

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

นอกจากนี้ ยังอนุญาตให้ใช้การลบ หยุด อัปเดต และเริ่มดำเนินการกับทรัพยากรที่แท็กด้วยแท็กทีมเดียวกันกับบทบาทการดำเนินการของผู้ใช้เท่านั้น:

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

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับบทบาทและนโยบาย อ้างถึงการกำหนดค่า Amazon SageMaker Studio สำหรับทีมและกลุ่มที่มีการแยกทรัพยากรโดยสมบูรณ์

โครงสร้างพื้นฐานเครือข่าย

โซลูชันนี้ใช้สภาพแวดล้อมโดเมน SageMaker ที่แยกออกมาอย่างสมบูรณ์พร้อมการรับส่งข้อมูลเครือข่ายทั้งหมด AWS PrivateLink การเชื่อมต่อ คุณสามารถเลือกเปิดใช้งานการเข้าถึงอินเทอร์เน็ตจากโน้ตบุ๊ก Studio การแก้ปัญหายังสร้างสาม กลุ่มความปลอดภัย VPC เพื่อควบคุมการรับส่งข้อมูลระหว่างส่วนประกอบโซลูชันทั้งหมด เช่น ฟังก์ชันแบ็กเอนด์ Lambda ของ SAML ปลายทาง VPC, และโน๊ตบุ๊คสตูดิโอ

เพื่อการพิสูจน์แนวคิดและความเรียบง่ายนี้ โซลูชันจะสร้างซับเน็ต SageMaker ในเครือข่ายเดียว โซนความพร้อมใช้งาน. สำหรับการตั้งค่าการใช้งานจริงของคุณ คุณต้องใช้เครือข่ายย่อยส่วนตัวหลายเครือข่ายใน Availability Zone หลาย ๆ แห่ง และตรวจสอบให้แน่ใจว่าแต่ละเครือข่ายย่อยมีขนาดที่เหมาะสม โดยสมมติว่า IP ขั้นต่ำห้า IP ต่อผู้ใช้หนึ่งราย

โซลูชันนี้จัดเตรียมโครงสร้างพื้นฐานเครือข่ายที่จำเป็นทั้งหมด เทมเพลต CloudFormation ./cfn- templates/vpc.yaml มีซอร์สโค้ด

ขั้นตอนการปรับใช้

ในการปรับใช้และทดสอบโซลูชัน คุณต้องทำตามขั้นตอนต่อไปนี้:

1. ปรับใช้สแต็กของโซลูชันผ่าน an โมเดลแอปพลิเคชัน AWS Serverless เทมเพลต (AWS SAM)
2. สร้างผู้ใช้ AWS SSO หรือใช้ผู้ใช้ AWS SSO ที่มีอยู่
3. สร้างแอปพลิเคชัน SAML 2.0 แบบกำหนดเองและกำหนดผู้ใช้ AWS SSO ให้กับแอปพลิเคชัน

ซอร์สโค้ดแบบเต็มสำหรับโซลูชันมีอยู่ใน GitHub . ของเรา กรุ.

เบื้องต้น

ในการใช้วิธีแก้ปัญหานี้ อินเทอร์เฟซบรรทัดคำสั่ง AWS AWS (AWS CLI) AWS SAM CLIและ Python3.8 หรือใหม่กว่า จะต้องติดตั้ง

ขั้นตอนการปรับใช้ถือว่าคุณเปิดใช้งาน AWS SSO และกำหนดค่าสำหรับ องค์กร AWS ในบัญชีที่มีการปรับใช้โซลูชัน

หากต้องการตั้งค่า AWS SSO โปรดดูคำแนะนำใน GitHub.

ตัวเลือกการปรับใช้โซลูชัน

คุณสามารถเลือกจากตัวเลือกการปรับใช้โซลูชันต่างๆ เพื่อให้เหมาะสมกับสภาพแวดล้อม AWS ที่มีอยู่ของคุณมากที่สุด คุณยังสามารถเลือกตัวเลือกการจัดสรรเครือข่ายและโดเมน SageMaker สำหรับข้อมูลโดยละเอียดเกี่ยวกับตัวเลือกการปรับใช้ต่างๆ โปรดดูที่ ไฟล์ README.

ปรับใช้เทมเพลต AWS SAM

ในการปรับใช้เทมเพลต AWS SAM ให้ทำตามขั้นตอนต่อไปนี้:

1. โคลนซอร์สโค้ด กรุ กับสภาพแวดล้อมในพื้นที่ของคุณ:

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

2. สร้างแอปพลิเคชัน AWS SAM:
3. ปรับใช้แอปพลิเคชัน:

   sam deploy --guided

4. จัดเตรียมพารามิเตอร์สแต็กตามสภาพแวดล้อมที่มีอยู่ของคุณและตัวเลือกการปรับใช้ที่ต้องการ เช่น VPC ที่มีอยู่ ซับเน็ตส่วนตัวและสาธารณะที่มีอยู่ และโดเมน SageMaker ที่มีอยู่ ตามที่กล่าวไว้ใน ตัวเลือกการปรับใช้โซลูชัน บทของไฟล์ README

คุณสามารถปล่อยให้พารามิเตอร์ทั้งหมดเป็นค่าเริ่มต้นเพื่อจัดเตรียมทรัพยากรเครือข่ายใหม่และโดเมน SageMaker ใหม่ อ้างถึงการใช้พารามิเตอร์โดยละเอียดใน README ไฟล์ หากคุณต้องการเปลี่ยนการตั้งค่าเริ่มต้นใดๆ

รอจนกว่าการปรับใช้สแต็กจะเสร็จสมบูรณ์ การปรับใช้แบบ end-to-end รวมถึงการจัดเตรียมทรัพยากรเครือข่ายทั้งหมดและโดเมน SageMaker ใช้เวลาประมาณ 20 นาที

หากต้องการดูเอาต์พุตสแต็ก ให้รันคำสั่งต่อไปนี้ในเทอร์มินัล:

export STACK_NAME=<SAM stack name>

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

สร้างผู้ใช้ SSO

ทำตามคำแนะนำเพื่อ เพิ่มผู้ใช้ AWS SSO เพื่อสร้างผู้ใช้สองคนที่มีชื่อ User1 และ User2 หรือใช้ผู้ใช้ AWS SSO ที่มีอยู่สองคนเพื่อทดสอบโซลูชัน ตรวจสอบให้แน่ใจว่าคุณใช้ AWS SSO ในภูมิภาค AWS เดียวกันกับที่คุณใช้โซลูชัน

สร้างแอปพลิเคชัน SAML 2.0 ที่กำหนดเอง

ในการสร้างแอปพลิเคชัน SAML 2.0 แบบกำหนดเองที่จำเป็นสำหรับทีม 1 และสำหรับทีม 2 ให้ทำตามขั้นตอนต่อไปนี้:

1. เปิดคอนโซล AWS SSO ในบัญชีการจัดการ AWS ขององค์กร AWS ของคุณ ในภูมิภาคเดียวกับที่คุณปรับใช้กองโซลูชัน
2. Choose การใช้งาน ในบานหน้าต่างนำทาง
3. Choose เพิ่มแอปพลิเคชั่นใหม่.
4. Choose เพิ่มแอปพลิเคชัน SAML 2.0 ที่กำหนดเอง.
5. สำหรับ ชื่อที่แสดงป้อนชื่อแอปพลิเคชัน เช่น SageMaker Studio Team 1.
6. ทิ้ง URL เริ่มต้นแอปพลิเคชัน และ สถานะรีเลย์ ว่างเปล่า
7. Choose หากคุณไม่มีไฟล์ข้อมูลเมตา คุณสามารถป้อนค่าข้อมูลเมตาได้ด้วยตนเอง.
8. สำหรับ แอปพลิเคชัน ACS URLป้อน URL ที่ให้ไว้ใน SAMLBackendEndpoint คีย์ของเอาต์พุตสแต็ก AWS SAM
9. สำหรับ แอปพลิเคชัน SAML ผู้ชมป้อน URL ที่ให้ไว้ใน SAMLAudience คีย์ของเอาต์พุตสแต็ก AWS SAM
10. Choose บันทึกการเปลี่ยนแปลง.
    
11. ไปที่ การแมปแอตทริบิวต์ แถบ
12. ตั้ง หัวข้อ ไปยัง อีเมล และ รูปแบบ ไปยัง ที่อยู่อีเมล.
13. เพิ่มแอตทริบิวต์ใหม่ดังต่อไปนี้:
    1. ssouserid ตั้งค่าให้ ${user:AD_GUID}
    2. teamid ตั้งค่าให้ Team1 or Team2ตามลำดับ สำหรับแต่ละแอปพลิเคชัน
       
14. Choose บันทึกการเปลี่ยนแปลง.
15. เกี่ยวกับ ผู้ใช้ที่ได้รับมอบหมาย เลือกแท็บ กำหนดผู้ใช้.
16. เลือกผู้ใช้ 1 สำหรับแอปพลิเคชัน Team 1 และทั้งผู้ใช้ 1 และผู้ใช้ 2 สำหรับแอปพลิเคชัน Team 2
17. Choose กำหนดผู้ใช้.
    

ทดสอบวิธีแก้ปัญหา

ในการทดสอบโซลูชัน ให้ทำตามขั้นตอนต่อไปนี้:

1. ไปที่พอร์ทัลผู้ใช้ AWS SSO https://<Identity Store ID>.awsapps.com/start และลงชื่อเป็นผู้ใช้ 1
   แอปพลิเคชัน SageMaker สองรายการจะแสดงในพอร์ทัล
   
2. Choose ทีม SageMaker Studio 1.
   คุณถูกเปลี่ยนเส้นทางไปยังอินสแตนซ์ Studio สำหรับ Team 1 ในหน้าต่างเบราว์เซอร์ใหม่
   ครั้งแรกที่คุณเริ่ม Studio SageMaker จะสร้างแอปพลิเคชัน JupyterServer กระบวนการนี้ใช้เวลาไม่กี่นาที
   
3. ในสตูดิโอ บน เนื้อไม่มีมัน เมนูให้เลือก ใหม่ และ สถานีปลายทาง เพื่อเริ่มต้นเทอร์มินัลใหม่
4. ในบรรทัดคำสั่งเทอร์มินัล ให้ป้อนคำสั่งต่อไปนี้:

   aws sts get-caller-identity

   คำสั่งส่งคืนบทบาทการดำเนินการของ Studio
   

   ในการตั้งค่าของเรา บทบาทนี้จะต้องแตกต่างกันในแต่ละทีม คุณยังสามารถตรวจสอบได้ว่าผู้ใช้แต่ละรายในแต่ละอินสแตนซ์ของ Studio มีโฮมไดเร็กทอรีของตนเองบนวอลุ่ม Amazon EFS ที่ต่อเชื่อม

5. กลับไปที่พอร์ทัล AWS SSO โดยยังคงบันทึกเป็นผู้ใช้ 1 แล้วเลือก ทีม SageMaker Studio 2.
   คุณถูกเปลี่ยนเส้นทางไปยังอินสแตนซ์ Team 2 Studio
   กระบวนการเริ่มต้นอาจใช้เวลาหลายนาทีอีกครั้ง เนื่องจาก SageMaker เริ่มแอปพลิเคชัน JupyterServer ใหม่สำหรับผู้ใช้ 2
6. ลงชื่อเป็นผู้ใช้ 2 ในพอร์ทัล AWS SSO
   ผู้ใช้ 2 มีเพียงหนึ่งแอปพลิเคชันที่กำหนด: SageMaker Studio Team 2
   

หากคุณเริ่มอินสแตนซ์ของ Studio ผ่านแอปพลิเคชันผู้ใช้นี้ คุณสามารถตรวจสอบว่าใช้บทบาทการดำเนินการ SageMaker เดียวกันกับอินสแตนซ์ Team 1 ของผู้ใช้ 2 อย่างไรก็ตาม แต่ละอินสแตนซ์ของ Studio จะถูกแยกออกโดยสิ้นเชิง ผู้ใช้ 2 มีโฮมไดเร็กทอรีของตนเองบนวอลุ่ม Amazon EFS และอินสแตนซ์ของแอปพลิเคชัน JupyterServer คุณสามารถตรวจสอบได้โดยการสร้างโฟลเดอร์และไฟล์บางไฟล์สำหรับผู้ใช้แต่ละราย และดูว่าโฮมไดเร็กทอรีของผู้ใช้แต่ละรายแยกจากกัน

ตอนนี้คุณสามารถลงชื่อเข้าใช้คอนโซล SageMaker และดูว่ามีการสร้างโปรไฟล์ผู้ใช้สามโปรไฟล์

คุณเพิ่งใช้โซลูชันการพิสูจน์แนวคิดเพื่อจัดการผู้ใช้หลายรายและหลายทีมด้วย Studio

ทำความสะอาด

เพื่อหลีกเลี่ยงการเรียกเก็บเงิน คุณต้องลบทรัพยากรที่สร้างและจัดเตรียมโครงการทั้งหมดออกจากบัญชี AWS ของคุณ ใช้คำสั่ง SAM CLI ต่อไปนี้เพื่อลบโซลูชัน CloudFormation stack:

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

ด้วยเหตุผลด้านความปลอดภัยและเพื่อป้องกันข้อมูลสูญหาย การต่อเชื่อม Amazon EFS และเนื้อหาที่เกี่ยวข้องกับโดเมน Studio ที่ปรับใช้ในโซลูชันนี้จะไม่ถูกลบ VPC และซับเน็ตที่เชื่อมโยงกับโดเมน SageMaker จะยังคงอยู่ในบัญชี AWS ของคุณ สำหรับคำแนะนำในการลบระบบไฟล์และ VPC โปรดดูที่ การลบระบบไฟล์ Amazon EFS และ ทำงานกับ VPCตามลำดับ

หากต้องการลบแอปพลิเคชัน SAML ที่กำหนดเอง ให้ทำตามขั้นตอนต่อไปนี้:

1. เปิดคอนโซล AWS SSO ในบัญชีการจัดการ AWS SSO
2. Choose การใช้งาน.
3. เลือก ทีม SageMaker Studio 1.
4. เกี่ยวกับ สถานะ เมนูให้เลือก ลบรายการออกจากรถเข็น.
5. ทำซ้ำขั้นตอนเหล่านี้สำหรับ ทีม SageMaker Studio 2.

สรุป

โซลูชันนี้สาธิตวิธีที่คุณสามารถสร้างสภาพแวดล้อมที่ยืดหยุ่นและปรับแต่งได้โดยใช้โปรไฟล์ผู้ใช้ AWS SSO และ Studio เพื่อสนับสนุนโครงสร้างองค์กรของคุณเอง ขั้นตอนการปรับปรุงต่อไปที่เป็นไปได้สำหรับโซลูชันที่พร้อมสำหรับการผลิตอาจเป็น:

• ใช้การจัดการโปรไฟล์ผู้ใช้ Studio แบบอัตโนมัติเป็นไมโครเซอร์วิสเฉพาะเพื่อสนับสนุนเวิร์กโฟลว์การจัดเตรียมโปรไฟล์อัตโนมัติ และเพื่อจัดการข้อมูลเมตาและการกำหนดค่าสำหรับโปรไฟล์ผู้ใช้ เช่น อเมซอน ไดนาโมดีบี.
• ใช้กลไกเดียวกันในกรณีทั่วไปของโดเมน SageMaker หลายโดเมนและบัญชี AWS หลายบัญชี แบ็กเอนด์ SAML เดียวกันสามารถขาย URL ที่กำหนดไว้ล่วงหน้าซึ่งเปลี่ยนเส้นทางไปยังชุดค่าผสมของโปรไฟล์-โดเมน-บัญชีตามตรรกะที่คุณกำหนดเองตามการให้สิทธิ์ของผู้ใช้และการตั้งค่าทีม
• ใช้กลไกการซิงโครไนซ์ระหว่าง IdP ของคุณกับ AWS SSO และสร้างแอปพลิเคชัน SAML 2.0 แบบกำหนดเองโดยอัตโนมัติ
• ใช้ข้อมูลที่ปรับขนาดได้และการจัดการการเข้าถึงทรัพยากรด้วย การควบคุมการเข้าถึงตามแอตทริบิวต์ (เอแบค).

หากคุณมีข้อเสนอแนะหรือคำถามใด ๆ โปรดแสดงความคิดเห็น

อ่านเพิ่มเติม

เอกสาร

บล๊อคโพสต์

เกี่ยวกับผู้เขียน

เยฟเกนี อิลยิน เป็นสถาปนิกโซลูชันที่ AWS เขามีประสบการณ์มากกว่า 20 ปีในการทำงานในการพัฒนาซอฟต์แวร์และสถาปัตยกรรมโซลูชันทุกระดับ และได้ใช้ภาษาการเขียนโปรแกรมตั้งแต่ COBOL และ Assembler ไปจนถึง .NET, Java และ Python เขาพัฒนาและเขียนโค้ดโซลูชันคลาวด์เนทีฟโดยมุ่งเน้นที่ข้อมูลขนาดใหญ่ การวิเคราะห์ และวิศวกรรมข้อมูล