EKS Pod Identity を使用する理由 Pod Identity に関する考慮事項 EKS クラスターで EKS Pod Identity を準備するジョブ実行ロールを作成する EKS Pod Identity の関連付けを設定するロールの関連付けを削除する既存の IRSA を Pod Identity に自動的に移行するトラブルシューティング

オプション 1: EKS クラスターで EKS Pod Identity を有効にする

EKS Pod Identity の関連付けは、Amazon EC2 インスタンスプロファイルから Amazon EC2 インスタンスに認証情報を提供する場合と同じような方法で、アプリケーションの認証情報を管理する機能があります。Amazon EKS Pod Identity は、追加の EKS Auth API と各ノードで実行されるエージェントポッドを使用して、ワークロードに認証情報を提供します。

Amazon EMR on EKS は、StartJobRun 送信モデルの emr-7.3.0 リリース以降、EKS Pod Identity のサポートを開始します。

EKS Pod Identity の詳細については、「Understand how EKS Pod Identity works」を参照してください。

EKS Pod Identity を使用する理由

EMR のセットアップの一環として、ジョブ実行ロールは、IAM ロールと特定の名前空間 (EMR 仮想クラスター) のサービスアカウントの間に信頼境界を確立しなければなりません。IRSA では、これは EMR ジョブ実行ロールの信頼ポリシーを更新することで実現されました。ただし、IAM 信頼ポリシーの長さに 4096 文字のハード制限があるので、最大十二 (12) 個の EKS クラスターで 1 つのジョブ実行 IAM ロールを共有するという制約がありました。

EMR の Pod Identity のサポートにより、IAM ロールとサービスアカウントの信頼境界は、EKS Pod Identity の関連付け APIs を通じて EKS チームによって管理されるようになりました。

注記

EKS Pod Identity のセキュリティ境界は、ポッドレベルではなく、サービスアカウントレベルのままです。

Pod Identity に関する考慮事項

Pod Identity Limitations の詳細については、「EKS Pod Identity considerations」を参照してください。

EKS クラスターで EKS Pod Identity を準備する

必要なアクセス許可が NodeInstanceRole に存在するかどうかを確認します

ノードロール NodeInstanceRole には、エージェントが EKS Auth API で AssumeRoleForPodIdentity アクションを実行する権限があります。AmazonEKS ユーザーガイドで定義されている AmazonEKSWorkerNodePolicy に以下を追加するか、カスタムポリシーを使用できます。

EKS クラスターが 0.181.0 以降の eksctl バージョンで作成された場合、必要な AssumeRoleForPodIdentity アクセス許可を含む AmazonEKSWorkerNodePolicy がノードロールに自動的にアタッチされます。アクセス許可がない場合は、Pod Identity のロールの引き受けを許可する次のアクセス許可を AmazonEKSWorkerNodePolicy に手動で追加します。このアクセス許可は、EKS Pod Identity エージェントがポッドの認証情報を取得するために必要です。

EKS Pod Identity エージェントアドオンを作成する

以下のコマンドを使用して、最新バージョンの EKS Pod Identity Agent アドオンを作成します:


aws eks create-addon --cluster-name cluster-name --addon-name eks-pod-identity-agent

kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'

Amazon EKS コンソールから EKS Pod Identity Agent アドオンを作成するには、以下の手順に従います:

Amazon EKS コンソールで Amazon EKS コンソールを開きます。
左のナビゲーションペインで、[クラスター] を選択し、次にアドオンを設定するEKS Pod Identity エージェントを選択します。
[アドオン] タブを選択してください。
[その他のアドオンを入手] を選択してください。
EKS Pod Identity のアドオンボックスの右上にあるボックスを選択し、[次へ] を選択します。
[選択したアドオン設定を構成する] ページの [バージョン] ドロップダウンリストで任意のバージョンを選択します。
(オプション) [オプションの設定] を展開して追加の設定を入力します。例えば、代替のコンテナイメージの場所と ImagePullSecrets を指定できます。許可されたキーのある JSON スキーマは、[アドオン設定スキーマ] に表示されます。

設定キーと値を [設定値] に入力します。
[次へ] を選択します。
エージェントポッドが CLI を介してクラスター上で実行されていることを確認してください。

kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'

出力例は以下のとおりです:


NAME                              READY   STATUS    RESTARTS      AGE
eks-pod-identity-agent-gmqp7      1/1     Running   1 (24h ago)   24h
eks-pod-identity-agent-prnsh      1/1     Running   1 (24h ago)   24h

