Active Directoryグループ固有のIAMロールを使用して、ユーザーをAmazon SageMaker Studioにオンボードします

Onboard users to Amazon SageMaker Studio using IAM roles specific to Active Directory groups.

Amazon SageMaker Studioは、機械学習（ML）のためのWebベースの統合開発環境（IDE）であり、MLモデルを構築、トレーニング、デバッグ、デプロイ、および監視することができます。AWSアカウントおよびリージョンにStudioをプロビジョニングするには、まずAmazon SageMakerドメインを作成する必要があります。これは、ML環境をカプセル化する構造体です。具体的には、SageMakerドメインには、関連するAmazon Elastic File System（Amazon EFS）ボリューム、承認済みユーザーのリスト、およびさまざまなセキュリティ、アプリケーション、ポリシー、Amazon Virtual Private Cloud（Amazon VPC）の構成が含まれます。

SageMakerドメインを作成する際には、AWS IAM Identity Center（AWS Single Sign-Onの後継）またはAWS Identity and Access Management（IAM）のいずれかのユーザー認証方法を使用するかを選択できます。両方の認証方法にはそれぞれのユースケースがありますが、この投稿では、認証方法としてIAM Identity Center、またはシングルサインオン（SSO）モードを使用したSageMakerドメインに焦点を当てます。

SSOモードでは、IAM Identity CenterでSSOユーザーとグループを設定し、StudioコンソールからSSOグループまたはユーザーにアクセス権を付与します。現在、ドメイン内のすべてのSSOユーザーはドメインの実行ロールを継承しています。これはすべての組織に適用できるわけではありません。たとえば、管理者は、Active Directory（AD）グループメンバーシップに基づいてStudio SSOユーザーのIAM権限を設定したい場合があります。さらに、管理者はSSOユーザーにStudioへのアクセス権限を手動で付与する必要があるため、数百人のユーザーをオンボードする場合には拡張できない場合があります。

この投稿では、ADグループメンバーシップに基づいて最小特権の権限でSSOユーザーをStudioにプロビジョニングするための解決策の具体的なガイダンスを提供します。このガイダンスにより、数百人のユーザーをStudioにオンボードすることができ、セキュリティとコンプライアンスの姿勢を達成することができます。

• テクノロジー・イノベーション・インスティテュートは、最新鋭のFalcon LLM 40BファウンデーションモデルをAmazon SageMakerでトレーニングします
• Amazon Lexのチャットボット開発ライフサイクルをテストベンチで加速化する
• Amazon Lex、Langchain、およびSageMaker Jumpstartを使用した会話型エクスペリエンスにおける生成AIの探求：イントロダクション

ソリューションの概要

以下の図は、ソリューションアーキテクチャを示しています。

StudioにADユーザーをプロビジョニングするワークフローには、次のステップが含まれます。

1. SSOモードでStudioドメインを設定します。

2. 各ADグループについて:

   1. 適切な細分化されたIAMポリシーを使用してStudioの実行ロールを設定します。
   2. ADグループ-ロールマッピングAmazon DynamoDBテーブルのエントリを記録します。

   また、ADグループ名に基づいてIAMロールARNの命名規則を採用し、外部データベースにマッピングを保存する必要がないようにすることもできます。

3. ADユーザーとグループ、およびメンバーシップをAWS Identity Centerに同期します:

   1. SCIMをサポートするIDプロバイダー（IdP）を使用している場合は、SCIM API統合をIAM Identity Centerで使用します。
   2. 自己管理型のADを使用している場合は、ADコネクタを使用することができます。

4. 企業のADでADグループが作成された場合、次の手順を完了します。

   1. IAM Identity Centerで対応するSSOグループを作成します。
   2. SageMakerコンソールを使用してSSOグループをStudioドメインに関連付けます。

5. 企業のADでADユーザーが作成された場合、IAM Identity Centerで対応するSSOユーザーが作成されます。

6. ADユーザーがADグループに割り当てられると、IAM Identity Center API（CreateGroupMembership）が呼び出され、SSOグループメンバーシップが作成されます。

7. 前述のイベントは、名前がAddMemberToGroupのAWS CloudTrailにログが記録されます。

8. Amazon EventBridgeルールはCloudTrailイベントをリッスンし、AddMemberToGroupルールパターンに一致します。

9. EventBridgeルールは、ターゲットAWS Lambda関数をトリガーします。

10. このLambda関数はIAM Identity Center APIをコールバックし、SSOユーザーとグループ情報を取得し、次の手順を実行してSSOユーザーのStudioユーザープロファイル（CreateUserProfile）を作成します:

    1. DynamoDBテーブルを検索して、ADグループに対応するIAMロールを取得します。
    2. SSOユーザーとルックアップテーブルから取得したIAMロールでユーザープロファイルを作成します。
    3. SSOユーザーはStudioにアクセス権を付与されます。

11. SSOユーザーはStudioドメインURLを介してStudio IDEにリダイレクトされます。

