Quản lý nhóm và người dùng với Amazon SageMaker và AWS SSO

Xưởng sản xuất Amazon SageMaker là một môi trường phát triển tích hợp dựa trên web (IDE) dành cho học máy (ML) cho phép bạn xây dựng, đào tạo, gỡ lỗi, triển khai và giám sát các mô hình ML của mình. Mỗi người dùng tham gia trong Studio đều có bộ tài nguyên dành riêng của họ, chẳng hạn như phiên bản máy tính, thư mục chính trên một Hệ thống tệp đàn hồi Amazon (Amazon EFS) và một Quản lý truy cập và nhận dạng AWS (IAM) vai trò thực thi.

Một trong những thách thức phổ biến nhất trong thế giới thực khi thiết lập quyền truy cập của người dùng cho Studio là cách quản lý nhiều người dùng, nhóm và nhóm khoa học dữ liệu để truy cập dữ liệu và cách ly tài nguyên.

Nhiều khách hàng triển khai quản lý người dùng bằng cách sử dụng danh tính được liên kết với Đăng nhập một lần AWS (AWS SSO) và nhà cung cấp danh tính bên ngoài (IdP), chẳng hạn như Active Directory (AD) hoặc thư mục AWS Managed Microsoft AD. Nó phù hợp với AWS Đề nghị thực hành sử dụng thông tin đăng nhập tạm thời để truy cập tài khoản AWS.

An Amazon SageMaker miền hỗ trợ AWS SSO và có thể được định cấu hình trong AWS SSO chế độ xác thực. Trong trường hợp này, mỗi người dùng AWS SSO có quyền có Hồ sơ người dùng Studio. Người dùng được cấp quyền truy cập vào Studio có một URL đăng nhập duy nhất trực tiếp mở Studio và họ đăng nhập bằng thông tin đăng nhập AWS SSO của mình. Các tổ chức quản lý người dùng của họ trong AWS SSO thay vì miền SageMaker. Bạn có thể chỉ định nhiều người dùng quyền truy cập vào miền cùng một lúc. Bạn có thể sử dụng hồ sơ người dùng Studio cho từng người dùng để xác định quyền bảo mật của họ trong sổ ghi chép Studio thông qua vai trò IAM được đính kèm với hồ sơ người dùng, được gọi là vai trò thực hiện. Vai trò này kiểm soát quyền đối với các hoạt động của SageMaker theo chính sách cấp phép IAM của nó.

Trong chế độ xác thực AWS SSO, luôn có ánh xạ XNUMX-XNUMX giữa người dùng và hồ sơ người dùng. Miền SageMaker quản lý việc tạo hồ sơ người dùng dựa trên ID người dùng AWS SSO. Bạn không thể tạo hồ sơ người dùng thông qua Bảng điều khiển quản lý AWS. Điều này hoạt động tốt trong trường hợp một người dùng chỉ là thành viên của một nhóm khoa học dữ liệu hoặc nếu người dùng có các yêu cầu truy cập giống nhau hoặc rất giống nhau trong các dự án và nhóm của họ. Trong một trường hợp sử dụng phổ biến hơn, khi người dùng có thể tham gia vào nhiều dự án ML và là thành viên của nhiều nhóm với các yêu cầu quyền hơi khác nhau, người dùng yêu cầu quyền truy cập vào các hồ sơ người dùng Studio khác nhau với các vai trò thực thi và chính sách quyền khác nhau. Vì bạn không thể quản lý hồ sơ người dùng độc lập với AWS SSO trong chế độ xác thực AWS SSO, nên bạn không thể triển khai ánh xạ một-nhiều giữa người dùng và hồ sơ người dùng Studio.

Nếu bạn cần thiết lập sự tách biệt rõ ràng về bối cảnh bảo mật, chẳng hạn như đối với các danh mục dữ liệu khác nhau hoặc cần ngăn chặn hoàn toàn khả năng hiển thị của một nhóm hoạt động và tài nguyên của người dùng với nhóm khác, thì phương pháp được đề xuất là tạo nhiều miền SageMaker. Tại thời điểm viết bài này, bạn chỉ có thể tạo một miền cho mỗi tài khoản AWS cho mỗi Khu vực. Để thực hiện sự phân tách mạnh mẽ, bạn có thể sử dụng nhiều tài khoản AWS với một miền cho mỗi tài khoản như một giải pháp.