これにより、kube-system 名前空間に新しい DaemonSet が設定されます。次に、EKS ノード上で実行する Amazon EKS Pod Identity エージェントは AssumeRoleForPodIdentity アクションを使用して EKS Auth API から一時的な認証情報を取得します。これらの認証情報は、コンテナ内で実行する AWS SDK で利用できます。

詳細については、パブリックドキュメントの前提条件「Amazon EKS Pod Identity エージェントのセットアップ」を参照してください。

ジョブ実行ロールを作成する

EKS Pod Identity を許可するジョブ実行ロールを作成または更新する

Amazon EMR on EKS でワークロードを実行するには、IAM ロールを作成する必要があります。このドキュメントでは、このロールをジョブ実行ロールと呼びます。IAM ロールの作成方法の詳細については、「IAM ユーザーガイド」の「ICreating IAM roles」を参照してください。

さらに、ジョブ実行ロールに必要なアクセス許可を指定する IAM ポリシーを作成し、このポリシーをロールにアタッチして EKS Pod Identity を有効にしなければなりません。

例えば、次のジョブ実行ロールがあるとします。詳細については、「Create a job execution role」を参照してください。


arn:aws:iam::111122223333:role/PodIdentityJobExecutionRole

重要

Amazon EMR on EKS は、ジョブ実行ロール名に基づいて Kubernetes サービスアカウントを自動的に作成します。cluster_name、pod_name および service_account_name の組み合わせが長さ制限を超えるとジョブが失敗する可能性があるので、ロール名が長すぎないようにしてください。

ジョブ実行ロール設定 – ジョブ実行ロールが EKS Pod Identity の以下の信頼アクセス許可で作成されていることを確認します。既存のジョブ実行ロールを更新するには、次の EKS サービスプリンシパルを信頼ポリシーの追加アクセス許可として信頼するように設定します。この信頼アクセス許可は、既存の IRSA 信頼ポリシーと共存できます。


cat >trust-relationship.json <<EOF
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}
EOF

ユーザーアクセス許可: ユーザーには、StartJobRun API コールを実行したりジョブを送信したりするための iam:PassRole アクセス許可が必要です。このアクセス許可により、ユーザーはジョブ実行ロールを EMR on EKS に渡すことができます。ジョブ管理者には、デフォルトでアクセス許可が必要です。

ユーザーに必要なアクセス許可を以下に示します:


{
    "Effect": "Allow",
    "Action": "iam:PassRole",
    "Resource": "arn:aws:iam::111122223333:role/PodIdentityJobExecutionRole",
    "Condition": {
        "StringEquals": {
            "iam:PassedToService": "pods.eks.amazonaws.com"
        }
    }
}

特定の EKS クラスターへのユーザーアクセスをさらに制限するには、AssociatedResourceArn 属性フィルターを IAM ポリシーに追加します。これにより、ロールの引き受けが承認された EKS クラスターに制限され、リソースレベルのセキュリティコントロールが強化されます。


