AmazonSageMakerとAWSSSOによるチームとユーザーの管理

Amazon SageMakerスタジオ は、機械学習 (ML) 用の Web ベースの統合開発環境 (IDE) であり、ML モデルの構築、トレーニング、デバッグ、デプロイ、および監視を行うことができます。 Studio でオンボーディングされた各ユーザーには、コンピューティング インスタンス、サーバー上のホーム ディレクトリなど、独自の専用リソース セットがあります。 AmazonElasticファイルシステム (Amazon EFS) ボリューム、および専用 AWS IDおよびアクセス管理 (IAM) 実行ロール。

Studio のユーザー アクセスを設定する際の最も一般的な実際の課題の XNUMX つは、データ アクセスとリソース分離のために複数のユーザー、グループ、およびデータ サイエンス チームを管理する方法です。

多くのお客様は、フェデレーション ID を使用してユーザー管理を実装しています。 AWSシングルサインオン (AWS SSO) および外部 ID プロバイダー (IdP) (Active Directory (AD) や AWS Managed Microsoft AD ディレクトリなど)。 AWS と連携しています 推奨される方法 一時認証情報を使用して AWS アカウントにアクセスする方法。

An アマゾンセージメーカー ドメイン AWS SSO をサポートし、AWS SSO で設定可能 認証モード。 この場合、資格のある各 AWS SSO ユーザーは独自の スタジオ ユーザー プロフィール. Studio へのアクセス権を付与されたユーザーには、Studio を直接開く一意のサインイン URL があり、AWS SSO 資格情報でサインインします。 組織は、SageMaker ドメインではなく AWS SSO でユーザーを管理します。 同時に複数のユーザー アクセスをドメインに割り当てることができます。 各ユーザーの Studio ユーザー プロファイルを使用して、ユーザー プロファイルにアタッチされた IAM ロールを介して Studio ノートブックでセキュリティ権限を定義できます。 実行の役割. このロールは、IAM アクセス許可ポリシーに従って SageMaker 操作のアクセス許可を制御します。

AWS SSO 認証モードでは、ユーザーとユーザー プロファイルの間に常に XNUMX 対 XNUMX のマッピングがあります。 SageMaker ドメインは、AWS SSO ユーザー ID に基づいてユーザー プロファイルの作成を管理します。 経由でユーザー プロファイルを作成することはできません。 AWSマネジメントコンソール. これは、XNUMX 人のユーザーが XNUMX つのデータ サイエンス チームのみのメンバーである場合、またはユーザーがプロジェクトやチーム全体で同じまたは非常に類似したアクセス要件を持っている場合にうまく機能します。 より一般的な使用例では、ユーザーが複数の ML プロジェクトに参加し、権限要件がわずかに異なる複数のチームのメンバーになることができる場合、ユーザーは、異なる実行ロールと権限ポリシーを持つ異なる Studio ユーザー プロファイルにアクセスする必要があります。 AWS SSO 認証モードでは AWS SSO とは独立してユーザー プロファイルを管理できないため、ユーザーと Studio ユーザー プロファイルの間に XNUMX 対多のマッピングを実装することはできません。

たとえば、異なるデータ カテゴリに対してセキュリティ コンテキストの強力な分離を確立する必要がある場合、またはユーザーのアクティビティとリソースの XNUMX つのグループが別のグループに完全に表示されないようにする必要がある場合は、複数の SageMaker ドメインを作成することをお勧めします。 この記事の執筆時点では、リージョンごとに AWS アカウントごとに XNUMX つのドメインのみを作成できます。 強力な分離を実装するには、回避策としてアカウントごとに XNUMX つのドメインを持つ複数の AWS アカウントを使用できます。