Thách thức thứ hai là hạn chế quyền truy cập vào IDE Studio chỉ cho người dùng từ bên trong mạng công ty hoặc VPC được chỉ định. Bạn có thể đạt được điều này bằng cách sử dụng Chính sách kiểm soát truy cập dựa trên IAM. Trong trường hợp này, miền SageMaker phải được định cấu hình với Chế độ xác thực IAM, vì các chính sách dựa trên danh tính IAM không được cơ chế đăng nhập ở chế độ AWS SSO hỗ trợ. Bài Truy cập an toàn vào Amazon SageMaker Studio với AWS SSO và ứng dụng SAML giải quyết thách thức này và trình bày cách kiểm soát quyền truy cập mạng vào miền SageMaker.

Giải pháp này giải quyết những thách thức về quản lý người dùng AWS SSO cho Studio đối với trường hợp sử dụng chung của nhiều nhóm người dùng và ánh xạ nhiều đến nhiều giữa người dùng và nhóm. Giải pháp phác thảo cách sử dụng ứng dụng SAML 2.0 tùy chỉnh làm cơ chế để kích hoạt xác thực người dùng cho Studio và hỗ trợ nhiều hồ sơ người dùng Studio cho mỗi người dùng AWS SSO.

Bạn có thể sử dụng phương pháp này để triển khai cổng người dùng tùy chỉnh với các ứng dụng được hỗ trợ bởi quy trình ủy quyền SAML 2.0. Cổng thông tin người dùng tùy chỉnh của bạn có thể có tính linh hoạt tối đa về cách quản lý và hiển thị các ứng dụng của người dùng. Ví dụ: cổng thông tin người dùng có thể hiển thị một số siêu dữ liệu dự án ML để tạo điều kiện xác định một ứng dụng để truy cập.

Bạn có thể tìm thấy mã nguồn của giải pháp trong Kho GitHub.

Tổng quan về giải pháp

Giải pháp thực hiện kiến ​​trúc sau đây.

Các thành phần kiến ​​trúc cấp cao chính như sau:

