هوش داده افلاطون
جستجوی عمودی و هوش مصنوعی

AI

مدیریت تیم و کاربر با Amazon SageMaker و AWS SSO

بازنشر افلاطون
بازنشر افلاطون

تاریخ:

نمایش ها: 63

Amazon SageMaker Studio یک محیط توسعه یکپارچه مبتنی بر وب (IDE) برای یادگیری ماشین (ML) است که به شما امکان می دهد مدل های ML خود را بسازید، آموزش دهید، اشکال زدایی کنید، استقرار دهید و نظارت کنید. هر کاربر داخلی در استودیو مجموعه ای از منابع اختصاصی خود را دارد، مانند نمونه های محاسباتی، یک فهرست اصلی در یک سیستم فایل الاستیک آمازون (Amazon EFS) جلد، و اختصاصی هویت AWS و مدیریت دسترسی (IAM) نقش اجرایی.

یکی از رایج‌ترین چالش‌های دنیای واقعی در راه‌اندازی دسترسی کاربر برای استودیو، نحوه مدیریت چندین کاربر، گروه‌ها و تیم‌های علم داده برای دسترسی به داده و جداسازی منابع است.

بسیاری از مشتریان مدیریت کاربر را با استفاده از هویت های فدرال با AWS Single Sign-On (AWS SSO) و یک ارائه دهنده هویت خارجی (IdP)، مانند Active Directory (AD) یا AWS Managed Microsoft AD Directory. با AWS هماهنگ است تمرین توصیه شده استفاده از اعتبارنامه های موقت برای دسترسی به حساب های AWS.

An آمازون SageMaker دامنه از AWS SSO پشتیبانی می کند و می تواند در AWS SSO پیکربندی شود حالت تأیید اعتبار. در این مورد، هر کاربر AWS SSO دارای عنوان خاص خود است مشخصات کاربر استودیو. کاربرانی که به استودیو دسترسی دارند، یک URL ورود به سیستم منحصربفرد دارند که مستقیماً استودیو را باز می‌کند و با اعتبارنامه AWS SSO خود وارد سیستم می‌شوند. سازمان ها به جای دامنه SageMaker، کاربران خود را در AWS SSO مدیریت می کنند. می توانید به طور همزمان به چندین کاربر دسترسی به دامنه اختصاص دهید. می توانید از پروفایل های کاربر Studio برای هر کاربر استفاده کنید تا مجوزهای امنیتی خود را در نوت بوک های استودیو از طریق یک نقش IAM متصل به نمایه کاربر، به نام نقش اجرایی. این نقش مجوزهای عملیات SageMaker را مطابق با خط مشی های مجوز IAM کنترل می کند.

در حالت احراز هویت AWS SSO، همیشه نقشه برداری یک به یک بین کاربران و پروفایل های کاربر وجود دارد. دامنه SageMaker ایجاد پروفایل های کاربر را بر اساس شناسه کاربری AWS SSO مدیریت می کند. شما نمی توانید پروفایل های کاربری را از طریق ایجاد کنید کنسول مدیریت AWS. زمانی که یک کاربر تنها عضو یک تیم علم داده باشد یا اگر کاربران نیازمندی‌های دسترسی یکسان یا بسیار مشابهی را در پروژه‌ها و تیم‌های خود داشته باشند، به خوبی کار می‌کند. در یک مورد استفاده رایج تر، زمانی که کاربر می تواند در چندین پروژه ML شرکت کند و عضو تیم های متعدد با شرایط مجوز کمی متفاوت باشد، کاربر نیاز به دسترسی به پروفایل های کاربر مختلف Studio با نقش های اجرایی متفاوت و خط مشی های مجوز دارد. از آنجایی که نمی‌توانید پروفایل‌های کاربر را مستقل از AWS SSO در حالت احراز هویت AWS SSO مدیریت کنید، نمی‌توانید نقشه‌برداری یک به چند را بین کاربران و پروفایل‌های کاربر استودیو اجرا کنید.

