前提条件クロスアカウント接続シナリオランタイムIAMロールを使用するように Studio を設定する

Studio で Amazon EMRクラスターアクセスのIAMランタイムロールを設定する

Studio または Studio Classic ノートブックから Amazon EMRクラスターに接続すると、ランタイムIAMロールと呼ばれるロールのリストを視覚的に参照し、その場で選択することができます。その後、ノートブックから作成されたすべての Apache Spark、Apache Hive、または Presto ジョブは、ランタイムロールにアタッチされたポリシーで許可されているデータとリソースにのみアクセスします。また、で管理されているデータレイクからデータにアクセスする場合 AWS Lake Formation、ランタイムロールにアタッチされたポリシーを使用して、テーブルレベルおよび列レベルのアクセスを適用できます。

この機能により、各自がデータへのアクセスレベルに合ったアクセス許可でスコープされたランタイムロールを使用して、自分とチームメイトが同じクラスターに接続できます。また、セッションは共有クラスター上で相互に分離されます。

Studio Classic を使用してこの機能を試すには、EMR「Amazon SageMaker Studio Classic の AWS Lake Formation および Amazon できめ細かなデータアクセスコントロールを適用する」を参照してください。このブログ記事は、事前設定されたランタイムロールを使用して Amazon EMRクラスターに接続できるデモ環境を設定するのに役立ちます。

前提条件

使用を開始する前に、次の前提条件を満たしていることを確認します。

Amazon EMRバージョン 6.9 以降を使用します。
Studio Classic ユーザーの場合： Studio Classic Jupyter サーバーアプリケーション設定で JupyterLab バージョン 3 を使用します。このバージョンは、ランタイムロールを使用した Amazon EMRクラスターへの Studio Classic 接続をサポートしています。

Studio ユーザーの場合: SageMaker ディストリビューションイメージバージョン 1.10以降を使用します。
クラスターのセキュリティ設定でランタイムロールの使用を許可します。詳細については、「Amazon EMR ステップのランタイムロール」を参照してください。
「Studio または Studio Classic から Amazon EMRクラスターに接続するためのサポートされているイメージとカーネル」に記載されているカーネルのいずれかを使用してノートブックを作成します。
ランタイムロールを設定するにはランタイムIAMロールを使用するように Studio を設定する、「」の手順を確認してください。

クロスアカウント接続シナリオ

ランタイムロール認証は、データが Studio アカウントの外にある場合に、さまざまなクロスアカウント接続シナリオをサポートします。次の図は、Amazon EMRクラスター、データ、さらには Amazon EMR ランタイム実行ロールを Studio アカウントとデータアカウント間で割り当てる 3 つの異なる方法を示しています。

オプション 1 では、Amazon EMRクラスターと Amazon EMR ランタイム実行ロールは Studio アカウントとは別のデータアカウントにあります。Amazon EMR アクセスロールを引き受けるアクセス許可を Studio または Studio Classic の実行ロールに付与する個別の Amazon EMR アクセスロール ( とも呼ばれますAssumable role) アクセス許可ポリシーを定義します。次に、Amazon EMR アクセスロールは Studio または Studio Classic の実行ロールEMRAPIGetClusterSessionCredentialsに代わって Amazon を呼び出し、クラスターへのアクセスを許可します。

オプション 2 では、Amazon EMRクラスターと Amazon EMR ランタイム実行ロールは Studio アカウントにあります。Studio 実行ロールには、Amazon EMR API GetClusterSessionCredentials を使用してクラスターにアクセスするアクセス許可があります。Amazon S3 バケットにアクセスするには、Amazon EMRランタイム実行ロールにクロスアカウント Amazon S3 バケットアクセス許可を付与します。Amazon S3 バケットポリシー内でこれらのアクセス許可を付与します。

オプション 3 では、Amazon EMRクラスターは Studio アカウントにあり、Amazon EMR ランタイム実行ロールはデータアカウントにあります。Studio または Studio Classic の実行ロールには、Amazon EMR API GetClusterSessionCredentials を使用してクラスターにアクセスするアクセス許可があります。Amazon EMR ランタイム実行ロールを実行ロール設定に追加しますJSON。その後、クラスターを選択するときに UI でロールを選択できます。実行ロール設定JSONファイルを設定する方法の詳細については、「」を参照してください実行ロールを Studio または Studio Classic に事前ロードする。