1. Nhà cung cấp danh tính - Người dùng và nhóm được quản lý trong một nguồn nhận dạng bên ngoài, ví dụ như trong Azure AD. Việc chỉ định của người dùng cho các nhóm AD xác định những quyền mà một người dùng cụ thể có và nhóm Studio nào họ có quyền truy cập. Nguồn nhận dạng phải được đồng bộ hóa với AWS SSO.
2. AWS SSO - AWS SSO quản lý người dùng SSO, bộ quyền SSO và ứng dụng. Giải pháp này sử dụng ứng dụng SAML 2.0 tùy chỉnh để cung cấp quyền truy cập vào Studio cho người dùng AWS SSO có quyền. Giải pháp cũng sử dụng ánh xạ thuộc tính SAML để điền xác nhận SAML với dữ liệu liên quan đến quyền truy cập cụ thể, chẳng hạn như ID người dùng và nhóm người dùng. Vì giải pháp tạo API SAML nên bạn có thể sử dụng bất kỳ xác nhận SAML nào hỗ trợ IdP để tạo kiến ​​trúc này. Ví dụ: bạn có thể sử dụng Okta hoặc thậm chí ứng dụng web của riêng bạn cung cấp trang đích với cổng người dùng và các ứng dụng. Đối với bài đăng này, chúng tôi sử dụng AWS SSO.
3. Các ứng dụng SAML 2.0 tùy chỉnh - Giải pháp tạo một ứng dụng cho mỗi nhóm Studio và chỉ định một hoặc nhiều ứng dụng cho một người dùng hoặc một nhóm người dùng dựa trên các quyền. Người dùng có thể truy cập các ứng dụng này từ bên trong cổng người dùng AWS SSO của họ dựa trên các quyền được chỉ định. Mỗi ứng dụng được định cấu hình với Cổng API Amazon URL điểm cuối làm phụ trợ SAML của nó.
4. Miền SageMaker - Giải pháp cung cấp miền SageMaker trong tài khoản AWS và tạo hồ sơ người dùng riêng cho từng tổ hợp người dùng AWS SSO và nhóm Studio mà người dùng được chỉ định. Miền phải được định cấu hình trong IAM chế độ xác thực.
5. Hồ sơ người dùng Studio - Giải pháp tự động tạo hồ sơ người dùng dành riêng cho từng tổ hợp người dùng-nhóm. Ví dụ: nếu người dùng là thành viên của hai nhóm Studio và có quyền tương ứng, giải pháp cung cấp hai hồ sơ người dùng riêng biệt cho người dùng này. Mỗi hồ sơ luôn thuộc về một và chỉ một người dùng. Vì bạn có hồ sơ người dùng Studio cho từng kết hợp có thể có giữa người dùng và một nhóm, nên bạn phải xem xét giới hạn tài khoản của mình cho hồ sơ người dùng trước khi triển khai phương pháp này. Ví dụ: nếu giới hạn của bạn là 500 hồ sơ người dùng và mỗi người dùng là thành viên của hai nhóm, bạn sử dụng giới hạn đó nhanh hơn 2.5 lần và kết quả là bạn có thể giới thiệu 250 người dùng. Với số lượng người dùng cao, chúng tôi khuyên bạn nên triển khai nhiều miền và tài khoản để phân tách ngữ cảnh bảo mật. Để chứng minh bằng chứng về khái niệm, chúng tôi sử dụng hai người dùng, Người dùng 1 và Người dùng 2, và hai nhóm Studio, Nhóm 1 và Nhóm 2. Người dùng 1 thuộc cả hai nhóm, trong khi Người dùng 2 chỉ thuộc về Nhóm 2. Người dùng 1 có thể truy cập môi trường Studio cho cả hai nhóm, trong khi Người dùng 2 chỉ có thể truy cập môi trường Studio cho Nhóm 2.
6. Các vai trò thực hiện studio - Mỗi hồ sơ người dùng Studio sử dụng một vai trò thực thi riêng với các chính sách cấp quyền với mức độ truy cập bắt buộc cho nhóm cụ thể mà người dùng thuộc về. Các vai trò thực thi trong studio thực hiện sự cô lập quyền hiệu quả giữa người dùng cá nhân và vai trò nhóm của họ. Bạn quản lý dữ liệu và quyền truy cập tài nguyên cho từng vai trò chứ không phải ở cấp người dùng cá nhân.

Giải pháp cũng triển khai kiểm soát truy cập dựa trên thuộc tính (ABAC) bằng cách sử dụng các thuộc tính SAML 2.0, thẻ trên hồ sơ người dùng Studio và thẻ trên vai trò thực thi SageMaker.

Trong cấu hình cụ thể này, chúng tôi giả định rằng người dùng AWS SSO không có quyền đăng nhập vào tài khoản AWS và không có vai trò IAM do AWS SSO kiểm soát tương ứng trong tài khoản. Mỗi người dùng đăng nhập vào môi trường Studio của họ thông qua URL được chỉ định trước từ cổng AWS SSO mà không cần truy cập bảng điều khiển trong tài khoản AWS của họ. Trong môi trường thế giới thực, bạn có thể cần thiết lập Bộ quyền AWS SSO để người dùng cho phép người dùng được ủy quyền đảm nhận vai trò IAM và đăng nhập vào tài khoản AWS. Ví dụ: bạn có thể cung cấp quyền vai trò nhà khoa học dữ liệu để người dùng có thể tương tác với các tài nguyên tài khoản và có mức độ truy cập mà họ cần để thực hiện vai trò của mình.

Kiến trúc giải pháp và quy trình làm việc

Sơ đồ sau đây trình bày quy trình đăng nhập end-to-end cho người dùng AWS SSO.