اگر نیاز به ایجاد جدایی قوی از زمینه‌های امنیتی دارید، به عنوان مثال برای دسته‌های داده‌های مختلف، یا نیاز دارید که به طور کامل از مشاهده یک گروه از فعالیت‌ها و منابع کاربران به گروه دیگر جلوگیری کنید، رویکرد توصیه‌شده ایجاد دامنه‌های SageMaker متعدد است. در زمان نوشتن این مقاله، شما می توانید تنها یک دامنه به ازای هر حساب AWS در هر منطقه ایجاد کنید. برای پیاده سازی جداسازی قوی، می توانید از چندین حساب AWS با یک دامنه در هر حساب به عنوان راه حل استفاده کنید.

چالش دوم این است که دسترسی به Studio IDE را محدود کنید فقط برای کاربرانی از داخل یک شبکه شرکتی یا یک VPC تعیین شده. با استفاده از آن می توانید به این مهم دست یابید سیاست های کنترل دسترسی مبتنی بر IAM. در این حالت، دامنه SageMaker باید با آن پیکربندی شود حالت احراز هویت IAM، زیرا سیاست های مبتنی بر هویت IAM توسط مکانیزم ورود به سیستم در حالت AWS SSO پشتیبانی نمی شود. پست دسترسی ایمن به Amazon SageMaker Studio با AWS SSO و یک برنامه SAML این چالش را حل می کند و نحوه کنترل دسترسی شبکه به دامنه SageMaker را نشان می دهد.

این راه‌حل چالش‌های مدیریت کاربر AWS SSO برای Studio را برای استفاده مشترک از گروه‌های کاربری متعدد و نقشه‌برداری چند به چند بین کاربران و تیم‌ها برطرف می‌کند. راه حل نحوه استفاده از a برنامه SAML 2.0 سفارشی به عنوان مکانیزمی برای احراز هویت کاربر برای Studio و پشتیبانی از چندین پروفایل کاربر استودیو برای هر کاربر AWS SSO.

می‌توانید از این رویکرد برای پیاده‌سازی یک پورتال کاربر سفارشی با برنامه‌هایی که توسط فرآیند مجوز SAML 2.0 پشتیبانی می‌شوند، استفاده کنید. پورتال کاربر سفارشی شما می تواند حداکثر انعطاف پذیری را در نحوه مدیریت و نمایش برنامه های کاربردی کاربر داشته باشد. به عنوان مثال، پورتال کاربر می تواند برخی از ابرداده های پروژه ML را برای تسهیل شناسایی یک برنامه کاربردی برای دسترسی نشان دهد.

می توانید کد منبع راه حل را در ما پیدا کنید مخزن GitHub.

بررسی اجمالی راه حل

راه حل معماری زیر را پیاده سازی می کند.