ランタイムIAMロールを使用するように Studio を設定する

Amazon EMRクラスターのランタイムロール認証を確立するには、必要なIAMポリシー、ネットワーク、およびユーザビリティの強化を設定します。Amazon EMRクラスター、Amazon EMRランタイム実行ロール、またはその両方が Studio アカウントの外部にある場合、クロスアカウント配置を処理するかどうかによってセットアップは異なります。以下のセクションでは、インストールするポリシー、クロスアカウント間のトラフィックを許可するようにネットワークを設定する方法、および Amazon EMR接続を自動化するように設定するためのローカル設定ファイルについて説明します。

Amazon EMRクラスターと Studio が同じアカウントにある場合にランタイムロール認証を設定する

Amazon EMRクラスターが Studio アカウントにある場合は、次の手順を実行して Studio 実行ポリシーに必要なアクセス許可を追加します。

Amazon EMRクラスターに接続するために必要なIAMポリシーを追加します。詳細については、「Amazon EMRクラスターのリストを設定する」を参照してください。
ポリシーで指定された 1 つ以上の許可された Amazon EMR ランタイム実行ロールを渡すEMRAPIGetClusterSessionCredentialsときに Amazon を呼び出すアクセス許可を付与します。
（オプション) ユーザー定義の命名規則に従うIAMロールを渡すアクセス許可を付与します。
（オプション) 特定のユーザー定義文字列でタグ付けされた Amazon EMRクラスターにアクセスするアクセス許可を付与します。
Amazon EMRクラスターに接続するときに使用するロールを選択できるように、IAMロールを事前ロードします。IAM ロールをプリロードする方法の詳細については、「」を参照してください実行ロールを Studio または Studio Classic に事前ロードする。

次のポリシー例では、モデリンググループとトレーニンググループに属する Amazon EMR ランタイム実行ロールがを呼び出すことを許可しますGetClusterSessionCredentials。さらに、保険契約者は、文字列modelingまたはでタグ付けされた Amazon EMRクラスターにアクセスできますtraining。


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "elasticmapreduce:GetClusterSessionCredentials",
            "Resource": "*",
            "Condition": {
                "StringLike": {
                    "elasticmapreduce:ExecutionRoleArn": [
                        "arn:aws:iam::123456780910:role/emr-execution-role-ml-modeling*",
                        "arn:aws:iam::123456780910:role/emr-execution-role-ml-training*"
                    ],
                    "elasticmapreduce:ResourceTag/group": [
                        "*modeling*",
                        "*training*"
                    ]
                }
            }
        }
    ]
}

クラスターと Studio が別のアカウントにある場合のランタイムロール認証の設定

Amazon EMRクラスターが Studio アカウントにない場合は、クラスターに接続できるように、 SageMaker 実行ロールがクロスアカウント Amazon EMR アクセスロールを引き受けることを許可します。次の手順を実行して、クロスアカウント設定をセットアップします。

SageMaker 実行ロールが Amazon EMR アクセスロールを引き受けることができるように、実行ロールのアクセス許可ポリシーを作成します。次に、ポリシーの例を示します。


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowAssumeCrossAccountEMRAccessRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::emr_account_id:role/emr-access-role-name"
        }
    ]
}

信頼ポリシーを作成して、Amazon EMR アクセスロールを引き受けるために信頼IDsされる Studio アカウントを指定します。次に、ポリシーの例を示します。


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCrossAccountSageMakerExecutionRoleToAssumeThisRole",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::studio_account_id:role/studio_execution_role"
      },
      "Action": "sts:AssumeRole"
    }
}

Amazon EMR アクセスロールのアクセス許可ポリシーを作成します。このポリシーは、クラスターで目的のタスクを実行するために必要なアクセス許可を Amazon EMR ランタイム実行ロールに付与します。アクセスロールEMR許可ポリシーで指定された Amazon EMR ランタイム実行ロールAPIGetClusterSessionCredentialsを使用してを呼び出すように Amazon アクセスロールを設定します。次に、ポリシーの例を示します。


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowCallingEmrGetClusterSessionCredentialsAPI",
            "Effect": "Allow",
            "Action": "elasticmapreduce:GetClusterSessionCredentials",
            "Resource": "",
            "Condition": {
                "StringLike": {
                    "elasticmapreduce:ExecutionRoleArn": [
                        "arn:aws:iam::emr_account_id:role/emr-execution-role-name"
                    ]
                }
            }
        }
    ]
}