Người dùng AWS SSO chọn một ứng dụng Studio tương ứng trong cổng AWS SSO của họ. AWS SSO chuẩn bị xác nhận SAML (1) với ánh xạ thuộc tính SAML đã định cấu hình. Ứng dụng SAML tùy chỉnh được định cấu hình với URL điểm cuối API Gateway làm Dịch vụ người tiêu dùng xác nhận (ACS) và cần các thuộc tính ánh xạ có chứa ID người dùng AWS SSO và ID nhóm. Chúng tôi sử dụng ssouserid và teamid các thuộc tính tùy chỉnh để gửi tất cả thông tin cần thiết đến phần phụ trợ SAML.

API Gateway gọi một API phụ trợ SAML. Một AWS Lambda hàm (2) triển khai API, phân tích cú pháp phản hồi SAML để trích xuất ID người dùng và ID nhóm. Hàm sử dụng chúng để truy xuất cấu hình dành riêng cho nhóm, chẳng hạn như vai trò thực thi và ID miền SageMaker. Chức năng kiểm tra xem hồ sơ người dùng được yêu cầu có tồn tại trong miền hay không và tạo một hồ sơ mới với cài đặt cấu hình tương ứng nếu không có hồ sơ nào tồn tại. Sau đó, chức năng tạo một URL được chỉ định sẵn trong Studio cho một hồ sơ người dùng Studio cụ thể bằng cách gọi TạoPresignedDomainUrl API (3) thông qua điểm cuối SageMaker API VPC. Hàm Lambda cuối cùng trả về URL được chỉ định trước với phản hồi chuyển hướng HTTP 302 để người dùng đăng nhập vào Studio.

Giải pháp triển khai phiên bản mẫu phi sản xuất của chương trình phụ trợ SAML. Hàm Lambda phân tích cú pháp xác nhận SAML và chỉ sử dụng các thuộc tính trong <saml2:AttributeStatement> yếu tố để xây dựng một CreatePresignedDomainUrl Lệnh gọi API. Trong giải pháp sản xuất của mình, bạn phải sử dụng triển khai phụ trợ SAML thích hợp, phải bao gồm xác thực phản hồi SAML, chữ ký và chứng chỉ, ngăn chặn phát lại và chuyển hướng cũng như bất kỳ tính năng nào khác của quy trình xác thực SAML. Ví dụ, bạn có thể sử dụng Triển khai chương trình phụ trợ SAML python3-saml or Bộ công cụ SAML mã nguồn mở OneLogin để triển khai chương trình phụ trợ SAML an toàn.

Tạo động các hồ sơ người dùng Studio

Giải pháp tự động tạo hồ sơ người dùng Studio cho từng tổ hợp người dùng-nhóm, ngay khi quy trình đăng nhập AWS SSO yêu cầu URL được chỉ định trước. Để có bằng chứng về khái niệm và sự đơn giản này, giải pháp tạo hồ sơ người dùng dựa trên siêu dữ liệu đã định cấu hình trong AWS Mẫu 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

Bạn có thể định cấu hình các nhóm, cài đặt tùy chỉnh và thẻ của riêng mình bằng cách thêm chúng vào cấu hình siêu dữ liệu cho tài nguyên AWS CloudFormation GetUserProfileMetadata.

Để biết thêm thông tin về các phần tử cấu hình của UserSettings, tham khảo create_user_profile trong boto3.

Vai trò IAM

Sơ đồ sau đây cho thấy các vai trò IAM trong giải pháp này.

Các vai trò như sau:

1. Vai trò thực hiện studio - Hồ sơ người dùng Studio sử dụng vai trò thực thi Studio chuyên dụng với dữ liệu và quyền tài nguyên cụ thể cho từng nhóm hoặc nhóm người dùng. Vai trò này cũng có thể sử dụng các thẻ để triển khai ABAC để truy cập dữ liệu và tài nguyên. Để biết thêm thông tin, hãy tham khảo Vai trò của SageMaker.
2. Vai trò thực thi Lambda phụ trợ SAML - Vai trò thực thi này chứa quyền gọi CreatePresignedDomainUrl API. Bạn có thể định cấu hình chính sách quyền để bao gồm các kiểm tra có điều kiện bổ sung bằng cách sử dụng Condition chìa khóa. Ví dụ: để chỉ cho phép truy cập vào Studio từ một dải địa chỉ IP được chỉ định trong mạng công ty riêng của bạn, hãy sử dụng mã sau:

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

   Để biết thêm ví dụ về cách sử dụng các điều kiện trong chính sách IAM, hãy tham khảo Kiểm soát quyền truy cập vào API SageMaker bằng cách sử dụng các chính sách dựa trên danh tính.

