إدارة الفريق والمستخدم مع Amazon SageMaker و AWS SSO

أمازون ساجميكر ستوديو هي بيئة تطوير متكاملة قائمة على الويب (IDE) للتعلم الآلي (ML) تتيح لك إنشاء نماذج ML الخاصة بك وتدريبها وتصحيحها ونشرها ومراقبتها. يمتلك كل مستخدم داخلي في Studio مجموعة موارد مخصصة خاصة به ، مثل مثيلات الحوسبة ، ودليل رئيسي على ملف نظام ملفات أمازون المرن (Amazon EFS) حجم ومخصص إدارة الهوية والوصول AWS (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 إنشاء ملفات تعريف المستخدمين بناءً على معرف مستخدم AWS SSO. لا يمكنك إنشاء ملفات تعريف المستخدمين عبر وحدة تحكم إدارة AWS. يعمل هذا بشكل جيد في الحالة التي يكون فيها أحد المستخدمين عضوًا في فريق علم بيانات واحد فقط أو إذا كان لدى المستخدمين نفس متطلبات الوصول أو متشابهة جدًا عبر مشاريعهم وفرقهم. في حالة الاستخدام الأكثر شيوعًا ، عندما يمكن للمستخدم المشاركة في العديد من مشاريع ML ويكون عضوًا في فرق متعددة بمتطلبات أذونات مختلفة قليلاً ، يتطلب المستخدم الوصول إلى ملفات تعريف مستخدم Studio مختلفة بأدوار تنفيذية وسياسات أذونات مختلفة. نظرًا لأنه لا يمكنك إدارة ملفات تعريف المستخدمين بشكل مستقل عن AWS SSO في وضع مصادقة AWS SSO ، لا يمكنك تنفيذ تعيين واحد إلى متعدد بين المستخدمين وملفات تعريف مستخدمي Studio.

إذا كنت بحاجة إلى إنشاء فصل قوي لسياقات الأمان ، على سبيل المثال لفئات البيانات المختلفة ، أو كنت بحاجة إلى منع رؤية مجموعة واحدة من أنشطة المستخدمين ومواردهم إلى مجموعة أخرى ، فإن الأسلوب الموصى به هو إنشاء مجالات SageMaker متعددة. في وقت كتابة هذه السطور ، يمكنك إنشاء مجال واحد فقط لكل حساب AWS لكل منطقة. لتنفيذ الفصل القوي ، يمكنك استخدام حسابات AWS متعددة مع مجال واحد لكل حساب كحل بديل.

التحدي الثاني هو تقييد الوصول إلى Studio IDE للمستخدمين فقط من داخل شبكة الشركة أو VPC المعين. يمكنك تحقيق ذلك باستخدام سياسات التحكم في الوصول المستندة إلى IAM. في هذه الحالة ، يجب تكوين مجال SageMaker باستخدام وضع مصادقة IAM، لأن السياسات القائمة على هوية IAM لا تدعمها آلية تسجيل الدخول في وضع AWS SSO. المنشور الوصول الآمن إلى Amazon SageMaker Studio باستخدام AWS SSO وتطبيق SAML يحل هذا التحدي ويوضح كيفية التحكم في وصول الشبكة إلى مجال SageMaker.

يعالج هذا الحل هذه التحديات التي تواجه إدارة مستخدمي AWS SSO لـ Studio لحالة الاستخدام الشائعة لمجموعات مستخدمين متعددة وتعيين متعدد إلى متعدد بين المستخدمين والفرق. يوضح الحل كيفية استخدام ملف تطبيق SAML 2.0 المخصص كآلية لتشغيل مصادقة المستخدم لـ Studio ودعم ملفات تعريف مستخدم Studio متعددة لكل مستخدم AWS SSO واحد.

يمكنك استخدام هذا الأسلوب لتنفيذ بوابة مستخدم مخصصة مع تطبيقات مدعومة بعملية تفويض SAML 2.0. يمكن أن تتمتع بوابة المستخدم المخصصة الخاصة بك بأقصى قدر من المرونة في كيفية إدارة وعرض تطبيقات المستخدم. على سبيل المثال ، يمكن لبوابة المستخدم إظهار بعض البيانات الوصفية لمشروع ML لتسهيل تحديد تطبيق للوصول إليه.

يمكنك العثور على الكود المصدري للحل في موقعنا مستودع جيثب.

حل نظرة عامة

الحل يطبق العمارة التالية.

مكونات العمارة عالية المستوى الرئيسية هي كما يلي:

1. مزود الهوية - تتم إدارة المستخدمين والمجموعات في مصدر هوية خارجي ، على سبيل المثال في Azure AD. تحدد تعيينات المستخدم لمجموعات AD الأذونات التي يمتلكها مستخدم معين وفريق الاستوديو الذي يمكنهم الوصول إليه. يجب أن يكون مصدر الهوية متزامنًا مع AWS SSO.
2. خدمة AWS SSO - يدير AWS SSO مستخدمي SSO ومجموعات أذونات SSO والتطبيقات. يستخدم هذا الحل تطبيق SAML 2.0 المخصص لتوفير الوصول إلى Studio لمستخدمي AWS SSO المؤهلين. يستخدم الحل أيضًا تعيين سمة SAML لتعبئة تأكيد SAML ببيانات محددة ذات صلة بالوصول ، مثل معرف المستخدم وفريق المستخدم. نظرًا لأن الحل ينشئ واجهة برمجة تطبيقات SAML ، يمكنك استخدام أي تأكيدات SAML تدعم IdP لإنشاء هذه البنية. على سبيل المثال ، يمكنك استخدام Okta أو حتى تطبيق الويب الخاص بك الذي يوفر صفحة مقصودة مع بوابة مستخدم وتطبيقات. في هذا المنشور ، نستخدم AWS SSO.
3. تطبيقات SAML 2.0 المخصصة - ينشئ الحل تطبيقًا واحدًا لكل فريق Studio ويخصص تطبيقًا واحدًا أو عدة تطبيقات لمستخدم أو مجموعة مستخدمين بناءً على الاستحقاقات. يمكن للمستخدمين الوصول إلى هذه التطبيقات من داخل بوابة مستخدم AWS SSO الخاصة بهم بناءً على الأذونات المعينة. يتم تكوين كل تطبيق بامتداد بوابة أمازون API عنوان 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 دور تنفيذ مخصص مع سياسات الأذونات مع مستوى الوصول المطلوب للفريق المحدد الذي ينتمي إليه المستخدم. تقوم أدوار تنفيذ الاستوديو بتنفيذ عزل إذن فعال بين المستخدمين الفرديين وأدوار الفريق الخاصة بهم. يمكنك إدارة الوصول إلى البيانات والموارد لكل دور وليس على مستوى المستخدم الفردي.

ينفذ الحل أيضًا عنصر تحكم في الوصول المستند إلى السمات (ABAC) باستخدام سمات SAML 2.0 والعلامات في ملفات تعريف مستخدم Studio وعلامات على أدوار تنفيذ SageMaker.

في هذا التكوين المحدد ، نفترض أن مستخدمي AWS SSO ليس لديهم أذونات لتسجيل الدخول إلى حساب AWS وليس لديهم أدوار IAM المقابلة التي يتحكم فيها AWS SSO في الحساب. يقوم كل مستخدم بتسجيل الدخول إلى بيئة الاستوديو الخاصة به عبر عنوان URL مُخصص مسبقًا من بوابة AWS SSO دون الحاجة إلى الانتقال إلى وحدة التحكم في حساب AWS الخاص به. في بيئة العالم الحقيقي ، قد تحتاج إلى الإعداد مجموعات أذونات AWS SSO للمستخدمين للسماح للمستخدمين المخولين بتولي دور IAM وتسجيل الدخول إلى حساب AWS. على سبيل المثال ، يمكنك توفير أذونات دور عالم البيانات للمستخدم حتى يتمكن من التفاعل مع موارد الحساب ولديه مستوى الوصول الذي يحتاجه لأداء دوره.

بنية الحل وسير العمل

يعرض الرسم البياني التالي تدفق تسجيل الدخول من طرف إلى طرف لمستخدم AWS SSO.

يختار مستخدم AWS SSO تطبيق Studio مطابقًا في بوابة AWS SSO الخاصة به. يعد AWS SSO تأكيد SAML (1) مع تعيينات سمات SAML المكونة. يتم تكوين تطبيق SAML المخصص باستخدام عنوان URL لنقطة نهاية API Gateway باعتباره Assertion Consumer Service (ACS) ، ويحتاج إلى سمات تعيين تحتوي على معرف مستخدم AWS SSO ومعرف الفريق. نحن نستخدم ssouserid و teamid السمات المخصصة لإرسال جميع المعلومات المطلوبة إلى الواجهة الخلفية لـ SAML.

تستدعي بوابة API واجهة برمجة تطبيقات خلفية SAML. ان AWS لامدا تقوم الوظيفة (2) بتنفيذ واجهة برمجة التطبيقات ، وتقوم بتحليل استجابة SAML لاستخراج معرف المستخدم ومعرف الفريق. تستخدمها الوظيفة لاسترداد تكوين خاص بالفريق ، مثل دور التنفيذ ومعرف مجال SageMaker. تتحقق الوظيفة من وجود ملف تعريف مستخدم مطلوب في المجال ، وتقوم بإنشاء ملف تعريف جديد مع إعدادات التكوين المقابلة في حالة عدم وجود ملف تعريف. بعد ذلك ، تقوم الوظيفة بإنشاء عنوان URL تم تعيينه مسبقًا من Studio لملف تعريف مستخدم Studio معين عن طريق الاتصال إنشاءPresignedDomainUrl API (3) عبر نقطة نهاية SageMaker API VPC. تقوم وظيفة Lambda أخيرًا بإرجاع عنوان URL المعين مسبقًا باستجابة إعادة توجيه HTTP 302 لتسجيل دخول المستخدم إلى Studio.

ينفذ الحل نسخة نموذجية غير إنتاجية لواجهة SAML الخلفية. تحلل الدالة Lambda تأكيد SAML وتستخدم السمات الموجودة في ملف <saml2:AttributeStatement> عنصر لبناء أ CreatePresignedDomainUrl استدعاء API. في حل الإنتاج الخاص بك ، يجب عليك استخدام تنفيذ خلفية SAML مناسب ، والذي يجب أن يتضمن التحقق من صحة استجابة SAML ، وتوقيع ، وشهادات ، ومنع إعادة التشغيل وإعادة التوجيه ، وأي ميزات أخرى لعملية مصادقة SAML. على سبيل المثال ، يمكنك استخدام ملف تنفيذ الواجهة الخلفية لـ python3-saml SAML or مجموعة أدوات SAML مفتوحة المصدر OneLogin لتنفيذ خلفية SAML آمنة.

الإنشاء الديناميكي لملفات تعريف مستخدم الاستوديو

يُنشئ الحل تلقائيًا ملف تعريف مستخدم Studio لكل مجموعة من المستخدمين والفريق ، بمجرد أن تطلب عملية تسجيل الدخول SSO في AWS عنوان 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. دور تنفيذ Lambda للخلفية SAML - يحتوي دور التنفيذ هذا على إذن لاستدعاء CreatePresignedDomainUrl API. يمكنك تكوين سياسة الأذونات لتضمين عمليات تحقق شرطية إضافية باستخدام 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 باستخدام السياسات القائمة على الهوية.

3. SageMaker - يتولى SageMaker دور تنفيذ الاستوديو نيابة عنك ، حيث تتحكم فيه سياسة الثقة المقابلة في دور التنفيذ. يسمح هذا للخدمة بالوصول إلى البيانات والموارد ، وتنفيذ الإجراءات نيابة عنك. يجب أن يحتوي دور تنفيذ الاستوديو على سياسة ثقة تسمح لـ SageMaker بتولي هذا الدور.
4. تعيين إذن AWS SSO دور IAM - يمكنك تعيين مستخدمي AWS SSO لحسابات AWS في مؤسسة AWS الخاصة بك عبر مجموعات أذونات AWS SSO. مجموعة الأذونات عبارة عن قالب يحدد مجموعة من سياسات IAM الخاصة بدور المستخدم. أنت تدير مجموعات الأذونات في AWS SSO ، ويتحكم AWS SSO في أدوار IAM المقابلة في كل حساب.
5. سياسات التحكم في خدمة مؤسسات AWS - كما ترى مؤسسات AWS ، يمكنك تنفيذها نُهج مراقبة الخدمة (SCPs) للتحكم مركزيًا في الحد الأقصى من الأذونات المتاحة لجميع الحسابات وجميع أدوار 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 كومة لهذا الحل ، يقوم بإنشاء ثلاثة أدوار تنفيذية في Studio مستخدمة في مجال SageMaker:

• SageMakerStudioExecutionRoleDefault
• SageMakerStudioExecutionRoleTeam1
• SageMakerStudioExecutionRoleTeam2

أيا من الأدوار لها AmazonSageMakerFullAccess السياسة المرفقة ، ولكل منها مجموعة محدودة فقط من الأذونات. في بيئة SageMaker الواقعية لديك ، تحتاج إلى تعديل أذونات الدور بناءً على متطلباتك المحددة.

SageMakerStudioExecutionRoleDefault لديه فقط السياسة المخصصة SageMakerReadOnlyPolicy مرفق بقائمة مقيدة من الإجراءات المسموح بها.

كلا أدوار الفريق ، SageMakerStudioExecutionRoleTeam1 و SageMakerStudioExecutionRoleTeam2، بالإضافة إلى سياستين مخصصتين ، SageMakerAccessSupportingServicesPolicy و SageMakerStudioDeveloperAccessPolicy، مما يسمح باستخدام خدمات معينة وسياسة رفض واحدة فقط ، SageMakerDeniedServicesPolicy، مع رفض صريح لبعض مكالمات واجهة برمجة تطبيقات SageMaker.

يفرض نهج وصول مطوري الاستوديو إعداد ملف Team علامة تساوي نفس قيمة دور التنفيذ الخاص بالمستخدم لاستدعاء أي برنامج 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"
}