アカウント間でトラフィックが行き来できるように、クロスアカウントネットワークを設定します。ガイド付き手順については、Amazon EMRクラスターのネットワークアクセスを設定する「のセットアップ」を参照してください。このセクションのステップは、以下のタスクを完了するのに役立ちます。
1. VPC- Studio アカウントと Amazon EMRアカウントをピアリングして接続を確立します。
2. 両方のアカウントのプライベートサブネットルートテーブルにルートを手動で追加します。これにより、Studio アカウントからリモートアカウントのプライベートサブネットへの Amazon EMRクラスターの作成と接続が可能になります。
3. Studio ドメインにアタッチされたセキュリティグループを設定して、アウトバウンドトラフィックを許可し、Amazon EMRプライマリノードのセキュリティグループを設定して、Studio インスタンスセキュリティグループからのインバウンドTCPトラフィックを許可します。
IAM ランタイムロールを事前にロードして、Amazon EMRクラスターに接続するときに使用するロールを選択できるようにします。IAM ロールをプリロードする方法の詳細については、「」を参照してください実行ロールを Studio または Studio Classic に事前ロードする。

Lake Formation へのアクセスの設定

が管理するデータレイクからデータにアクセスする場合 AWS Lake Formation、ランタイムロールにアタッチされたポリシーを使用して、テーブルレベルおよび列レベルのアクセスを適用できます。Lake Formation アクセスのアクセス許可を設定するには、「Amazon EMRをと統合 AWS Lake Formationする」を参照してください。

実行ロールを Studio または Studio Classic に事前ロードする

IAM ランタイムロールをプリロードして、Amazon EMRクラスターに接続するときに使用するロールを選択することができます。Studio JupyterLab ののユーザーは、 SageMaker コンソールまたは提供されたスクリプトを使用できます。

Preload runtime roles in JupyterLab using the SageMaker console

SageMaker コンソールを使用してランタイムロールをユーザープロファイルまたはドメインに関連付けるには：

で SageMaker コンソールに移動しますhttps://console.aws.amazon.com/sagemaker/。
左側のナビゲーションペインで、ドメイン を選択し、アクセス許可を更新した SageMaker 実行ロールを使用してドメインを選択します。
- ランタイム (およびクロスアカウントユースケースのアクセスロール) をドメインに追加するには: ドメインの詳細ページのアプリケーション設定タブで、 JupyterLabセクションに移動します。
- ランタイム (およびクロスアカウントユースケースのアクセスロール) をユーザープロファイルに追加するには: ドメインの詳細ページで、ユーザープロファイルタブを選択し、アクセス許可を更新した SageMaker 実行ロールを使用してユーザープロファイルを選択します。App Configurations タブで、 JupyterLabセクションに移動します。
ARNs アクセスロール (想定ロール) と EMR Serverless ランタイム実行ロールの編集と追加を選択します。
[送信] を選択します。

次に Amazon EMRサーバーに接続すると、ランタイムロールがドロップダウンメニューに表示されて選択できるようになります。

Preload runtime roles in JupyterLab using a Python script

アクセス許可を更新した SageMaker 実行ロールを使用してスペースから開始された JupyterLab アプリケーションで、ターミナルで次のコマンドを実行します。domainID、user-profile-name、emr-accountID、を適切な値EMRServiceRoleに置き換えます。このコードスニペットは、クロスアカウントユースケースの SageMaker ドメイン内のユーザープロファイル設定 (client.update_userprofile) を更新します。具体的には、Amazon のサービスロールを設定しますEMR。また、 JupyterLab アプリケーションが Amazon EMRアカウントEMR内で Amazon を実行するための特定のIAMロール (AssumableRole または AccessRole) を引き受けることも許可します。