注意しておくべき点として、現時点では、ステップ4b (SSOグループをスタジオドメインに関連付ける) は、SageMakerドメインレベルのSageMakerコンソールを使用して管理者が手動で実行する必要があります。

ユーザープロファイルを作成するためのLambda関数の設定

このソリューションでは、Lambda関数を使用してスタジオのユーザープロファイルを作成します。以下のサンプルLambda関数を提供し、スタジオのユーザープロファイルの作成を自動化するために必要な要件に合わせてコピーして変更することができます。この関数は、以下のアクションを実行します:

1. EventBridgeからCloudTrailのAddMemberToGroupイベントを受信する。
2. 環境変数からスタジオのDOMAIN_IDを取得します (複数のドメインがある場合は、代わりにドメインIDをハードコードするか、DynamoDBテーブルを使用することもできます)。
3. ダミーマークアップテーブルからADユーザーを実行ロールにマッチングさせます。テーブル駆動型アプローチを使用している場合は、これをDynamoDBから取得するように変更できます。DynamoDBを使用する場合、Lambda関数の実行ロールにはテーブルから読み取る権限が必要です。
4. CloudTrailイベントデータに基づいて、IAM Identity CenterからSSOユーザーとADグループメンバーシップ情報を取得します。
5. SSOの詳細とマッチングされた実行ロールを持つSSOユーザープロファイルを作成します。

import os
import json
import boto3
DOMAIN_ID = os.environ.get('DOMAIN_ID', 'd-xxxx')


def lambda_handler(event, context):
    
    print({"Event": event})

    client = boto3.client('identitystore')
    sm_client = boto3.client('sagemaker')
    
    event_detail = event['detail']
    group_response = client.describe_group(
        IdentityStoreId=event_detail['requestParameters']['identityStoreId'],
        GroupId=event_detail['requestParameters']['groupId'],
    )
    group_name = group_response['DisplayName']
    
    user_response = client.describe_user(
        IdentityStoreId=event_detail['requestParameters']['identityStoreId'],
        UserId=event_detail['requestParameters']['member']['memberId']
    )
    user_name = user_response['UserName']
    print(f"Event details: {user_name} has been added to {group_name}")
    
    mapping_dict = {
        "ad-group-1": "<execution-role-arn>",
        "ad-group-2": "<execution-role-arn>”
    }
    
    user_role = mapping_dict.get(group_name)
    
    if user_role:
        response = sm_client.create_user_profile(
            DomainId=DOMAIN_ID,
            SingleSignOnUserIdentifier="UserName",
            SingleSignOnUserValue=user_name,
            # if the SSO user_name value is an email, 
      #  add logic to handle it since Studio user profiles don’t accept @ character
            UserProfileName=user_name, 
            UserSettings={
                "ExecutionRole": user_role
            }
        )
        print(response)
    else:
        response = "Group is not authorized to use SageMaker. Doing nothing."
        print(response)
    return {
        'statusCode': 200,
        'body': json.dumps(response)
    }

デフォルトでは、Lambdaの実行ロールはユーザープロファイルを作成したり、SSOユーザーのリストを表示するためのアクセス権限を持っていません。Lambda関数を作成した後、IAMで関数の実行ロールにアクセスし、組織の要件に基づいて必要に応じてスコープダウンした後、以下のポリシーをインラインポリシーとして添付します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "identitystore:DescribeGroup",
                "identitystore:DescribeUser"
            ],
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": "sagemaker:CreateUserProfile",
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": "iam:PassRole",
            "Effect": "Allow",
            "Resource": [
                "<list-of-studio-execution-roles>"
            ]
        }
    ]
}

CloudTrailイベントのためのEventBridgeルールの設定

EventBridgeは、さまざまなソースからのデータを使用してアプリケーションを接続するために使用できるサーバーレスのイベントバスサービスです。このソリューションでは、ルールベースのトリガーを作成します: EventBridgeはイベントをリッスンし、提供されたパターンに一致するかどうかをマッチングして、パターン一致が成功した場合にLambda関数をトリガーします。ソリューションの概要で説明したように、AddMemberToGroupイベントにリッスンします。設定するには、以下の手順を完了します。

1. EventBridgeコンソールで、ナビゲーションペインでルールを選択します。

2. ルールの作成を選択します。

3. ルール名を指定します。たとえば、AddUserToADGroupです。

4. オプションで説明を入力します。

5. イベントバスにはデフォルトを選択します。

6. ルールの種類で、イベントパターンを持つルールを選択し、次へを選択します。

7. イベントパターンの作成ページで、イベントソースをAWSイベントまたはEventBridgeパートナーイベントに設定します。

8. イベントパターンで、カスタムパターン（JSONエディタ）タブを選択し、次のパターンを入力します。

   {
     "source": ["aws.sso-directory"],
     "detail-type": ["AWS API Call via CloudTrail"],
     "detail": {
       "eventSource": ["sso-directory.amazonaws.com"],
       "eventName": ["AddMemberToGroup"]
     }
   }