XNUMXつ目の課題は、 Studio IDE へのアクセスを制限する 企業ネットワークまたは指定された VPC 内のユーザーのみ。 を使用してこれを達成できます IAM ベースのアクセス制御ポリシー. この場合、SageMaker ドメインは次のように構成する必要があります。 IAM 認証モード、IAM ID ベースのポリシーは、AWS SSO モードのサインイン メカニズムでサポートされていないためです。 ポスト AWSSSOとSAMLアプリケーションを使用したAmazonSageMakerStudioへの安全なアクセス この課題を解決し、SageMaker ドメインへのネットワーク アクセスを制御する方法を示します。

このソリューションは、Studio の AWS SSO ユーザー管理のこれらの課題に対処し、複数のユーザー グループの一般的なユース ケースと、ユーザーとチーム間の多対多のマッピングに対応します。 このソリューションでは、 カスタム SAML 2.0 アプリケーション Studio のユーザー認証をトリガーし、XNUMX 人の AWS SSO ユーザーごとに複数の Studio ユーザー プロファイルをサポートするメカニズムとして。

このアプローチを使用して、SAML 2.0 承認プロセスによってサポートされるアプリケーションでカスタム ユーザー ポータルを実装できます。 カスタム ユーザー ポータルでは、ユーザー アプリケーションの管理および表示方法について最大限の柔軟性を得ることができます。 たとえば、ユーザー ポータルは、アクセスするアプリケーションの識別を容易にするために、一部の ML プロジェクト メタデータを表示できます。

ソリューションのソース コードは、 GitHubリポジトリ.

ソリューションの概要

このソリューションは、次のアーキテクチャを実装します。

主な高レベルのアーキテクチャ コンポーネントは次のとおりです。

1. ID プロバイダー – ユーザーとグループは、Azure AD などの外部 ID ソースで管理されます。 AD グループへのユーザーの割り当ては、特定のユーザーが持つ権限と、そのユーザーがアクセスできる Studio チームを定義します。 ID ソースは、AWS SSO と同期する必要があります。
2. AWS SSO – AWS SSO は、SSO ユーザー、SSO 権限セット、およびアプリケーションを管理します。 このソリューションは、カスタム SAML 2.0 アプリケーションを使用して、資格のある AWS SSO ユーザーに Studio へのアクセスを提供します。 このソリューションでは、SAML 属性マッピングも使用して、ユーザー ID やユーザー チームなどの特定のアクセス関連データを SAML アサーションに入力します。 このソリューションは SAML API を作成するため、SAML アサーションをサポートする任意の IdP を使用してこのアーキテクチャを作成できます。 たとえば、Okta や、ランディング ページにユーザー ポータルとアプリケーションを提供する独自の Web アプリケーションを使用することもできます。 この投稿では、AWS SSO を使用します。
3. カスタム SAML 2.0 アプリケーション – このソリューションは、Studio チームごとに XNUMX つのアプリケーションを作成し、権限に基づいて XNUMX つまたは複数のアプリケーションをユーザーまたはユーザー グループに割り当てます。 ユーザーは、割り当てられたアクセス許可に基づいて、AWS SSO ユーザー ポータル内からこれらのアプリケーションにアクセスできます。 各アプリケーションは、 アマゾンAPIゲートウェイ SAML バックエンドとしてのエンドポイント URL。
4. SageMakerドメイン – このソリューションは、AWS アカウントで SageMaker ドメインをプロビジョニングし、AWS SSO ユーザーとユーザーが割り当てられているスタジオ チームの組み合わせごとに専用のユーザー プロファイルを作成します。 ドメインは IAM で設定する必要があります 認証モード。
5. Studioユーザープロファイル – このソリューションは、ユーザーとチームの組み合わせごとに専用のユーザー プロファイルを自動的に作成します。 たとえば、ユーザーが 500 つの Studio チームのメンバーであり、対応する権限を持っている場合、ソリューションはこのユーザーに対して 2.5 つの個別のユーザー プロファイルをプロビジョニングします。 各プロファイルは、常に 250 人のユーザーのみに属します。 ユーザーとチームの可能な組み合わせごとに Studio ユーザー プロファイルがあるため、このアプローチを実装する前に、ユーザー プロファイルのアカウント制限を考慮する必要があります。 たとえば、制限が 1 ユーザー プロファイルで、各ユーザーが 2 つのチームのメンバーである場合、その制限を 1 倍速く消費し、その結果、2 ユーザーをオンボーディングできます。 ユーザー数が多い場合は、セキュリティ コンテキストの分離のために複数のドメインとアカウントを実装することをお勧めします。 概念実証を実証するために、ユーザー 1 とユーザー 2 の 2 人のユーザーと、チーム 1 とチーム 2 の 2 つのスタジオ チームを使用します。ユーザー XNUMX は両方のチームに属し、ユーザー XNUMX はチーム XNUMX のみに属します。 ユーザー XNUMX は両方のチームの Studio 環境にアクセスできますが、ユーザー XNUMX はチーム XNUMX の Studio 環境にのみアクセスできます。
6. スタジオの実行役割 – 各 Studio ユーザー プロファイルは、ユーザーが属する特定のチームに必要なレベルのアクセス権を持つアクセス許可ポリシーを備えた専用の実行ロールを使用します。 Studio 実行ロールは、個々のユーザーとそのチーム ロールの間で効果的な権限分離を実装します。 個々のユーザー レベルではなく、役割ごとにデータとリソースへのアクセスを管理します。