علاوة على ذلك ، فإنه يسمح باستخدام عمليات الحذف والإيقاف والتحديث والبدء فقط على الموارد التي تم وضع علامة عليها بنفس علامة الفريق مثل دور التنفيذ الخاص بالمستخدم:

{
    "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 الرابط الخاص روابط. يمكنك اختياريًا تمكين الوصول إلى الإنترنت من أجهزة كمبيوتر Studio المحمولة. الحل أيضا يخلق ثلاثة مجموعات أمان VPC للتحكم في حركة المرور بين جميع مكونات الحل مثل وظيفة Lambda للخلفية SAML ، نقاط نهاية VPC ، وأجهزة الاستوديو.

بالنسبة لإثبات المفهوم والبساطة هذا ، ينشئ الحل شبكة فرعية SageMaker في ملف واحد منطقة التوفر. لإعداد الإنتاج الخاص بك ، يجب عليك استخدام شبكات فرعية خاصة متعددة عبر مناطق توافر خدمات متعددة والتأكد من أن كل شبكة فرعية ذات حجم مناسب ، بافتراض خمسة عناوين IP كحد أدنى لكل مستخدم.

يوفر هذا الحل جميع البنية التحتية للشبكة المطلوبة. نموذج CloudFormation ./cfn-templates/vpc.yaml يحتوي على شفرة المصدر.

خطوات النشر

لنشر الحل واختباره ، يجب عليك إكمال الخطوات التالية:

1. انشر مكدس الحل عبر ملف نموذج تطبيق AWS Serverless (AWS SAM).
2. أنشئ مستخدمي AWS SSO ، أو استخدم مستخدمي AWS SSO الحاليين.
3. أنشئ تطبيقات SAML 2.0 مخصصة وقم بتعيين مستخدمي AWS SSO للتطبيقات.

يتم توفير رمز المصدر الكامل للحل في GitHub الخاص بنا مستودع.

المتطلبات الأساسية المسبقة

لاستخدام هذا الحل ، فإن واجهة سطر الأوامر AWS (AWS 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 الحالي ، كما تمت مناقشته في خيارات نشر الحل فصل من ملف التمهيدي.

يمكنك ترك جميع المعلمات في قيمها الافتراضية لتوفير موارد شبكة جديدة ومجال SageMaker جديد. الرجوع إلى استخدام المعلمة المفصلة في README ملف إذا كنت بحاجة إلى تغيير أي إعدادات افتراضية.

انتظر حتى اكتمال نشر المكدس. يستغرق النشر الشامل بما في ذلك توفير جميع موارد الشبكة ومجال 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. اختار التطبيقات في جزء التنقل.
3. اختار أضف تطبيقًا جديدًا.
4. اختار أضف تطبيق SAML 2.0 مخصص.
5. في حالة إسم المستخدم، أدخل اسم التطبيق ، على سبيل المثال SageMaker Studio Team 1.
6. يترك عنوان URL لبدء التطبيق و حالة التتابع فارغة.
7. اختار إذا لم يكن لديك ملف بيانات وصفية ، فيمكنك إدخال قيم البيانات الوصفية يدويًا.
8. في حالة عنوان URL لـ ACS للتطبيق، أدخل عنوان URL المتوفر في ملف SAMLBackendEndpoint مفتاح إخراج مكدس AWS SAM.
9. في حالة جمهور تطبيق SAML، أدخل عنوان URL المتوفر في ملف SAMLAudience مفتاح إخراج مكدس AWS SAM.
10. اختار حفظ التغييرات.
    
11. انتقل إلى تعيينات السمات علامة التبويب.
12. تعيين الموضوع إلى البريد الإلكتروني و شكل إلى عنوان بريد الكتروني.
13. أضف السمات الجديدة التالية:
    1. ssouserid تعيين إلى ${user:AD_GUID}
    2. teamid تعيين إلى Team1 or Team2، على التوالي ، لكل تطبيق
       
14. اختار حفظ التغييرات.
15. على المستخدمون المعينون علامة التبويب، اختر تعيين المستخدمين.
16. اختر المستخدم 1 لتطبيق Team 1 وكل من المستخدم 1 والمستخدم 2 لتطبيق Team 2.
17. اختار تعيين المستخدمين.
    

اختبر المحلول

لاختبار الحل ، أكمل الخطوات التالية:

1. انتقل إلى بوابة مستخدم AWS SSO https://<Identity Store ID>.awsapps.com/start ووقع كمستخدم 1.
   يتم عرض تطبيقين من تطبيقات SageMaker في البوابة.
   
2. اختار فريق SageMaker Studio 1.
   تتم إعادة توجيهك إلى مثيل Studio للفريق 1 في نافذة متصفح جديدة.
   في المرة الأولى التي تبدأ فيها تشغيل Studio ، يقوم SageMaker بإنشاء تطبيق JupyterServer. تستغرق هذه العملية بضع دقائق.
   
3. في الاستوديو ، على قم بتقديم القائمة، اختر جديد و محطة لبدء محطة جديدة.
4. في سطر أوامر المحطة ، أدخل الأمر التالي:

   aws sts get-caller-identity

   يقوم الأمر بإرجاع دور تنفيذ الاستوديو.
   

   في الإعداد لدينا ، يجب أن يكون هذا الدور مختلفًا لكل فريق. يمكنك أيضًا التحقق من أن كل مستخدم في كل مثيل من 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 مثل مثيل الفريق 1 للمستخدم 2. ومع ذلك ، يتم عزل كل مثيل Studio تمامًا. يمتلك المستخدم 2 الدليل الرئيسي الخاص به على وحدة تخزين Amazon EFS ومثيله الخاص لتطبيق JupyterServer. يمكنك التحقق من ذلك عن طريق إنشاء مجلد وبعض الملفات لكل مستخدم ومعرفة أن الدليل الرئيسي لكل مستخدم معزول.

يمكنك الآن تسجيل الدخول إلى وحدة تحكم SageMaker ومعرفة أن هناك ثلاثة ملفات تعريف مستخدم تم إنشاؤها.

لقد نفذت للتو إثباتًا لحل المفهوم لإدارة العديد من المستخدمين والفرق باستخدام Studio.

تنظيف

لتجنب الرسوم ، يجب عليك إزالة جميع الموارد المخصصة للمشروع والتي تم إنشاؤها من حساب AWS الخاص بك. استخدم الأمر SAM CLI التالي لحذف مكدس CloudFormation للحل:

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

لأسباب تتعلق بالأمان ولمنع فقدان البيانات ، لا يتم حذف تحميل Amazon EFS والمحتوى المرتبط بنطاق Studio المنشور في هذا الحل. تظل VPC والشبكات الفرعية المرتبطة بمجال SageMaker في حساب AWS الخاص بك. للحصول على إرشادات لحذف نظام الملفات و VPC ، راجع حذف نظام ملفات Amazon EFS و العمل مع VPCs، على التوالي.

لحذف تطبيق SAML المخصص ، أكمل الخطوات التالية:

1. افتح وحدة تحكم AWS SSO في حساب إدارة AWS SSO.
2. اختار التطبيقات.
3. أختار فريق SageMaker Studio 1.
4. على الإجراءات القائمة، اختر حذف.
5. كرر هذه الخطوات لـ فريق SageMaker Studio 2.

وفي الختام

أوضح هذا الحل كيف يمكنك إنشاء بيئة مرنة وقابلة للتخصيص باستخدام ملفات تعريف مستخدم AWS SSO و Studio لدعم هيكل مؤسستك. يمكن أن تكون خطوات التحسين المحتملة التالية نحو حل جاهز للإنتاج هي:

• تنفيذ إدارة ملف تعريف مستخدم Studio المؤتمتة كخدمة مصغرة مخصصة لدعم سير عمل توفير ملف تعريف مؤتمت وللتعامل مع البيانات الوصفية والتكوين لملفات تعريف المستخدمين ، على سبيل المثال في الأمازون DynamoDB.
• استخدم نفس الآلية في حالة أكثر عمومية لنطاقات SageMaker المتعددة وحسابات AWS المتعددة. يمكن لواجهة SAML الخلفية نفسها أن تقدم عنوان URL المقابل المعين مسبقًا لإعادة التوجيه إلى مجموعة ملف تعريف مستخدم ومجال وحساب وفقًا لمنطقك المخصص استنادًا إلى استحقاقات المستخدم وإعداد الفريق.
• نفِّذ آلية مزامنة بين IdP و AWS SSO وأتمتة إنشاء تطبيقات SAML 2.0 المخصصة.
• تنفيذ إدارة الوصول إلى الموارد والبيانات القابلة للتطوير باستخدام التحكم في الوصول المستند إلى السمات (أباك).

إذا كان لديك أي ملاحظات أو أسئلة ، فيرجى تركها في التعليقات.

لمزيد من القراءة

توثيق

المدوّنة

عن المؤلف

يفغيني إلين هو مهندس حلول في AWS. لديه أكثر من 20 عامًا من الخبرة في العمل على جميع مستويات تطوير البرمجيات وهندسة الحلول واستخدم لغات البرمجة من COBOL و Assembler إلى .NET و Java و Python. يقوم بتطوير وترميز الحلول السحابية الأصلية مع التركيز على البيانات الضخمة والتحليلات وهندسة البيانات.