اجزای اصلی معماری سطح بالا به شرح زیر است:

  1. ارائه دهنده هویت - کاربران و گروه ها در یک منبع هویت خارجی مدیریت می شوند، به عنوان مثال در Azure AD. تکالیف کاربر به گروه‌های AD مشخص می‌کند که یک کاربر خاص چه مجوزهایی دارد و به کدام تیم استودیو دسترسی دارد. منبع هویت باید با AWS SSO همگام شود.
  2. AWS SSO – AWS SSO کاربران SSO، مجموعه های مجوز SSO و برنامه ها را مدیریت می کند. این راه حل از یک برنامه SAML 2.0 سفارشی برای دسترسی به استودیو برای کاربران AWS SSO استفاده می کند. این راه حل همچنین از نگاشت ویژگی SAML برای پر کردن ادعای SAML با داده های مرتبط با دسترسی خاص، مانند شناسه کاربر و تیم کاربر، استفاده می کند. از آنجایی که راه حل یک SAML API ایجاد می کند، می توانید از هر IdP که از اظهارات SAML پشتیبانی می کند برای ایجاد این معماری استفاده کنید. به عنوان مثال، می توانید از Okta یا حتی برنامه وب خود استفاده کنید که صفحه فرود را با پورتال کاربر و برنامه های کاربردی ارائه می دهد. برای این پست، ما از AWS SSO استفاده می کنیم.
  3. برنامه های کاربردی SAML 2.0 سفارشی – این راه حل برای هر تیم استودیو یک برنامه ایجاد می کند و یک یا چند برنامه را بر اساس حقوق به یک کاربر یا یک گروه کاربری اختصاص می دهد. کاربران می توانند از داخل پورتال کاربر AWS SSO خود بر اساس مجوزهای اختصاص داده شده به این برنامه ها دسترسی داشته باشند. هر برنامه با پیکربندی شده است دروازه API آمازون URL نقطه پایانی به عنوان باطن SAML آن.
  4. دامنه SageMaker – این راه حل یک دامنه SageMaker را در یک حساب AWS فراهم می کند و یک پروفایل کاربری اختصاصی برای هر ترکیبی از کاربر AWS SSO و تیم استودیو که کاربر به آن اختصاص داده می شود ایجاد می کند. دامنه باید در IAM پیکربندی شود حالت تأیید اعتبار.
  5. پروفایل کاربران استودیو - راه حل به طور خودکار یک پروفایل کاربری اختصاصی برای هر ترکیب کاربر-تیم ایجاد می کند. به عنوان مثال، اگر یک کاربر عضو دو تیم استودیو باشد و مجوزهای مربوطه را داشته باشد، راه حل دو نمایه کاربری مجزا را برای این کاربر فراهم می کند. هر پروفایل همیشه متعلق به یک و تنها یک کاربر است. از آنجایی که برای هر ترکیب ممکن از یک کاربر و یک تیم، یک نمایه کاربری استودیو دارید، باید قبل از اجرای این رویکرد، محدودیت‌های حساب کاربری خود را برای پروفایل‌های کاربر در نظر بگیرید. به عنوان مثال، اگر محدودیت شما 500 پروفایل کاربر باشد و هر کاربر عضو دو تیم باشد، این محدودیت را 2.5 برابر سریعتر مصرف می کنید و در نتیجه می توانید 250 کاربر را وارد کنید. با تعداد کاربران زیاد، توصیه می کنیم چندین دامنه و حساب را برای جداسازی زمینه امنیتی پیاده سازی کنید. برای نشان دادن اثبات مفهوم، از دو کاربر، کاربر 1 و کاربر 2، و دو تیم استودیو، تیم 1 و تیم 2 استفاده می‌کنیم. کاربر 1 متعلق به هر دو تیم است، در حالی که کاربر 2 فقط به تیم 2 تعلق دارد. کاربر 1 می تواند به محیط های استودیو برای هر دو تیم دسترسی داشته باشد، در حالی که کاربر 2 می تواند فقط به محیط استودیو برای تیم 2 دسترسی داشته باشد.
  6. نقش های اجرایی استودیو - هر پروفایل کاربری استودیو از یک نقش اجرایی اختصاصی با قوانین مجوز با سطح دسترسی لازم برای تیم خاصی که کاربر به آن تعلق دارد استفاده می کند. نقش‌های اجرای استودیو یک جداسازی مجوز مؤثر بین کاربران فردی و نقش‌های تیمی آنها را پیاده‌سازی می‌کنند. شما دسترسی به داده ها و منابع را برای هر نقش و نه در سطح یک کاربر مدیریت می کنید.

این راه حل همچنین یک کنترل دسترسی مبتنی بر ویژگی (ABAC) را با استفاده از ویژگی های SAML 2.0، برچسب ها در پروفایل های کاربر Studio، و برچسب ها در نقش های اجرایی SageMaker پیاده سازی می کند.