9. 次へを選択します。

10. ターゲットの選択ページで、ターゲットタイプにAWSサービス、ターゲットにLambda関数、および以前に作成した関数を選択し、次へを選択します。

11. 構成のタグページで次へを選択し、レビューおよび作成ページでルールの作成を選択します。

Lambda関数とEventBridgeルールを設定したら、このソリューションをテストできます。IdPを開き、ADグループの1つにユーザーを追加します（Studio実行ロールにマップされている）。ユーザーを追加すると、Lambda関数ログを確認してイベントを検査し、またStudioユーザーが自動的にプロビジョニングされることを確認できます。さらに、DescribeUserProfile APIコールを使用して、適切な権限でユーザーが作成されたことを確認できます。

複数のStudioアカウントのサポート

前述のアーキテクチャで複数のStudioアカウントをサポートするには、次の変更をお勧めします。

1. StudioアカウントレベルごとにマップされたADグループを設定します。
2. 各StudioアカウントにグループレベルのIAMロールを設定します。
3. グループからIAMロールのマッピングを設定または取得します。
4. 作成されたユーザープロファイルとIAMロールマッピングARNに基づいて、クロスアカウントロールの仮定を実行するLambda関数を設定します。

ユーザーのデプロイメント

ユーザーがADグループから削除された場合、Studioドメインからアクセスを削除する必要があります。 SSOでは、ユーザーが削除されると、ADからIAM Identity Centerへの同期が行われている場合、IAM Identity Centerでユーザーが自動的に無効になり、Studioアプリケーションへのアクセスがすぐに取り消されます。

ただし、Studioのユーザープロファイルはまだ存在します。CloudTrailとLambda関数を使用して、ユーザープロファイルを削除する類似したワークフローを追加できます。EventBridgeトリガーは、DeleteGroupMembershipイベントをリッスンするように変更する必要があります。Lambda関数では、次の手順を実行します。

1. ユーザーとグループIDからユーザープロファイル名を取得します。
2. UserProfileNameEqualsパラメーターでフィルタリングして、ユーザープロファイルのすべての実行中のアプリをリストします。ページネーションされた応答を確認して、すべてのユーザーのアプリをリストします。
3. ユーザーのすべての実行中のアプリを削除し、すべてのアプリが削除されるまで待ちます。アプリのステータスを表示するには、DescribeApp APIを使用できます。
4. すべてのアプリが削除状態（または失敗）になったら、ユーザープロファイルを削除します。

このソリューションを使用すると、MLプラットフォーム管理者は、1つの中央の場所でグループメンバーシップを維持し、EventBridgeとLambda関数を介してStudioユーザープロファイルの管理を自動化できます。

以下のコードは、CloudTrailイベントのサンプルを示しています。

"AddMemberToGroup": 
{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "Unknown",
        "accountId": "<account-id>",
        "accessKeyId": "30997fec-b566-4b8b-810b-60934abddaa2"
    },
    "eventTime": "2022-09-26T22:24:18Z",
    "eventSource": "sso-directory.amazonaws.com",
    "eventName": "AddMemberToGroup",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "54.189.184.116",
    "userAgent": "Okta SCIM Client 1.0.0",
    "requestParameters": {
        "identityStoreId": "d-906716eb24",
        "groupId": "14f83478-a061-708f-8de4-a3a2b99e9d89",
        "member": {
            "memberId": "04c8e458-a021-702e-f9d1-7f430ff2c752"
        }
    },
    "responseElements": null,
    "requestID": "b24a123b-afb3-4fb6-8650-b0dc1f35ea3a",
    "eventID": "c2c0873b-5c49-404c-add7-f10d4a6bd40c",
    "readOnly": false,
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "<account-id>",
    "eventCategory": "Management",
    "tlsDetails": {
        "tlsVersion": "TLSv1.2",
        "cipherSuite": "ECDHE-RSA-AES128-GCM-SHA256",
        "clientProvidedHostHeader": "up.sso.us-east-1.amazonaws.com"
    }
}

以下のコードは、サンプルのStudioユーザープロファイルAPIリクエストを示しています：

create-user-profile \\
--domain-id d-xxxxxx \\
--user-profile-name ssouserid
--single-sign-on-user-identifier 'userName' \\
--single-sign-on-user-value 'ssouserid‘ \\
--user-settings ExecutionRole=arn:aws:iam::<account id>:role/name

結論

この記事では、管理者がADグループメンバーシップに基づいて数百のユーザーのStudioオンボーディングをスケーリングする方法について説明しました。組織が自動化し、スケール化して、アジリティ、セキュリティ、コンプライアンスのニーズに対応するために採用できるエンドツーエンドのソリューションアーキテクチャを示しました。ユーザーオンボーディングを自動化する拡張可能なソリューションをお探しの場合は、このソリューションを試して、以下にフィードバックを残してください！Studioへのオンボードについて詳しくは、Amazon SageMakerドメインへのオンボードを参照してください。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!