3. SageMaker - SageMaker đảm nhận vai trò thực thi Studio thay mặt bạn, như được kiểm soát bởi một chính sách tin cậy tương ứng về vai trò thực thi. Điều này cho phép dịch vụ truy cập dữ liệu và tài nguyên và thực hiện các hành động thay mặt bạn. Vai trò thực thi Studio phải chứa chính sách tin cậy cho phép SageMaker đảm nhận vai trò này.
4. Quyền AWS SSO đặt vai trò IAM - Bạn có thể chỉ định người dùng AWS SSO của mình cho các tài khoản AWS trong tổ chức AWS của bạn thông qua Bộ quyền AWS SSO. Tập hợp quyền là một mẫu xác định tập hợp các chính sách IAM dành riêng cho vai trò của người dùng. Bạn quản lý các bộ quyền trong AWS SSO và AWS SSO kiểm soát các vai trò IAM tương ứng trong mỗi tài khoản.
5. Chính sách kiểm soát dịch vụ của các tổ chức AWS - Nếu bạn dùng Tổ chức AWS, bạn có thể thực hiện Chính sách kiểm soát dịch vụ (SCP) để kiểm soát tập trung các quyền tối đa có sẵn cho tất cả các tài khoản và tất cả các vai trò IAM trong tổ chức của bạn. Ví dụ: để ngăn chặn tập trung quyền truy cập vào Studio thông qua bảng điều khiển, bạn có thể triển khai SCP sau và đính kèm nó vào các tài khoản có miền SageMaker:

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

Các vai trò được cung cấp giải pháp

Sản phẩm Hình thành đám mây AWS ngăn xếp đối với giải pháp này, tạo ra ba vai trò thực thi Studio được sử dụng trong miền SageMaker:

• SageMakerStudioExecutionRoleDefault
• SageMakerStudioExecutionRoleTeam1
• SageMakerStudioExecutionRoleTeam2

Không có vai trò nào có AmazonSageMakerTruy cập đầy đủ chính sách đính kèm và mỗi chính sách chỉ có một bộ quyền hạn chế. Trong môi trường SageMaker thế giới thực của bạn, bạn cần sửa đổi các quyền của vai trò dựa trên các yêu cầu cụ thể của bạn.

SageMakerStudioExecutionRoleDefault chỉ có chính sách tùy chỉnh SageMakerReadOnlyPolicy đính kèm với một danh sách hạn chế các hành động được phép.

Cả hai vai trò trong nhóm, SageMakerStudioExecutionRoleTeam1 và SageMakerStudioExecutionRoleTeam2, ngoài ra có hai chính sách tùy chỉnh, SageMakerAccessSupportingServicesPolicy và SageMakerStudioDeveloperAccessPolicy, cho phép sử dụng các dịch vụ cụ thể và một chính sách chỉ từ chối, SageMakerDeniedServicesPolicy, với sự từ chối rõ ràng đối với một số lệnh gọi API SageMaker.

Chính sách truy cập dành cho nhà phát triển Studio thực thi cài đặt của Team thẻ bằng cùng một giá trị với vai trò thực thi của chính người dùng để gọi bất kỳ SageMaker nào 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"
}

Hơn nữa, nó cho phép sử dụng thao tác xóa, dừng, cập nhật và bắt đầu chỉ trên các tài nguyên được gắn thẻ cùng một thẻ Nhóm với vai trò thực thi của người dùng:

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

Để biết thêm thông tin về vai trò và chính sách, tham khảo Định cấu hình Amazon SageMaker Studio cho các nhóm và nhóm với sự cô lập hoàn toàn về tài nguyên.

Cơ sở hạ tầng mạng

Giải pháp triển khai một môi trường miền SageMaker hoàn toàn biệt lập với tất cả lưu lượng mạng đi qua Liên kết riêng AWS kết nối. Bạn có thể tùy chọn kích hoạt truy cập internet từ máy tính xách tay Studio. Giải pháp cũng tạo ra ba Nhóm bảo mật VPC để kiểm soát lưu lượng giữa tất cả các thành phần giải pháp, chẳng hạn như hàm Lambda phụ trợ SAML, Điểm cuối VPC, và máy tính xách tay Studio.