このソリューションは、SAML 2.0 属性、Studio ユーザー プロファイルのタグ、および SageMaker 実行ロールのタグを使用して、属性ベースのアクセス制御 (ABAC) も実装します。

この特定の構成では、AWS SSO ユーザーが AWS アカウントにサインインするアクセス許可を持っておらず、アカウントに対応する AWS SSO 制御の IAM ロールを持っていないことを前提としています。 各ユーザーは、AWS アカウントのコンソールに移動する必要なく、AWS SSO ポータルから署名付き URL を介して Studio 環境にサインインします。 実際の環境では、セットアップが必要になる場合があります AWS SSO アクセス許可セット 許可されたユーザーが IAM ロールを引き受け、AWS アカウントにサインインすることをユーザーに許可します。 たとえば、データ サイエンティスト ロールのアクセス許可をユーザーに提供して、ユーザーがアカウント リソースと対話し、そのロールを果たすために必要なレベルのアクセス権を持つことができるようにすることができます。

ソリューションアーキテクチャとワークフロー

次の図は、AWS SSO ユーザーのエンドツーエンドのサインイン フローを示しています。

AWS SSO ユーザーは、AWS SSO ポータルで対応する Studio アプリケーションを選択します。 AWS SSO は、構成された SAML 属性マッピングを使用して SAML アサーション (1) を準備します。 カスタム SAML アプリケーションは、API Gateway エンドポイント URL をアサーション コンシューマー サービス (ACS) として設定され、AWS SSO ユーザー ID とチーム ID を含むマッピング属性が必要です。 を使用しております ssouserid および teamid カスタム属性を使用して、必要なすべての情報を SAML バックエンドに送信します。

API Gateway は SAML バックエンド API を呼び出します。 アン AWSラムダ 関数 (2) は API を実装し、SAML 応答を解析してユーザー ID とチーム ID を抽出します。 関数はそれらを使用して、実行ロールや SageMaker ドメイン ID などのチーム固有の構成を取得します。 この関数は、必要なユーザー プロファイルがドメインに存在するかどうかを確認し、プロファイルが存在しない場合は、対応する構成設定で新しいプロファイルを作成します。 その後、この関数は次を呼び出して、特定の Studio ユーザー プロファイルの Studio 署名付き URL を生成します。 署名付きドメインURLの作成 API (3) SageMaker API VPC エンドポイント経由。 Lambda 関数は最終的に、署名付き URL を HTTP 302 リダイレクト応答とともに返し、ユーザーを Studio にサインインさせます。