در این پیکربندی خاص، فرض می‌کنیم که کاربران AWS SSO مجوز ورود به حساب AWS را ندارند و نقش‌های IAM تحت کنترل AWS SSO را در حساب ندارند. هر کاربر از طریق یک URL از پیش تعیین شده از پورتال AWS SSO بدون نیاز به رفتن به کنسول در حساب AWS خود وارد محیط استودیو خود می شود. در یک محیط واقعی، ممکن است نیاز به راه اندازی داشته باشید مجموعه های مجوز AWS SSO برای کاربران اجازه می دهد تا کاربران مجاز نقش IAM را بر عهده بگیرند و به یک حساب AWS وارد شوند. به عنوان مثال، شما می توانید مجوزهای نقش دانشمند داده را برای کاربر فراهم کنید تا بتواند با منابع حساب تعامل داشته باشد و سطح دسترسی مورد نیاز برای ایفای نقش خود را داشته باشد.

معماری راه حل و گردش کار

نمودار زیر جریان ورود به سیستم را برای یک کاربر AWS SSO نشان می‌دهد.

یک کاربر AWS SSO یک برنامه استودیو مربوطه را در پورتال AWS SSO خود انتخاب می کند. AWS SSO یک ادعای SAML (1) را با نگاشت ویژگی SAML پیکربندی شده آماده می کند. یک برنامه SAML سفارشی با URL نقطه پایانی API Gateway به عنوان خدمات مصرف کننده ادعایی (ACS) پیکربندی شده است و به ویژگی های نقشه برداری حاوی شناسه کاربر AWS SSO و شناسه تیم نیاز دارد. ما استفاده می کنیم ssouserid و teamid ویژگی های سفارشی برای ارسال تمام اطلاعات مورد نیاز به باطن SAML.

دروازه API یک API پشتیبان SAML را فراخوانی می کند. یک AWS لامبدا تابع (2) API را پیاده سازی می کند، پاسخ SAML را برای استخراج شناسه کاربر و شناسه تیم تجزیه می کند. این تابع از آنها برای بازیابی یک پیکربندی خاص تیم مانند یک نقش اجرایی و شناسه دامنه SageMaker استفاده می کند. این تابع بررسی می‌کند که آیا یک نمایه کاربر مورد نیاز در دامنه وجود دارد یا خیر، و اگر پروفایلی وجود نداشته باشد، یک پروفایل جدید با تنظیمات پیکربندی مربوطه ایجاد می‌کند. پس از آن، این تابع با فراخوانی یک URL تعیین شده استودیو برای یک نمایه کاربر خاص استودیو ایجاد می کند CreatePresignedDomainUrl API (3) از طریق یک نقطه پایانی SageMaker API VPC. تابع Lambda در نهایت URL تعیین شده را با پاسخ تغییر مسیر HTTP 302 برای ورود کاربر به استودیو برمی گرداند.

راه حل یک نسخه نمونه غیر تولیدی از یک باطن SAML را پیاده سازی می کند. تابع Lambda ادعای SAML را تجزیه می کند و فقط از ویژگی ها در آن استفاده می کند <saml2:AttributeStatement> عنصر برای ساختن a CreatePresignedDomainUrl تماس API. در راه حل تولید خود، باید از پیاده سازی پشتیبان SAML مناسب استفاده کنید، که باید شامل اعتبار سنجی پاسخ SAML، امضا، و گواهی ها، جلوگیری از پخش مجدد و تغییر مسیر، و سایر ویژگی های فرآیند احراز هویت SAML باشد. برای مثال می توانید از a استفاده کنید پیاده سازی باطن python3-saml SAML or جعبه ابزار SAML منبع باز OneLogin برای پیاده سازی یک باطن SAML امن.

ایجاد پویا پروفایل های کاربری استودیو