Đối với bằng chứng về khái niệm và sự đơn giản này, giải pháp tạo ra một mạng con SageMaker trong một Vùng khả dụng. Đối với thiết lập sản xuất của mình, bạn phải sử dụng nhiều mạng con riêng trên nhiều Vùng khả dụng và đảm bảo rằng mỗi mạng con có kích thước phù hợp, giả sử tối thiểu năm IP cho mỗi người dùng.

Giải pháp này cung cấp tất cả cơ sở hạ tầng mạng cần thiết. Mẫu CloudFormation ./cfn-templates/vpc.yaml chứa mã nguồn.

Các bước triển khai

Để triển khai và kiểm tra giải pháp, bạn phải hoàn thành các bước sau:

1. Triển khai ngăn xếp của giải pháp thông qua một Mô hình ứng dụng không có máy chủ AWS (AWS SAM) mẫu.
2. Tạo người dùng AWS SSO hoặc sử dụng người dùng AWS SSO hiện có.
3. Tạo các ứng dụng SAML 2.0 tùy chỉnh và chỉ định người dùng AWS SSO cho các ứng dụng.

Mã nguồn đầy đủ cho giải pháp được cung cấp trong GitHub của chúng tôi kho.

Điều kiện tiên quyết

Để sử dụng giải pháp này, Giao diện dòng lệnh AWS (AWS CLI), AWS SAM CLIvà Python3.8 trở lên phải được cài đặt.

Quy trình triển khai giả định rằng bạn đã bật AWS SSO và định cấu hình cho Tổ chức AWS trong tài khoản nơi giải pháp được triển khai.

Để thiết lập AWS SSO, hãy tham khảo hướng dẫn trong GitHub.

Các tùy chọn triển khai giải pháp

Bạn có thể chọn từ một số tùy chọn triển khai giải pháp để phù hợp nhất với môi trường AWS hiện có của mình. Bạn cũng có thể chọn các tùy chọn cung cấp miền và mạng SageMaker. Để biết thông tin chi tiết về các lựa chọn triển khai khác nhau, hãy tham khảo Tệp README.

Triển khai mẫu AWS SAM

Để triển khai mẫu AWS SAM, hãy hoàn thành các bước sau:

1. Sao chép mã nguồn kho đến môi trường địa phương của bạn:

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

2. Xây dựng ứng dụng AWS SAM:
3. Triển khai ứng dụng:

   sam deploy --guided

4. Cung cấp các tham số ngăn xếp theo môi trường hiện tại của bạn và các tùy chọn triển khai mong muốn, chẳng hạn như VPC hiện có, mạng con riêng tư và công khai hiện có và miền SageMaker hiện có, như đã thảo luận trong Các tùy chọn triển khai giải pháp chương của tệp README.

Bạn có thể để tất cả các tham số ở giá trị mặc định của chúng để cung cấp tài nguyên mạng mới và miền SageMaker mới. Tham khảo cách sử dụng thông số chi tiết trong README nếu bạn cần thay đổi bất kỳ cài đặt mặc định nào.

Chờ cho đến khi việc triển khai ngăn xếp hoàn tất. Việc triển khai end-to-end bao gồm cung cấp tất cả tài nguyên mạng và miền SageMaker mất khoảng 20 phút.

Để xem đầu ra ngăn xếp, hãy chạy lệnh sau trong thiết bị đầu cuối:

export STACK_NAME=<SAM stack name>

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

Tạo người dùng SSO

Làm theo hướng dẫn để thêm người dùng AWS SSO để tạo hai người dùng có tên User1 và User2 hoặc sử dụng bất kỳ hai người dùng AWS SSO nào hiện có của bạn để thử nghiệm giải pháp. Đảm bảo bạn sử dụng AWS SSO trong cùng Khu vực AWS mà bạn đã triển khai giải pháp.

Tạo ứng dụng SAML 2.0 tùy chỉnh