このソリューションは、SAML バックエンドの非実稼働サンプル バージョンを実装します。 Lambda 関数は SAML アサーションを解析し、 <saml2:AttributeStatement> を構築する要素 CreatePresignedDomainUrl API 呼び出し。 運用ソリューションでは、適切な SAML バックエンド実装を使用する必要があります。これには、SAML 応答、署名、証明書の検証、リプレイとリダイレクトの防止、および SAML 認証プロセスのその他の機能が含まれている必要があります。 たとえば、 python3-saml SAML バックエンドの実装 or OneLogin オープンソース SAML ツールキット 安全な SAML バックエンドを実装します。

Studio ユーザー プロファイルの動的作成

このソリューションは、AWS SSO サインイン プロセスが署名付き URL をリクエストするとすぐに、ユーザーとチームの組み合わせごとに Studio ユーザー プロファイルを自動的に作成します。 この概念実証とシンプルさのために、ソリューションは 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、 参照する boto3 の create_user_profile.

IAMの役割

次の図は、このソリューションの IAM ロールを示しています。

役割は次のとおりです。

1. スタジオ執行役 – Studio ユーザー プロファイルは、各チームまたはユーザー グループに固有のデータおよびリソース権限を持つ専用の Studio 実行ロールを使用します。 このロールは、タグを使用して、データおよびリソース アクセス用の ABAC を実装することもできます。 詳細については、次を参照してください。 SageMakerの役割.
2. SAML バックエンド Lambda 実行ロール – この実行ロールには、 CreatePresignedDomainUrl API。 次を使用して、追加の条件付きチェックを含めるようにアクセス許可ポリシーを構成できます。 Condition キー。 たとえば、企業のプライベート ネットワーク内の指定された範囲の IP アドレスからのみ Studio へのアクセスを許可するには、次のコードを使用します。

   {
       "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 ポリシーで条件を使用する方法の例については、次を参照してください。 ID ベースのポリシーを使用して、SageMaker API へのアクセスを制御します。

3. セージメーカー – SageMaker は、実行ロールの対応する信頼ポリシーによって制御されるように、ユーザーに代わって Studio 実行ロールを引き受けます。 これにより、サービスはデータとリソースにアクセスし、ユーザーに代わってアクションを実行できます。 Studio 実行ロールには、SageMaker がこのロールを引き受けることを許可する信頼ポリシーが含まれている必要があります。
4. AWS SSO 権限セット IAM ロール – AWS 組織内の AWS アカウントに AWS SSO ユーザーを割り当てるには、 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 CloudFormation スタック このソリューションでは、SageMaker ドメインで使用される XNUMX つの Studio 実行ロールを作成します。

• SageMakerStudioExecutionRoleDefault
• SageMakerStudioExecutionRoleTeam1
• SageMakerStudioExecutionRoleTeam2

どの役割も持っていません AmazonSageMakerFullAccess ポリシーが添付されており、それぞれに限定された一連の権限しかありません。 実際の SageMaker 環境では、特定の要件に基づいてロールのアクセス許可を修正する必要があります。

SageMakerStudioExecutionRoleDefault カスタムポリシーのみを持っています SageMakerReadOnlyPolicy 許可されたアクションの制限リストが添付されています。

両方のチームの役割、 SageMakerStudioExecutionRoleTeam1 および SageMakerStudioExecutionRoleTeam2、さらに XNUMX つのカスタム ポリシーがあり、 SageMakerAccessSupportingServicesPolicy および SageMakerStudioDeveloperAccessPolicy、特定のサービスと XNUMX つの拒否のみのポリシーの使用を許可し、 SageMakerDeniedServicesPolicy、一部の SageMaker API 呼び出しを明示的に拒否します。

Studio 開発者アクセス ポリシーは、 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 プライベートリンク 接続。 必要に応じて、Studio ノートブックからのインターネット アクセスを有効にすることができます。 このソリューションでは、次の XNUMX つも作成されます。 VPC セキュリティ グループ SAML バックエンドの Lambda 関数など、すべてのソリューション コンポーネント間のトラフィックを制御するため、 VPC エンドポイント、 そしてスタジオノート。

この概念実証とシンプルさのために、ソリューションは単一の SageMaker サブネットを作成します。 アベイラビリティーゾーン. 本番環境のセットアップでは、複数のアベイラビリティーゾーンで複数のプライベートサブネットを使用し、各サブネットが適切なサイズであることを確認する必要があります (ユーザーごとに最小 XNUMX つの IP を想定)。

このソリューションは、必要なすべてのネットワーク インフラストラクチャをプロビジョニングします。 CloudFormation テンプレート ./cfn-templates/vpc.yaml ソースコードが含まれています。

展開手順

ソリューションをデプロイしてテストするには、次の手順を完了する必要があります。

1. を介してソリューションのスタックをデプロイします AWSサーバーレスアプリケーションモデル （AWS SAM）テンプレート。
2. AWS SSO ユーザーを作成するか、既存の AWS SSO ユーザーを使用します。
3. カスタム SAML 2.0 アプリケーションを作成し、AWS SSO ユーザーをアプリケーションに割り当てます。

ソリューションの完全なソース コードは、GitHub で提供されています。 倉庫.

前提条件

このソリューションを使用するには、 AWSコマンドラインインターフェイス （AWS CLI）、 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. 「 ソリューションの展開オプション 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 という名前の XNUMX 人のユーザーを作成するか、既存の AWS SSO ユーザーのいずれか XNUMX つを使用してソリューションをテストします。 ソリューションをデプロイしたのと同じ AWS リージョンで AWS SSO を使用していることを確認してください。

カスタム SAML 2.0 アプリケーションを作成する

チーム 2.0 とチーム 1 に必要なカスタム SAML 2 アプリケーションを作成するには、次の手順を実行します。

1. ソリューション スタックをデプロイしたのと同じリージョンで、AWS 組織の AWS 管理アカウントで AWS SSO コンソールを開きます。
2. 選択する アプリケーション ナビゲーションペインに表示されます。
3. 選択する 新しいアプリケーションを追加する.
4. 選択する カスタムSAML2.0アプリケーションを追加する.
5. 表示名、アプリケーション名を入力します。たとえば、 SageMaker Studio Team 1.
6. コメントを残す アプリケーション開始URL および リレー状態 空の。
7. 選択する メタデータ ファイルがない場合は、メタデータ値を手動で入力できます.
8. アプリケーションACSURLで提供されている URL を入力します。 SAMLBackendEndpoint AWS SAM スタック出力のキー。
9. アプリケーションSAMLオーディエンスで提供されている URL を入力します。 SAMLAudience AWS SAM スタック出力のキー。
10. 選択する 変更を保存します.
    
11. に移動します 属性マッピング タブには何も表示されないことに注意してください。
12. をセットする 件名 〜へ email および フォーマット 〜へ 電子メールアドレス.
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 として署名します。
   XNUMX つの SageMaker アプリケーションがポータルに表示されます。
   
2. 選択する SageMaker スタジオ チーム 1.
   新しいブラウザ ウィンドウで、チーム 1 の Studio インスタンスにリダイレクトされます。
   Studio を初めて起動すると、SageMaker は JupyterServer アプリケーションを作成します。 このプロセスには数分かかります。
   
3. スタジオでは、 File メニュー、選択 新作 および ターミナル 新しいターミナルを起動します。
4. ターミナル コマンド ラインで、次のコマンドを入力します。

   aws sts get-caller-identity

   このコマンドは Studio 実行ロールを返します。
   

   私たちの設定では、この役割はチームごとに異なる必要があります。 また、Studio の各インスタンスの各ユーザーが、マウントされた Amazon EFS ボリュームに独自のホーム ディレクトリを持っていることを確認することもできます。

5. まだユーザー 1 としてログインしている AWS SSO ポータルに戻り、選択します。 SageMaker スタジオ チーム 2.
   Team 2 Studio インスタンスにリダイレクトされます。
   SageMaker がユーザー 2 の新しい JupyterServer アプリケーションを開始するため、開始プロセスには数分かかる場合があります。
6. AWS SSO ポータルでユーザー 2 としてサインインします。
   ユーザー 2 には、SageMaker Studio Team 2 という XNUMX つのアプリケーションのみが割り当てられています。
   

このユーザーアプリケーションを介して Studio のインスタンスを開始すると、ユーザー 1 のチーム 2 インスタンスと同じ SageMaker 実行ロールを使用していることを確認できます。 ただし、各 Studio インスタンスは完全に分離されています。 ユーザー 2 は、Amazon EFS ボリューム上に独自のホーム ディレクトリと、JupyterServer アプリケーションの独自のインスタンスを持っています。 これを確認するには、ユーザーごとにフォルダーといくつかのファイルを作成し、各ユーザーのホーム ディレクトリが分離されていることを確認します。

これで、SageMaker コンソールにサインインして、XNUMX つのユーザー プロファイルが作成されていることを確認できます。

Studio で複数のユーザーとチームを管理するための概念実証ソリューションを実装しました。

クリーンアップ

料金が発生しないようにするには、プロジェクトでプロビジョニングおよび生成されたすべてのリソースを AWS アカウントから削除する必要があります。 次の SAM CLI コマンドを使用して、ソリューションの CloudFormation スタックを削除します。

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

セキュリティ上の理由とデータ損失を防ぐため、Amazon EFS マウントと、このソリューションにデプロイされた Studio ドメインに関連付けられたコンテンツは削除されません。 SageMaker ドメインに関連付けられた VPC とサブネットは、AWS アカウントに残ります。 ファイル システムと VPC を削除する手順については、次を参照してください。 Amazon EFS ファイル システムの削除 および VPC の操作それぞれ。

カスタム SAML アプリケーションを削除するには、次の手順を実行します。

1. AWS SSO 管理アカウントで AWS SSO コンソールを開きます。
2. 選択する アプリケーション.
3. 選択 SageMaker スタジオ チーム 1.
4. ソフトウェア設定ページで、下図のように メニュー、選択 削除します.
5. これらの手順を繰り返します SageMaker スタジオ チーム 2.

まとめ

このソリューションは、AWS SSO と Studio ユーザープロファイルを使用して柔軟でカスタマイズ可能な環境を作成し、独自の組織構造をサポートする方法を示しました。 本番対応のソリューションに向けた次の可能な改善ステップは次のとおりです。

• 自動化された Studio ユーザー プロファイル管理を専用のマイクロサービスとして実装して、自動化されたプロファイル プロビジョニング ワークフローをサポートし、ユーザー プロファイルのメタデータと構成を処理します。 Amazon DynamoDB.
• 複数の SageMaker ドメインと複数の AWS アカウントのより一般的なケースで同じメカニズムを使用します。 同じ SAML バックエンドは、ユーザーの資格とチームのセットアップに基づくカスタム ロジックに従って、ユーザー プロファイル、ドメイン、アカウントの組み合わせにリダイレクトする、対応する署名付き URL を提供できます。
• IdP と AWS SSO 間の同期メカニズムを実装し、カスタム SAML 2.0 アプリケーションの作成を自動化します。
• スケーラブルなデータおよびリソース アクセス管理を実装する 属性ベースのアクセス制御 （ABAC）。

フィードバックや質問がある場合は、コメントに残してください。

参考文献

ドキュメンテーション

ブログの記事

著者について

エフゲニー・イリン AWSのソリューションアーキテクトです。 彼は、ソフトウェア開発とソリューションアーキテクチャのすべてのレベルで20年以上の経験があり、COBOLやアセンブラーから.NET、Java、Pythonまでのプログラミング言語を使用してきました。 彼は、ビッグデータ、分析、およびデータエンジニアリングに重点を置いて、クラウドネイティブソリューションを開発およびコーディングしています。