または、スペースがドメインレベルで設定された実行ロールを使用している場合は、を使用してドメイン設定client.update_domainを更新します。


import botocore.session
import json
sess = botocore.session.get_session()
client = sess.create_client('sagemaker')

client.update_userprofile(
DomainId="domainID", 
UserProfileName="user-profile-name",
DefaultUserSettings={
    'JupyterLabAppSettings': {
        'EmrSettings': {
            'AssumableRoleArns': ["arn:aws:iam::emr-accountID:role/AssumableRole"],
            'ExecutionRoleArns': ["arn:aws:iam::emr-accountID:role/EMRServiceRole", 
                             "arn:aws:iam::emr-accountID:role/AnotherServiceRole"]
        }
        
    }
})
resp = client.describe_user_profile(DomainId="domainID", UserProfileName=user-profile-name")

resp['CreationTime'] = str(resp['CreationTime'])
resp['LastModifiedTime'] = str(resp['LastModifiedTime'])
print(json.dumps(resp, indent=2))

Preload runtime roles in Studio Classic

（AccessRoleAssumableRole) ARNのを実行 SageMaker ロールに提供します。ARN は、起動時に Jupyter サーバーによってロードされます。Studio が使用する実行ロールは、信頼するアカウント内の Amazon EMRクラスターを検出して接続するためのクロスアカウントロールを前提としています。

この情報を指定するには、ライフサイクル設定 (LCC) スクリプトを使用します。ドメインまたは特定のユーザープロファイルLCCにをアタッチできます。使用するLCCスクリプトは JupyterServer 設定である必要があります。LCC スクリプトの作成方法の詳細については、「Studio Classic でライフサイクル設定を使用する」を参照してください。

以下はLCCスクリプトの例です。スクリプトを変更するには、 AssumableRoleとをそれぞれの値emr-accountに置き換えます。クロスアカウントの数は 5 に制限されています。

次のスニペットは、Studio Classic LCC アプリケーションとクラスターが同じアカウントにある場合に適用できる bash スクリプトの例です。


#!/bin/bash

set -eux

FILE_DIRECTORY="/home/sagemaker-user/.sagemaker-analytics-configuration-DO_NOT_DELETE"
FILE_NAME="emr-configurations-DO_NOT_DELETE.json"
FILE="$FILE_DIRECTORY/$FILE_NAME"

mkdir -p $FILE_DIRECTORY

cat << 'EOF' > "$FILE"
{
    "emr-execution-role-arns":
    {
      "123456789012": [
          "arn:aws:iam::123456789012:role/emr-execution-role-1",
          "arn:aws:iam::123456789012:role/emr-execution-role-2"
      ]
    }
}
EOF

Studio Classic アプリケーションとクラスターが異なるアカウントにある場合は、クラスターを使用できる Amazon EMR アクセスロールを指定します。次のポリシー例では、123456789012 は Amazon EMRクラスターアカウント ID で、212121212121 と 434343434343 は許可された Amazon EMR アクセスロールARNsのです。


#!/bin/bash

set -eux

FILE_DIRECTORY="/home/sagemaker-user/.sagemaker-analytics-configuration-DO_NOT_DELETE"
FILE_NAME="emr-configurations-DO_NOT_DELETE.json"
FILE="$FILE_DIRECTORY/$FILE_NAME"

mkdir -p $FILE_DIRECTORY

cat << 'EOF' > "$FILE"
{
    "emr-execution-role-arns":
    {
      "123456789012": [
          "arn:aws:iam::212121212121:role/emr-execution-role-1",
          "arn:aws:iam::434343434343:role/emr-execution-role-2"
      ]
    }
}
EOF

# add your cross-account EMR access role
FILE_DIRECTORY="/home/sagemaker-user/.cross-account-configuration-DO_NOT_DELETE"
FILE_NAME="emr-discovery-iam-role-arns-DO_NOT_DELETE.json"
FILE="$FILE_DIRECTORY/$FILE_NAME"

mkdir -p $FILE_DIRECTORY

cat << 'EOF' > "$FILE"
{
    "123456789012": "arn:aws:iam::123456789012:role/cross-account-emr-access-role"
}
EOF

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

Amazon EMRクラスターのリストを設定する

リファレンスポリシー