翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# EKS クラスターの IAM ロールを有効にする
以下のトピックでは、IAM ロールを有効にするためのオプションについて詳しく説明します。
**Topics**
+ [オプション 1: EKS クラスターで EKS Pod Identity を有効にする](setting-up-enable-IAM.md)
+ [オプション 2: EKS クラスターでサービスアカウント (IRSA) の IAM ロールを有効にする](setting-up-enable-IAM-service-accounts.md)
# オプション 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](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html)」を参照してください。
## 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](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html#pod-id-considerations)」を参照してください。
## EKS クラスターで EKS Pod Identity を準備する
### 必要なアクセス許可が NodeInstanceRole に存在するかどうかを確認します
ノードロール `NodeInstanceRole` には、エージェントが EKS Auth API で `AssumeRoleForPodIdentity` アクションを実行する権限があります。AmazonEKS ユーザーガイドで定義されている [AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/security-iam-awsmanpol.html#security-iam-awsmanpol-amazoneksworkernodepolicy) に以下を追加するか、カスタムポリシーを使用できます。
EKS クラスターが **0.181.0** 以降の eksctl バージョンで作成された場合、必要な `AssumeRoleForPodIdentity` アクセス許可を含む AmazonEKSWorkerNodePolicy がノードロールに自動的にアタッチされます。アクセス許可がない場合は、Pod Identity のロールの引き受けを許可する次のアクセス許可を AmazonEKSWorkerNodePolicy に手動で追加します。このアクセス許可は、EKS Pod Identity エージェントがポッドの認証情報を取得するために必要です。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks-auth:AssumeRoleForPodIdentity"
],
"Resource": [
"*"
],
"Sid": "AllowEKSAUTHAssumeroleforpodidentity"
}
]
}
```
------
### 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 アドオンを作成するには、以下の手順に従います:
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)で Amazon EKS コンソールを開きます。
1. 左のナビゲーションペインで、**[クラスター]** を選択し、次にアドオンを設定するEKS Pod Identity エージェントを選択します。
1. **[アドオン]** タブを選択してください。
1. **[その他のアドオンを入手]** を選択してください。
1. EKS Pod Identity のアドオンボックスの右上にあるボックスを選択し、**[次へ]** を選択します。
1. **[選択したアドオン設定を構成する]** ページの **[バージョン]** ドロップダウンリストで任意のバージョンを選択します。
1. (オプション) **[オプションの設定]** を展開して追加の設定を入力します。例えば、代替のコンテナイメージの場所と `ImagePullSecrets` を指定できます。許可されたキーのある JSON スキーマは、**[アドオン設定スキーマ]** に表示されます。
設定キーと値を **[設定値]** に入力します。
1. [**次へ**] を選択します。
1. エージェントポッドが 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](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html) アクションを使用して EKS Auth API から一時的な認証情報を取得します。これらの認証情報は、コンテナ内で実行する AWS SDKs で使用できます。
詳細については、パブリックドキュメントの前提条件[「Amazon EKS Pod Identity エージェントのセットアップ](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html)」を参照してください。
## ジョブ実行ロールを作成する
### EKS Pod Identity を許可するジョブ実行ロールを作成または更新する
Amazon EMR on EKS でワークロードを実行するには、IAM ロールを作成する必要があります。このドキュメントでは、このロールをジョブ実行ロールと呼びます。IAM ロールの作成方法の詳細については、「IAM ユーザーガイド」の「I[Creating IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html)」を参照してください。
さらに、ジョブ実行ロールに必要なアクセス許可を指定する IAM ポリシーを作成し、このポリシーをロールにアタッチして EKS Pod Identity を有効にしなければなりません。
例えば、次のジョブ実行ロールがあるとします。詳細については、「[Create a job execution role](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html)」を参照してください。
```
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 <
### 前提条件
EKS 管理者ユーザーなどの Pod Identity の関連付けを作成する IAM Identity に、 アクセス許可 `eks:CreatePodIdentityAssociation` と `iam:PassRole` があることを確認します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:CreatePodIdentityAssociation"
],
"Resource": [
"arn:aws:eks:*:*:cluster/*"
],
"Sid": "AllowEKSCreatepodidentityassociation"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::*:role/*"
],
"Condition": {
"StringEquals": {
"iam:PassedToService": "pods.eks.amazonaws.com"
}
},
"Sid": "AllowIAMPassrole"
}
]
}
```
------
### ロールと EMR サービスアカウントの関連付けを作成する
------
#### [ Create EMR role associations through the AWS CLI ]
Kubernetes 名前空間にジョブを送信する場合、管理者はジョブ実行ロールと EMR マネージドサービスアカウントの ID との間に関連付けを作成しなければなりません。EMR マネージドサービスアカウントは、ジョブの送信時に自動的に作成され、ジョブが送信される名前空間にスコープ設定されます。
AWS CLI (バージョン 2.24.0 以上) では、次のコマンドを実行して、ポッド ID とのロールの関連付けを作成します。
以下のコマンドを実行して、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 アカウント間でアクセスを委任](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)する」を参照してください。
------
#### [ 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 セットアップの以下のステップをスキップできます:
+ [EKS クラスターでサービスアカウント (IRSA) の IAM ロールを有効にする](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM.html)
+ [ジョブ実行ロールを作成する](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html)
+ [ジョブ実行ロールの信頼ポリシーを更新する](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html)
次のステップに直接スキップできます: [Amazon EMR on EKS へのアクセス権をユーザーに付与する](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-iam.html)
## ロールの関連付けを削除する
仮想クラスターまたはジョブ実行ロールを削除し、そのサービスアカウントに 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 の使用を開始する](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)」を参照してください。
### ジョブが失敗し、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 の使用を開始する](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)」を参照してください。
# オプション 2: EKS クラスターでサービスアカウント (IRSA) の IAM ロールを有効にする
サービスアカウントの IAM ロール機能は、Amazon EKS バージョン 1.14 以降、および 2019 年 9 月 3 日以降にバージョン1.13 に更新された EKS クラスターで利用できます。この機能を使用するために、既存の EKS クラスターをバージョン 1.14 以降に更新できます。詳細については、「[Amazon EKS クラスターの Kubernetes バージョンの更新](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html)」を参照してください。
クラスターがサービスアカウントの IAM ロールをサポートしている場合、[OpenID Connect](https://openid.net/connect/) 発行者 URL が関連付けられます。この URL は Amazon EKS コンソールで表示することも、次の AWS CLI コマンドを使用して取得することもできます。
**重要**
このコマンドから適切な出力を受け取るには AWS CLI 、 の最新バージョンを使用する必要があります。
```
aws eks describe-cluster --name cluster_name --query "cluster.identity.oidc.issuer" --output text
```
予想される出力は次のようになります。
```
https://oidc.eks..amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E
```
クラスターでサービスアカウントの IAM ロールを使用するには、[eksctl](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-eksctl) または [AWS マネジメントコンソール](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-console) のいずれかを使用して OIDC ID プロバイダーを作成する必要があります。
## `eksctl` を使用してクラスターの IAM OIDC ID プロバイダーを作成するには
以下のコマンドを使用して、`eksctl` のバージョンを確認します。この手順では、`eksctl` をインストール済みで、お使いの `eksctl` のバージョンが 0.32.0 以上であることを前提としています。
```
eksctl version
```
eksctl のインストールまたはアップグレードの詳細については、「[eksctl のインストールまたはアップグレード](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html#installing-eksctl)」を参照してください。
次のコマンドを使用して、クラスターの OIDC ID プロバイダーを作成します。*cluster\$1name* は、独自の値に置き換えてください。
```
eksctl utils associate-iam-oidc-provider --cluster cluster_name --approve
```
## を使用してクラスターの IAM OIDC ID プロバイダーを作成するには AWS マネジメントコンソール
クラスターの Amazon EKS コンソールの説明から OIDC 発行者 URL を取得するか、次の AWS CLI コマンドを使用します。
次のコマンドを使って、 AWS CLIから OIDC 発行者 URL を取得します。
```
aws eks describe-cluster --name --query "cluster.identity.oidc.issuer" --output text
```
次の手順に従って、Amazon EKS コンソールから OIDC 発行者 URL を取得します。
1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。
1. ナビゲーションペインで、**[ID プロバイダー]** を選択し、**[プロバイダーの作成]** をクリックします。
1. [**プロバイダーのタイプ**] で [**Choose a provider type**] を選択してから、[**OpenID Connect**] を選択します。
1. **Provider URL** に、クラスターの OIDC 発行者 URL を貼り付けます。
1. [対象者] に、「sts.amazonaws.com」と入力し、**[次のステップ]** を選択します。
1. プロバイダー情報が正しいことを確認し、[**作成**] を選択して ID プロバイダーを作成します。
# ジョブ実行ロールを作成する
Amazon EMR on EKS でワークロードを実行するには、IAM ロールを作成する必要があります。このドキュメントでは、このロールを*ジョブ実行ロール*と呼びます。IAM ロールの作成方法の詳細については、「IAM ユーザーガイド」の「[IAM ロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html)」を参照してください。
また、ジョブ実行ロールの権限を指定する IAM ポリシーを作成し、その IAM ポリシーをジョブ実行ロールにアタッチする必要があります。
ジョブ実行ロールの次のポリシーでは、リソースターゲット、Amazon S3、および CloudWatch へのアクセスが許可されます。これらのアクセス許可は、ジョブとアクセスログを監視するために必要です。 AWS CLIを使用して同じプロセスを実行するには:
ジョブ実行用の IAM ロールを作成する: EMR がジョブ実行に使用するロールを作成します。これは、EMR ジョブが EKS で実行する時に引き受けるロールです。
```
cat < ~/environment/emr-trust-policy.json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "elasticmapreduce.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
EoF
aws iam create-role --role-name EMRContainers-JobExecutionRole --assume-role-policy-document file://~/environment/emr-trust-policy.json
```
次に、ロールに必要な IAM ポリシーをアタッチして、s3 と cloudwatch にログを書き込むことができるようにしなければなりません。
```
cat < ~/environment/EMRContainers-JobExecutionRole.json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:ListBucket"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
},
{
"Effect": "Allow",
"Action": [
"logs:PutLogEvents",
"logs:CreateLogStream",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams"
],
"Resource": [
"arn:aws:logs:*:*:*"
]
}
]
}
EoF
aws iam put-role-policy --role-name EMRContainers-JobExecutionRole --policy-name EMR-Containers-Job-Execution --policy-document file://~/environment/EMRContainers-JobExecutionRole.json
```
**注記**
アクセス権限は、ジョブ実行ロール内のすべての S3 オブジェクトに付与するのではなく、適切にスコープする必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket"
],
"Sid": "AllowS3Putobject"
},
{
"Effect": "Allow",
"Action": [
"logs:PutLogEvents",
"logs:CreateLogStream",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams"
],
"Resource": [
"arn:aws:logs:*:*:*"
],
"Sid": "AllowLOGSPutlogevents"
}
]
}
```
------
詳細については、[ジョブ実行ロールの使用](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/iam-execution-role.html)、[S3ログ使用のためのジョブ実行の構成](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-s3)、および [CloudWatchログ使用のためのジョブ実行の構成） を参照してください](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-cloudwatch)。
# ジョブ実行ロールの信頼ポリシーを更新する
サービスアカウントの IAM ロール (IRSA) を使用して Kubernetes 名前空間上でジョブを実行する場合、管理者はジョブ実行ロールと EMR マネージドサービスアカウントの ID との間に信頼関係を作成する必要があります。信頼関係は、ジョブ実行ロールの信頼ポリシーを更新することによって作成できます。EMR マネージドサービスアカウントは、ジョブの送信時に自動的に作成され、ジョブが送信される名前空間にスコープ設定されます。
信頼ポリシーを更新するには、次のコマンドを実行します。
```
aws emr-containers update-role-trust-policy \
--cluster-name cluster \
--namespace namespace \
--role-name iam_role_name_for_job_execution
```
詳細については、「[Amazon EMR on EKS でのジョブ実行ロールの使用](iam-execution-role.md)」を参照してください。
**重要**
上記のコマンドを実行するオペレータには、`eks:DescribeCluster`、`iam:GetRole`、`iam:UpdateAssumeRolePolicy` のアクセス許可が必要です。