این راه حل به طور خودکار یک نمایه کاربر استودیو برای هر ترکیب کاربر-تیم ایجاد می کند، به محض اینکه فرآیند ورود به سیستم 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. نقش اجرای استودیو - نمایه کاربر استودیو از یک نقش اجرای اختصاصی استودیو با مجوزهای داده و منابع خاص برای هر تیم یا گروه کاربری استفاده می کند. این نقش همچنین می تواند از برچسب ها برای پیاده سازی ABAC برای دسترسی به داده ها و منابع استفاده کند. برای اطلاعات بیشتر مراجعه کنید نقش های SageMaker.
  2. نقش اجرای پشتیبان SAML Lambda – این نقش اجرایی حاوی مجوز فراخوانی است CreatePresignedDomainUrl API. می‌توانید خط‌مشی مجوز را طوری پیکربندی کنید که بررسی‌های مشروط اضافی را با استفاده از آن شامل شود Condition کلیدها به عنوان مثال، برای اجازه دسترسی به استودیو فقط از محدوده مشخصی از آدرس‌های 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 در سازمان شما. برای مثال، برای جلوگیری از دسترسی مرکزی به استودیو از طریق کنسول، می‌توانید SCP زیر را پیاده‌سازی کنید و آن را به حساب‌های دارای دامنه SageMaker متصل کنید: 
    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "sagemaker:*"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Condition": {
        "NotIpAddress": {
          "aws:VpcSourceIp": "<AuthorizedPrivateSubnet>"
        }
      },
      "Action": [
        "sagemaker:CreatePresignedDomainUrl"
      ],
      "Resource": "*",
      "Effect": "Deny"
    }
  ]
}

نقش های ارائه شده راه حل

La AWS CloudFormation پشته برای این راه حل، سه نقش اجرای Studio مورد استفاده در دامنه SageMaker ایجاد می کند:

  • SageMakerStudioExecutionRoleDefault
  • SageMakerStudioExecutionRoleTeam1
  • SageMakerStudioExecutionRoleTeam2

هیچ کدام از نقش ها این را ندارند AmazonSageMakerFullAccess خط مشی ضمیمه شده است و هرکدام فقط مجموعه محدودی از مجوزها را دارند. در محیط واقعی SageMaker خود، باید مجوزهای نقش را بر اساس نیازهای خاص خود اصلاح کنید.

SageMakerStudioExecutionRoleDefault فقط سیاست سفارشی را دارد SageMakerReadOnlyPolicy به همراه فهرست محدودی از اقدامات مجاز پیوست شده است.

هر دو نقش تیمی، SageMakerStudioExecutionRoleTeam1 و SageMakerStudioExecutionRoleTeam2، علاوه بر این دارای دو سیاست سفارشی است، SageMakerAccessSupportingServicesPolicy و SageMakerStudioDeveloperAccessPolicy، اجازه استفاده از خدمات خاص و یک خط مشی فقط انکار، SageMakerDeniedServicesPolicy، با رد صریح برخی از تماس های SageMaker API.

خط‌مشی دسترسی توسعه‌دهنده استودیو تنظیم را اعمال می‌کند 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"
}

علاوه بر این، استفاده از عملیات حذف، توقف، به‌روزرسانی و شروع را فقط در منابعی که با همان تگ Team برچسب‌گذاری شده‌اند، به عنوان نقش اجرایی کاربر امکان‌پذیر می‌کند:

{
    "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 برای کنترل ترافیک بین تمام اجزای راه حل مانند تابع پشتیبان SAML Lambda، نقاط پایانی VPC، و نوت بوک های استودیویی

برای اثبات مفهوم و سادگی، راه حل یک زیرشبکه SageMaker را در یک واحد ایجاد می کند منطقه در دسترس بودن. برای تنظیم تولید خود، باید از چندین زیرشبکه خصوصی در چندین منطقه دسترسی استفاده کنید و اطمینان حاصل کنید که هر زیرشبکه اندازه مناسبی دارد، با فرض حداقل پنج IP برای هر کاربر.

این راه حل تمام زیرساخت های شبکه مورد نیاز را فراهم می کند. قالب CloudFormation ./cfn-templates/vpc.yaml حاوی کد منبع

مراحل استقرار

برای استقرار و آزمایش راه حل، باید مراحل زیر را انجام دهید:

  1. پشته راه حل را از طریق an مستقر کنید مدل برنامه بدون سرور AWS قالب (AWS SAM).
  2. کاربران AWS SSO ایجاد کنید یا از کاربران موجود AWS SSO استفاده کنید.
  3. برنامه های SAML 2.0 سفارشی ایجاد کنید و کاربران AWS SSO را به برنامه ها اختصاص دهید.

کد منبع کامل راه حل در GitHub ما ارائه شده است مخزن.

پیش نیازها

برای استفاده از این محلول، رابط خط فرمان AWS (AWS CLI)، AWS SAM CLIو پایتون 3.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 اگر نیاز به تغییر تنظیمات پیش‌فرض دارید، فایل را ثبت کنید.

صبر کنید تا استقرار پشته کامل شود. استقرار انتها به انتها شامل تهیه تمام منابع شبکه و دامنه 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، آدرس ارائه شده در را وارد کنید SAMLBackendEndpoint کلید خروجی پشته AWS SAM.
  9. برای مخاطبان برنامه SAML، آدرس ارائه شده در را وارد کنید SAMLAudience کلید خروجی پشته AWS SAM.
  10. را انتخاب کنید ذخیره تغییرات.
  11. حرکت به نگاشت ویژگی ها تب.
  12. تنظیم کنید موضوع به پست الکترونیک و قالب به آدرس ایمیل.
  13. ویژگی های جدید زیر را اضافه کنید:
    1. ssouserid مجموعه را به ${user:AD_GUID}
    2. teamid مجموعه را به Team1 or Team2به ترتیب برای هر برنامه
  14. را انتخاب کنید ذخیره تغییرات.
  15. بر کاربران اختصاص داده شده برگه ، انتخاب کنید کاربران را اختصاص دهید.
  16. کاربر 1 را برای برنامه تیم 1 و کاربر 1 و کاربر 2 را برای برنامه تیم 2 انتخاب کنید.
  17. را انتخاب کنید کاربران را اختصاص دهید.

محلول را تست کنید

برای آزمایش راه حل، مراحل زیر را انجام دهید:

  1. به پورتال کاربر AWS SSO بروید https://<Identity Store ID>.awsapps.com/start و به عنوان کاربر 1 امضا کنید.
    دو برنامه SageMaker در پورتال نشان داده شده است.
  2. را انتخاب کنید تیم SageMaker Studio 1.
    شما در یک پنجره مرورگر جدید به نمونه استودیو برای تیم 1 هدایت می شوید.
    اولین باری که استودیو را راه اندازی می کنید، SageMaker یک برنامه JupyterServer ایجاد می کند. این فرآیند چند دقیقه طول می کشد.
  3. در استودیو، در پرونده منو ، انتخاب کنید جدید و پایانه برای راه اندازی ترمینال جدید
  4. در خط فرمان ترمینال، دستور زیر را وارد کنید: 
    aws sts get-caller-identity

    دستور نقش اجرای Studio را برمی گرداند.

    در تنظیمات ما، این نقش باید برای هر تیم متفاوت باشد. همچنین می‌توانید بررسی کنید که هر کاربر در هر نمونه از استودیو دایرکتوری اصلی خود را در یک حجم آمازون EFS نصب شده دارد.

  5. به پورتال AWS SSO که هنوز به عنوان کاربر 1 وارد شده است، بازگردید و انتخاب کنید تیم SageMaker Studio 2.
    شما به یک نمونه استودیوی تیم 2 هدایت می شوید.
    روند شروع دوباره می تواند چندین دقیقه طول بکشد، زیرا SageMaker یک برنامه جدید JupyterServer را برای کاربر 2 راه اندازی می کند.
  6. به عنوان کاربر 2 در پورتال AWS SSO وارد شوید.
    کاربر 2 تنها یک برنامه اختصاص داده است: SageMaker Studio Team 2.

اگر نمونه‌ای از استودیو را از طریق این برنامه کاربری راه‌اندازی کنید، می‌توانید تأیید کنید که از همان نقش اجرای SageMaker به عنوان نمونه تیم 1 کاربر 2 استفاده می‌کند. با این حال، هر نمونه Studio کاملاً ایزوله است. کاربر 2 فهرست اصلی خود را در حجم EFS آمازون و نمونه ای از برنامه JupyterServer دارد. شما می توانید این موضوع را با ایجاد یک پوشه و چند فایل برای هر یک از کاربران تأیید کنید و ببینید که فهرست اصلی هر کاربر ایزوله است.

اکنون می توانید وارد کنسول SageMaker شوید و ببینید که سه پروفایل کاربری ایجاد شده است.

شما به تازگی یک راه حل مفهومی اثباتی را برای مدیریت چندین کاربر و تیم با استودیو پیاده سازی کرده اید.

پاک کردن

برای اجتناب از هزینه، باید تمام منابع تهیه شده و تولید شده توسط پروژه را از حساب AWS خود حذف کنید. از دستور SAM CLI زیر برای حذف پشته راه حل CloudFormation استفاده کنید:

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

به دلایل امنیتی و برای جلوگیری از از دست رفتن داده ها، مانت EFS Amazon و محتوای مرتبط با دامنه Studio مستقر در این راه حل حذف نمی شوند. VPC و زیرشبکه های مرتبط با دامنه SageMaker در حساب AWS شما باقی می مانند. برای دستورالعمل های مربوط به حذف سیستم فایل و VPC، مراجعه کنید حذف یک سیستم فایل آمازون EFS و با VPC ها کار کنیدبود.

برای حذف برنامه SAML سفارشی، مراحل زیر را انجام دهید:

  1. کنسول AWS SSO را در حساب مدیریتی AWS SSO باز کنید.
  2. را انتخاب کنید اپلیکیشن‌ها.
  3. انتخاب کنید تیم SageMaker Studio 1.
  4. بر اعمال منو ، انتخاب کنید برداشتن.
  5. این مراحل را برای تیم SageMaker Studio 2.

نتیجه

این راه حل نشان داد که چگونه می توانید یک محیط انعطاف پذیر و قابل تنظیم با استفاده از پروفایل های کاربر AWS SSO و Studio برای پشتیبانی از ساختار سازمانی خود ایجاد کنید. گام‌های بهبود احتمالی بعدی به سمت یک راه‌حل آماده تولید می‌تواند موارد زیر باشد:

  • پیاده سازی خودکار مدیریت پروفایل کاربر استودیو به عنوان یک میکروسرویس اختصاصی برای پشتیبانی از یک گردش کار تهیه پروفایل خودکار و مدیریت فراداده و پیکربندی برای پروفایل های کاربر، به عنوان مثال در آمازون DynamoDB.
  • از مکانیسم یکسانی در یک مورد کلی تر از چندین دامنه SageMaker و چندین حساب AWS استفاده کنید. همان پشتیبان SAML می‌تواند یک URL از پیش تعیین شده مربوطه را با توجه به منطق سفارشی شما بر اساس حقوق کاربر و راه‌اندازی تیم، به یک ترکیب نمایه کاربر-دامنه-حساب هدایت کند.
  • یک مکانیسم همگام سازی بین IdP و AWS SSO خود را اجرا کنید و ایجاد خودکار برنامه های SAML 2.0 سفارشی را انجام دهید.
  • پیاده سازی داده های مقیاس پذیر و مدیریت دسترسی به منابع با کنترل دسترسی مبتنی بر ویژگی (ABAC).

اگر بازخورد یا سوالی دارید، لطفاً آنها را در نظرات مطرح کنید.

مطالعه بیشتر

مستندات

پست های وبلاگ

درباره نویسنده

یوگنی ایلین یک معمار راه حل در AWS است. او بیش از 20 سال تجربه کار در تمام سطوح توسعه نرم افزار و معماری راه حل ها را دارد و از زبان های برنامه نویسی از COBOL و Assembler گرفته تا دات نت، جاوا و پایتون استفاده کرده است. او راه حل های بومی ابری را با تمرکز بر داده های بزرگ، تجزیه و تحلیل و مهندسی داده توسعه و کدگذاری می کند.

نقطه_img

جدیدترین اطلاعات

نقطه_img

حق چاپ @ 2024 Plato Technologies Inc.

چت با ما

سلام! چگونه می توانم به شما کمک کنم؟