Để tạo các ứng dụng SAML 2.0 tùy chỉnh bắt buộc cho Nhóm 1 và Nhóm 2, hãy hoàn thành các bước sau:

1. Mở bảng điều khiển AWS SSO trong tài khoản quản lý AWS của tổ chức AWS của bạn, trong cùng Khu vực mà bạn đã triển khai ngăn xếp giải pháp.
2. Chọn Ứng dụng trong khung điều hướng.
3. Chọn Thêm một ứng dụng mới.
4. Chọn Thêm ứng dụng SAML 2.0 tùy chỉnh.
5. Trong Tên hiển thị, nhập tên ứng dụng, chẳng hạn SageMaker Studio Team 1.
6. Rời bỏ URL bắt đầu ứng dụng và Trạng thái chuyển tiếp trống.
7. Chọn Nếu bạn không có tệp siêu dữ liệu, bạn có thể nhập các giá trị siêu dữ liệu của mình theo cách thủ công.
8. Trong URL ACS của ứng dụng, nhập URL được cung cấp trong SAMLBackendEndpoint khóa của đầu ra ngăn xếp AWS SAM.
9. Trong Đối tượng SAML ứng dụng, nhập URL được cung cấp trong SAMLAudience khóa của đầu ra ngăn xếp AWS SAM.
10. Chọn Lưu các thay đổi.
    
11. Điều hướng đến Ánh xạ thuộc tính tab.
12. Đặt Tiêu Đề đến e-mail và Định dạng đến địa chỉ email.
13. Thêm các thuộc tính mới sau:
    1. ssouserid đặt thành ${user:AD_GUID}
    2. teamid đặt thành Team1 or Team2tương ứng, cho mỗi ứng dụng
       
14. Chọn Lưu các thay đổi.
15. trên Người dùng được chỉ định tab, chọn Chỉ định người dùng.
16. Chọn Người dùng 1 cho ứng dụng Nhóm 1 và cả Người dùng 1 và Người dùng 2 cho ứng dụng Nhóm 2.
17. Chọn Chỉ định người dùng.
    

Kiểm tra giải pháp

Để kiểm tra giải pháp, hãy hoàn thành các bước sau:

1. Truy cập cổng người dùng AWS SSO https://<Identity Store ID>.awsapps.com/start và đăng nhập với tư cách là Người dùng 1.
   Hai ứng dụng SageMaker được hiển thị trong cổng thông tin.
   
2. Chọn Nhóm SageMaker Studio 1.
   Bạn được chuyển hướng đến phiên bản Studio cho Nhóm 1 trong một cửa sổ trình duyệt mới.
   Lần đầu tiên bạn khởi động Studio, SageMaker tạo một ứng dụng JupyterServer. Quá trình này mất vài phút.
   
3. Trong Studio, trên Tập tin menu, chọn Mới và Thiết bị đầu cuối để bắt đầu một thiết bị đầu cuối mới.
4. Trong dòng lệnh đầu cuối, nhập lệnh sau:

   aws sts get-caller-identity

   Lệnh trả về vai trò thực thi Studio.
   

   Trong thiết lập của chúng tôi, vai trò này phải khác nhau đối với mỗi nhóm. Bạn cũng có thể kiểm tra xem mỗi người dùng trong mỗi phiên bản Studio có thư mục chính của riêng họ trên ổ đĩa Amazon EFS được gắn kết hay không.

5. Quay lại cổng AWS SSO, vẫn được đăng nhập với tư cách Người dùng 1 và chọn Nhóm SageMaker Studio 2.
   Bạn được chuyển hướng đến phiên bản Team 2 Studio.
   Quá trình bắt đầu lại có thể mất vài phút vì SageMaker khởi động ứng dụng JupyterServer mới cho Người dùng 2.
6. Đăng nhập với tư cách Người dùng 2 trong cổng AWS SSO.
   Người dùng 2 chỉ có một ứng dụng được chỉ định: SageMaker Studio Team 2.
   