"Condition": {
        "ArnLike": {
            "iam:AssociatedResourceARN": [
                "arn:aws:eks:us-west-2:111122223333:cluster/*"
            ]
        }

EKS Pod Identity の関連付けを設定する

前提条件

EKS 管理者ユーザーなどの Pod Identity の関連付けを作成する IAM Identity に、アクセス許可 eks:CreatePodIdentityAssociation と iam:PassRole があることを確認します。

ロールと EMR サービスアカウントの関連付けを作成する

Create EMR role associations through the AWS CLI

Kubernetes 名前空間にジョブを送信する場合、管理者はジョブ実行ロールと EMR マネージドサービスアカウントの ID との間に関連付けを作成しなければなりません。EMR マネージドサービスアカウントは、ジョブの送信時に自動的に作成され、ジョブが送信される名前空間にスコープ設定されます。

AWS CLI (バージョン 2.24.0 以降) で、次のコマンドを実行して、Pod Identity とのロールの関連付けを作成します。

以下のコマンドを実行して、Pod Identity の関連付けを作成します:


aws emr-containers create-role-associations \
        --cluster-name mycluster \
        --namespace mynamespace \
        --role-name JobExecutionRoleIRSAv2

注意:

各クラスターの関連付けの上限は 1,000 です。各ジョブ実行ロール - 名前空間マッピングには、ジョブ送信者、ドライバー、エグゼキュターポッドに 3 つの関連付けが必要です。
関連付けることができるのはクラスターと同じ AWS アカウントにあるロールだけです。別のアカウントから、EKS Pod Identity が使用するように設定したこのアカウントのロールに、アクセスを委任できます。アクセス権の委任および AssumeRole については、「IAM ユーザーガイド」の「 IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任」を参照してください。

Create EMR role associations through Amazon EKS

EMR は、ジョブの送信時に特定の命名パターンを持つサービスアカウントを作成します。手動の関連付けを行うか、このワークフローを AWS SDK と統合するには、以下の手順に従います:

サービスアカウント名の作成:


emr-containers-sa-spark-%(SPARK_ROLE)s-%(AWS_ACCOUNT_ID)s-%(BASE36_ENCODED_ROLE_NAME)s

以下の例では、サンプルジョブ実行ロール JobExecutionRoleIRSAv2 のロール関連付けを作成します。

ロールの関連付けの例:


RoleName: JobExecutionRoleIRSAv2
Base36EncodingOfRoleName: 2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe

CLI コマンドの例


# setup for the client service account (used by job runner pod)
# emr-containers-sa-spark-client-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-client-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe

# driver service account
# emr-containers-sa-spark-driver-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe        
aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-driver-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe

# executor service account
# emr-containers-sa-spark-executor-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-executor-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe

EKS Pod Identity に必要なすべてのステップを完了したら、IRSA セットアップの以下のステップをスキップできます:

次のステップに直接スキップできます: Amazon EMR on EKS へのアクセス権をユーザーに付与する

ロールの関連付けを削除する

仮想クラスターまたはジョブ実行ロールを削除し、そのサービスアカウントに EMR へのアクセスを許可しない場合は、そのロールの関連付けを削除しなければなりません。これは、EKS が存在しないリソース (名前空間とサービスアカウント) との関連付けを許可するためです。Amazon EMR on EKS では、名前空間が削除された場合やロールが使用されなくなった場合は、関連付けを削除して、他の関連付けのスペースを解放することをお勧めします。

注記

EKS には作成できる関連付けの数に制限があるため (ソフト制限: クラスターあたり 1,000 個の関連付け)、関連付けが残ると、それらを削除しない場合にスケーリング機能に影響する可能性があります。特定の名前空間に Pod Identity の関連付けを一覧表示して、クリーンアップする必要がある既存の関連付けがあるかどうかを確認できます:


aws eks list-pod-identity-associations --cluster-name mycluster --namespace mynamespace

AWS CLI (バージョン 2.24.0 以降) で、以下の emr-containers コマンドを実行して EMR のロールの関連付けを削除します:


aws emr-containers delete-role-associations \
        --cluster-name mycluster \
        --namespace mynamespace \
        --role-name JobExecutionRoleIRSAv2

既存の IRSA を Pod Identity に自動的に移行する

ツール eksctl を使用して、サービスアカウントの既存の IAM ロール (IRSA) を Pod Identity の関連付けに移行できます:


eksctl utils migrate-to-pod-identity \
    --cluster mycluster \
    --remove-oidc-provider-trust-relationship \
    --approve

--approve フラグなしでコマンドを実行することにより、移行ステップを反映した計画のみが出力され、実際の移行は行われません。

トラブルシューティング

ジョブが NoClassDefinitionFound または ClassNotFound 認証情報プロバイダーの例外で失敗したか、認証情報プロバイダーを取得できませんでした。

EKS Pod Identity は、コンテナ認証情報プロバイダーを使用して必要な認証情報を取得します。カスタム認証情報プロバイダーを指定した場合は、正しく動作していることを確認します。または、EKS Pod Identity をサポートする正しい AWS SDK バージョンを使用していることを確認してください。詳細については、「Amazon EKS の使用を開始する」を参照してください。

ジョブが失敗し、eks-pod-identity-agent ログに「Failed to Retrieve Credentials due to [x] Size Limit」というエラーが表示されました。

EMR on EKS は、ジョブ実行ロール名に基づいて Kubernetes サービスアカウントを作成します。ロール名が長すぎると、cluster_name、pod_name、service_account_name の組み合わせが長さ制限を超えているため、EKS Auth は認証情報の取得に失敗します。どのコンポーネントが最もスペースを占有しているかを特定し、それに応じてサイズを調整します。

ジョブが失敗し、eks-pod-identity ログに「認証情報 xxx の取得に失敗しました」というエラーが表示されました。

この問題の考えられる原因の 1 つは、クラスターに PrivateLink を正しく設定せずに EKS クラスターがプライベートサブネットの下に設定されていることです。クラスターがプライベートネットワークにあるかどうかを確認し、問題に対処するように AWS PrivateLink を設定します。詳細な手順については、「Amazon EKS の使用を開始する」を参照してください。

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

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

ドキュメントの表記規則

EKS クラスターの IAM ロールを有効にする

オプション 2: EKS クラスターでサービスアカウント (IRSA) の IAM ロールを有効にする