Nếu bạn bắt đầu một phiên bản của Studio thông qua ứng dụng người dùng này, bạn có thể xác minh rằng nó sử dụng cùng một vai trò thực thi SageMaker như phiên bản Nhóm 1 của Người dùng 2. Tuy nhiên, mỗi phiên bản Studio hoàn toàn bị cô lập. Người dùng 2 có thư mục chính của riêng họ trên ổ đĩa Amazon EFS và phiên bản riêng của ứng dụng JupyterServer. Bạn có thể xác minh điều này bằng cách tạo một thư mục và một số tệp cho từng người dùng và thấy rằng thư mục chính của mỗi người dùng đều bị cô lập.

Bây giờ bạn có thể đăng nhập vào bảng điều khiển SageMaker và thấy rằng có ba hồ sơ người dùng đã được tạo.

Bạn vừa triển khai giải pháp bằng chứng về khái niệm để quản lý nhiều người dùng và nhóm với Studio.

Làm sạch

Để tránh bị tính phí, bạn phải xóa tất cả các tài nguyên do dự án cung cấp và được tạo khỏi tài khoản AWS của mình. Sử dụng lệnh SAM CLI sau để xóa ngăn xếp CloudFormation giải pháp:

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

Vì lý do bảo mật và để tránh mất dữ liệu, ngàm Amazon EFS và nội dung được liên kết với miền Studio được triển khai trong giải pháp này sẽ không bị xóa. VPC và các mạng con được liên kết với miền SageMaker vẫn còn trong tài khoản AWS của bạn. Để biết hướng dẫn xóa hệ thống tệp và VPC, hãy tham khảo Xóa hệ thống tệp Amazon EFS và Làm việc với VPC, Tương ứng.

Để xóa ứng dụng SAML tùy chỉnh, hãy hoàn thành các bước sau:

1. Mở bảng điều khiển AWS SSO trong tài khoản quản lý AWS SSO.
2. Chọn Ứng dụng.
3. Chọn Nhóm SageMaker Studio 1.
4. trên Hoạt động menu, chọn Hủy bỏ.
5. Lặp lại các bước này cho Nhóm SageMaker Studio 2.

Kết luận

Giải pháp này đã trình bày cách bạn có thể tạo môi trường linh hoạt và có thể tùy chỉnh bằng cách sử dụng hồ sơ người dùng AWS SSO và Studio để hỗ trợ cấu trúc tổ chức của riêng bạn. Các bước cải tiến có thể tiếp theo hướng tới một giải pháp sẵn sàng cho sản xuất có thể là:

• Triển khai quản lý hồ sơ người dùng Studio tự động như một dịch vụ vi mô chuyên dụng để hỗ trợ quy trình cung cấp hồ sơ tự động và để xử lý siêu dữ liệu và cấu hình cho hồ sơ người dùng, chẳng hạn như trong Máy phát điện Amazon.
• Sử dụng cơ chế tương tự trong trường hợp tổng quát hơn của nhiều miền SageMaker và nhiều tài khoản AWS. Cùng một chương trình phụ trợ SAML có thể cung cấp URL được chỉ định trước tương ứng chuyển hướng đến tổ hợp tài khoản-miền-hồ sơ người dùng theo logic tùy chỉnh của bạn dựa trên quyền của người dùng và thiết lập nhóm.
• Triển khai cơ chế đồng bộ hóa giữa IdP và AWS SSO của bạn và tự động tạo các ứng dụng SAML 2.0 tùy chỉnh.
• Thực hiện quản lý truy cập tài nguyên và dữ liệu có thể mở rộng với kiểm soát truy cập dựa trên thuộc tính (ABAC).

Nếu bạn có bất kỳ phản hồi hoặc câu hỏi nào, vui lòng để lại trong phần bình luận.

Đọc thêm

Tài liệu

Bài viết blog

Lưu ý

Yevgeniy Ilyin là Kiến trúc sư Giải pháp tại AWS. Ông có hơn 20 năm kinh nghiệm làm việc ở tất cả các cấp độ của kiến ​​trúc giải pháp và phát triển phần mềm, đồng thời đã sử dụng các ngôn ngữ lập trình từ COBOL và Assembler đến .NET, Java và Python. Ông phát triển và mã hóa các giải pháp gốc đám mây tập trung vào dữ liệu lớn, phân tích và kỹ thuật dữ liệu.