ECS/EKSでのIAM使用
目次
はじめに
こんにちは。CloudBuildersのじんです。
前回、ECS/EKSのIPアドレスについて書きましたが、今回はIAMについてです。
ECSやEKSについて、クラスター、インスタンス/ノード、サービス/Podといった構成になっており、それぞれにIAMロールが必要となります。IAMの観点から、必要なロールの種類、ポリシーの検討、ロールの設定箇所、設定されたロールの確認方法、アクセス許可観点の動作確認についてまとめてみます。なお、ECS AnywhereやEKSConnectorとOutpostで使用するIAMロールについては割愛します。
ECS：管理用のIAMロール
今回は主に動作に必要なロールを中心に見ていきますが、その前に管理用のIAMポリシーについて触れておきましょう。
AWS管理ポリシーでは、AmazonECS_FullAccessが関連サービスも含め権限が付与されたポリシーとなります。権限を絞っていくには、Actionを絞るのと、Resource/Conditionで条件を付けるのであれば、下記のような単位で考えていきます。
| 対象 | 目的 | 方法 |
| クラスター | クラスターのコンテナインスタンス/デプロイメント/タスク/サービスの管理 | Resourceで対象を限定 |
| コンテナインスタンス | 管理対象コンテナインスタンスの限定 | Resourceで対象を限定 |
| タスク定義 | タスク定義の管理や、タスク定義を使用できるクラスタの限定 | Resourceで対象のタスク定義を限定、Conditionで使用できるクラスターを限定 |
管理用のIAMロールについては、下記の公式リンクに記載があるので、参考にします。
ECS：動作で必要なIAMロール
ECSの動作上必要なIAMロールには下記のような種類があります。このうち、ECSサービスロールは「サービスにリンクされたロール」(Service-Linked Role；SLR)のため、ユーザーが管理/設定する必要がないロールとなります。
このため、動作環境がEC2では、後の3つのロール、Fargateではタスク実行ロールとタスクロールだけを考えれば良いことになります。 この後でそれぞれ見ていきます。
- ECSサービスロール
- EC2インスタンスロール（コンテナインスタンスロール）
- タスク実行ロール
- タスクロール
ECSサービスロール
ECSのサービスがAWSリソースを操作するためのロールです。「サービスにリンクされたロール」(Service-Linked Role；SLR)で、AWSServiceRoleForECSという名前で自動作成されます。
ポリシーとしてはAmazonECSServiceRolePolicyがアタッチされており、許可されているサービスはAuto Scaling/Cloud Map/CloudWatch/CloudWatch Logs/EC2/EC2 AutoScaling/ELB/EventBridge/Route 53/SSMとなります。
EC2インスタンスロール（コンテナインスタンスIAMロール）
ECSのEC2起動タイプを使用する場合のEC2用のロールとなります。EC2インスタンスでECSエージェント、DockerデーモンがCloudWatch Logsへのログの保存や、ECRへのアクセスするために使用します。
マネージメントコンソールで作成する場合、AmazonEC2ContainerServiceforEC2Roleポリシーがアタッチされ、これはECSやECR、CloudWatch Logsのアクセス許可がセットされます。
タスク実行ロール
コンテナエージェントがタスクを実行する際に使用するロールです。ECRやCloudWatch Logsの権限がポリシーとして必要となります。
指定せずにタスク定義を作成すると「ecsTaskExecutionRole」が自動作成されます。
次のタスクロールと信頼関係ポリシー上区別されませんが、こちらはタスクを実行するためのロール、タスクロールはタスク（コンテナ）に付与するロールとなります。
SecretsManagerとKMSを使って環境変数を暗号化する場合は、こちらにアクセス許可が必要となります。
タスクロール
コンテナアプリケーションがAWSリソースにアクセスするためのロールです。タスクからAWSリソースにアクセスしない場合は不要です。
EKSと異なる点は、サービスに直接このロールを割り当てることで、コンテナで動作させるスクリプトやアプリケーションからAWSリソースにアクセスさせることができます。（EKSでは、IAM Roles for Service Accounts(IRSA)やPod Identityが介在する必要があります）
タスクからS3にアクセスするとか、DynamoDBにアクセスするといった場合に、ポリシーを追加します。ECS Execを使う場合は、SSMのアクセス許可が必要となります。
その他
インフラストラクチャロール：インフラストラクチャロールは、下記の3つのパターンがあり、それぞれAWSマネージドポリシーが用意されています。
- EBS ボリュームを Fargate または EC2 起動タイプの Amazon ECS タスクにアタッチする
AmazonECSInfrastructureRolePolicyForVolumes - ECS Service Connect サービス間のトラフィックを暗号化する
AmazonECSInfrastructureRolePolicyForServiceConnectTransportLayerSecurity - VPC LatticeとECSの統合を使用する
AmazonECSInfrastructureRolePolicyForVpcLattice
その他ECS Anywhereで使われるロールもありますが、ここでは割愛します。
ECS：ロールの設定
ここでは、ロールに設定するポリシーについてまとめます。ECSサービスロールについては、SLRのため設定は不要です。
EC2インスタンスロール
EC2インスタンスロールを作成するには、信頼ポリシーのPrincipalのサービスにec2を設定し、AWS管理ポリシーを設定します。ECS Agentやタスクの起動のための権限は、AWS管理ポリシーのAmazonEC2ContainerServiceforEC2Roleで済みますが、ポリシーをカスタマイズして最小限のアクセス許可とする場合は、下記のリンクを参考にカスタムポリシーを作成します。
| 信頼ポリシーのPrincipalのサービス | ec2.amazonaws.com |
| AWS管理ポリシー | AmazonEC2ContainerServiceforEC2Role |
ECRについては、ネットワークがawsvpcの場合は、タスク実行ロールに必要です。
ECS Agentの設定をS3に置いて読み込ませたい場合は、S3の読み込みの権限を付与します。
ECS エージェントの設定変数のリストは下記を参照。ログレベルの設定等で使用します。（起動テンプレートのユーザーデータに直接記載するか、S3を読み込む指定を行います。）
タスク実行ロール
タスク実行ロールを作成するには、下記の信頼ポリシーのPrincipalを設定し、AWS管理ポリシーを設定します。AWS管理ポリシーAmazonECSTaskExecutionRolePolicyで、ECRとCloudWatch Logsに対するアクセス許可を付与することができます。ポリシーをカスタマイズして最小限のアクセス許可とする場合は、下記のリンクを参考にカスタムポリシーを作成します。
| 信頼ポリシーのPrincipalのサービス | ecs-tasks.amazonaws.com |
| AWS管理ポリシー | AmazonECSTaskExecutionRolePolicy |
タスク定義でプライベートレジストリ認証を設定する場合は、Secrets ManageとKMSに対するアクセス許可を付与する必要があります。
また、S3から一括で環境変数を読み込む場合は、S3に対するアクセス許可や、S3をSSE-KMSで暗号化している場合にKMSのアクセス許可を付与する必要があります。
タスクロール
タスクロールは、コンテナアプリケーションがAWSリソースにアクセスしない場合は、作成の必要はありません。作成する場合、信頼ポリシーはタスク実行ロールと共通です。AWS管理ポリシーを使う場合は、アクセスするリソースに応じて選択しますが、できればポリシーを作成して、最小限のアクセス許可とします。下記のリンクを参考にカスタムポリシーを作成します。
| 信頼ポリシーのPrincipalのサービス | ecs-tasks.amazonaws.com |
| AWS管理ポリシー | – |
タスクロールにアクセス許可が必要なパターンとしては、下記のようなものがあります。
- ECS Execを実行する場合は、SSM関連の必要なアクセス許可を追加します。
- タスク（コンテナで実行するアプリケーション）から、S3やDynamo DB、RDSにアクセスする、SQSやLambdaを呼び出す場合には、それぞれのアクセス許可をタスクロールに設定します。
マネージメントコンソールからロールの作成
マネージメントコンソールでロールを作る場合、信頼されたエンティティタイプでECSを指定すると、下記のようなユースケースが表示されるので、整理しておきます。
| ユースケース | デフォルトで選択されるAWS管理ポリシー | 信頼ポリシーのPrincipalのサービス | 上記で対応するロール | |
| 1 | Elastic Container Service | AmazonEC2ContainerServiceRole | ecs.amazonaws.com | ECSサービスロール |
| 2 | Elastic Container Service Autoscale | AmazonEC2ContainerServiceAutoscaleRole | application-autoscaling.amazonaws.com | – |
| 3 | Elastic Container Service Task | なし | ecs-tasks.amazonaws.com | タスク実行ロール タスクロール |
| 4 | EC2 Role for Elastic Container Service | AmazonEC2ContainerServiceforEC2Role | ec2.amazonaws.com | EC2インスタンスロール |
| 5 | Elastic Container Service for VPC Lattice | AmazonECSInfrastructureRolePolicyForVpcLattice | ecs.amazonaws.com | インフラストラクチャロール（VPC Lattice用） |
3はタスク実行ロールとタスクロールを作る際に選択します。
4はコンテナインスタンスのIAMロールを作る際に指定します。
5はVPC LatticeとECSの統合を使用する場合に使用します。
ECS：IAMロールの使用
ここでは、下記のロールの設定箇所についてまとめます。
EC2インスタンスロール
クラスターを作成する際に、インフラストラクチャとして、EC2インスタンスを使用する場合に指定します。
マネージメントコンソールでは、EC2 インスタンスロールとして指定します。
CloudFormationのテンプレートでは、ECSクラスターが使用するキャパシティプロバイダーに指定するAutoScalingGloupのLaunchTemplateのInstanceProfileとして指定（作成）します。
タスク実行ロール、タスクロール
タスク定義を作成する際にタスク実行ロールとタスクロールを指定します。インフラストラクチャがEC2でもFargateでも同様です。
マネージメントコンソールでは、タスク定義を作成する際に指定します。タスクロールは必須ではなく、コンテナからAWSリソースにアクセスしない場合は指定する必要はありません。
CloudFormationのテンプレートでも、タスク定義を作成する際に、ExecutionRoleArn、TaskRoleArnとして指定します。
インフラストラクチャロール
サービスの作成時にボリューム、VPC Lattice、Service Connect(TLS化が必要な場合のみ)を使用する場合に設定します。
マネージメントコンソールでは、サービスやタスクを作成する際のオプションで設定します。
CloudFormationのテンプレートは、サービスやタスク定義を作成する際に、Service ServiceManagedEBSVolumeConfigurationやService VpcLatticeConfiguration、Service ServiceConnectTlsConfigurationでロールを指定します。
ECS：ロールの確認方法
ここではIAMロールを設定した後に確認する方法や、動作確認についてまとめます。
ECSサービスロール
ECSサービスロールはSLRですが、下記の方法で確認できます。
マネージメントコンソールで確認するには、クラスター→対象のクラスター→サービス→対象のサービス→設定とネットワーク→ネットワーク設定のところに設定されたサービスロールが表示されます。
CLIでは、describe-servicesでクラスタとサービス指定で確認することができます。
$ aws ecs describe-services --cluster ClusterName --services ServiceName --query services[].roleArn --output text
arn:aws:iam::123456789012:role/aws-service-role/ecs.amazonaws.com/AWSServiceRoleForECSEC2インスタンスロール
コンテナインスタンスのIAMロールは、実際にはECSクラスターが使用するキャパシティプロバイダーのAutoScalingの設定となりますので、ECSのマネージメントコンソールから確認するには、リンクを何回か辿る必要があります。
クラスター→対象のクラスター→インフラストラクチャタブ→ASG(AutoScalingGroup)のリンク→起動テンプレートのリンク→起動テンプレートのバージョンの詳細で[高度な詳細]→IAMインスタンスプロフィール
または、実際に起動しているコンテナインスタンスのロールを確認しても良いので、上記のASG(AutoScalingGroup)のリンク→インスタンス管理→インスタンスIDのリンク→→インスタンスのセキュリティタブでIAMロールを確認
もちろん、AutoScalingGroupの名前にクラスタ名が含まれるので、そこから直接確認することや、起動しているインスタンスのNameタグが「 Instance – クラスタ名」となるので、そちらから直接確認ができます。
CLIでは、このNameタグを元に確認する例を挙げておきます。
$ aws ec2 describe-instances --filters "Name=tag:Name,Values=*ClusterName" --query Reservations[].Instances[].[InstanceId] --output text
i-015b96ed7367fxxxx
$ aws ec2 describe-instances --instance-ids i-015b96ed7367fxxxx --query 'Reservations[].Instances[].IamInstanceProfile.Arn' --output text
arn:aws:iam::123456789012:instance-profile/EC2InstanceRoleNameタスク実行ロール、タスクロール
マネージメントコンソールで確認するには、タスク定義に設定されたタスク実行ロール、タスクロールを確認するには、タスク定義→対象のタスク→対象のリビジョンから確認できます。
サービス側で確認するには、クラスター→対象のクラスター→サービスでタスク定義へのリンクがあるので、そこからタスク定義の使用されているリビジョンで上記と同様に確認ができます。
CLIでは、describe-servicesでタスク定義を確認し、タスク定義からロールを確認することができます。
$ aws ecs describe-services --cluster ClusterName --services ServiceName --query services[].taskDefinition --output text
arn:aws:ecs:ap-northeast-1:123456789012:task-definition/EcsTaskDefinition:1
$ aws ecs describe-task-definition --task-definition arn:aws:ecs:ap-northeast-1:123456789012:task-definition/EcsTaskDefinition:1 --query "taskDefinition.{taskRoleArn:taskRoleArn, executionRoleArn:executionRoleArn}"
{
"taskRoleArn": "arn:aws:iam::123456789012:role/TaskRoleName",
"executionRoleArn": "arn:aws:iam::123456789012:role/TaskExecRoleName"
}なお、awscliをタスクで実行し、sts get-caller-identityを実行することでタスクロールを確認することも可能です。
タスク定義例
{
"taskDefinition": {
"taskDefinitionArn": "arn:aws:ecs:ap-northeast-1:123456789012:task-definition/ECSTaskDefinition:1",
"containerDefinitions": [
{
"name": "awscli",
"image": "public.ecr.aws/aws-cli/aws-cli:latest",
"cpu": 0,
"portMappings": [],
"essential": true,
"command": [
"sts",
"get-caller-identity"
],インフラストラクチャロール
マネージメントコンソールで確認するには、クラスター→対象のクラスター→対象のサービスのリンク→設定とネットワーク→デプロイ時に設定されたボリュームにボリュームロールのリンクがあります。（ボリュームの場合）
CLIでは、describe-servicesで確認することができます。
$ aws ecs describe-services --cluster ClusterName --services ServiceName --query "services[].deployments[].volumeConfigurations[].managedEBSVolume.roleArn" --output text
arn:aws:iam::123456789012:role/RoleForECSInfrastructureNameECS：IAMロール動作確認
ここでは、ロールの設定が正しいことを確認してみます。方法は設定したアクセス許可や環境によりますので、下記は例となります。
EC2インスタンスロール
インスタンスが起動し、ECSでコンテナインスタンスとして認識されていることを確認します。
マネージメントコンソールで確認するには、クラスター→対象のクラスター→インフラストラクチャ→コンテナインスタンスの一覧で確認できます。
CLIでは、list-container-instancesで確認することができます。
$ aws ecs list-container-instances --cluster ClusterName --output text
CONTAINERINSTANCEARNS arn:aws:ecs:ap-northeast-1:123456789012:container-instance/ClusterName/48e77cafb6db4b85b70868d31880xxxxタスク実行ロール
タスクが起動していることを確認し、タスク定義でログ設定をしている場合は、ログがCloudWatch Logsに指定したロググループに出力されていることを確認します。
マネージメントコンソールで確認するには、クラスター→対象のクラスター→サービス→サービスでタスクが実行されていることで確認できます。
CLIでは、list-tasksで確認することができます。（サービス名は省略可能）
$ aws ecs list-tasks --cluster ClusterName --service-name ServiceName --desired-status RUNNING --output text
TASKARNS arn:aws:ecs:ap-northeast-1:123456789012:task/ClusterName/6209fc04007843bdad733fdc4b31xxxxタスクロール
タスクからAWSリソースにアクセスできていることは、コンテナ上でアクセスすることにより確認できます。
下記は、一例ですがタスク定義のコンテナ定義（部分）となります。
{
"taskDefinition": {
"taskDefinitionArn": "arn:aws:ecs:ap-northeast-1:123456789012:task-definition/ECSTaskDefinition:1",
"containerDefinitions": [
{
"name": "awscli",
"image": "public.ecr.aws/aws-cli/aws-cli:latest",
"cpu": 0,
"portMappings": [],
"essential": true,
"command": [
"s3",
"ls",
"s3://bucketname"
],実行されたタスクのログから結果を確認できます。（CloudWatch Logsのロググループから確認することで、タスクロールの確認にもなります。）
また、暗号化した環境変数（secrets）を使用する場合、タスク実行ポリシーにSecretsManageとKMSのアクセス許可をします。下記にポリシーとタスク定義例（部分）、ECS Exec（execute-command）で確認する例を挙げておきます。なお、ECS Execを実行するには、タスクポリシー側にssmmessagesのアクセス許可が必要です。後にリンクを挙げておきます。
タスク実行ポリシー例
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"kms:Decrypt"
],
"Resource": [
"arn:aws:secretsmanager:region:aws_account_id:secret:secret_name",
"arn:aws:kms:region:aws_account_id:key/key_id"
]
}
]
}タスク定義例（secrets部分）
"containerDefinitions": [
{
"secrets": [
{
"name": "secretskey",
"valueFrom": "arn:aws:secretsmanager:region:aws_account_id:secret:secret_name"
}
],下記のようにecs execute-commandでコンテナ内から確認することも可能です。
$ aws ecs execute-command --cluster ClusterName --task task --container ContainerName --interactive --command ""/bin/sh""
The Session Manager plugin was installed successfully. Use the AWS CLI to start a session.
# echo $secretskey
{""secretskey"":""secretsValue""}ECS Execを使用する場合のタスクポリシーについては下記を参照して下さい。
環境変数の暗号化については下記を参照して下さい。
EKS：管理用のIAMロール
EKSについても、動作に必要なロールを中心に見ていきますが、その前に管理用のIAMポリシーについて触れておきましょう。
EKSの管理用ポリシーは、AWS管理ポリシーでは、提供されていないため、下記を参考に付与する必要があります。
リンクにある内容は、直接的にEKSのクラスターを作成するアクセス許可の他、後に挙げる「サービスにリンクされたロール」(Service-Linked Role；SLR)を作成するアクセス許可と、クラスターで使われる各種ロールをPassRoleするアクセス許可が必要です。関連するリソースに対するアクセス許可は、EKSクラスターのIAMロールがアクセス許可を持つことになりますが、各種ロールを別途準備する必要があります。
アクセス許可を絞っていくには、Actionを絞るのと、Resource/Conditionで条件を付けるのであれば、下記のような単位で考えていきます。
| 対象 | 目的 | 方法 |
| クラスター | クラスターの管理 | Resourceで対象を限定 |
| ノードグループ | 管理対象ノードグループの限定 | Resourceで対象を限定 |
EKSの場合は、上記より細かいKubernetes内の権限については、アクセスエントリまたはaws-auth ConfigMapでIAMと連携することができます。
従来のアクセス制御は、aws-auth ConfigMapで行うものでしたが、こちらは現在非推奨になっています。（連携方法を含め下記リンクを参照）
こちらは、ConfigMapでIAMロール（またはユーザー）とKubernetesグループを結び付けることができます。Kubernetesの権限を設定するClusterRoleBinding/RoleBindingについては下記を参照して下さい
現在はアクセスエントリを使用する方法が推奨となります。こちらはConfigMapを介さずに設定することができます。（指定したKubernetesグループ名に対してClusterRoleBinding/RoleBinding設定は必要）
アクセスエントリで設定できるアクセスポリシーは、下記を参照して下さい。
なお、クラスタ認証モードで上記のアクセスエントリまたはaws-auth ConfigMapのどちらを使うか（併用も可能）を設定することができます。
EKS：動作で必要なIAMロール
サービスにリンクされたロール
EKSの動作上必要なIAMロールのうち、「サービスにリンクされたロール」(Service-Linked Role；SLR)は下記のようなものがあります。これはユーザーが管理/設定する必要がないロールとなりますので参考程度に見て頂ければと思います。
クラスター管理ロール（AWSServiceRoleForAmazonEKS）
クラスター管理用のロールで、ポリシーAmazonEKSServiceRolePolicyがアタッチされ、ネットワークやセキュリティグループ、ログ等のアクセス許可があります。
ノードグループ管理ロール（AWSServiceRoleForAmazonEKSNodegroup）
ノードグループ（EC2）管理用のロールで、ポリシーAWSServiceRoleForAmazonEKSNodegroupがアタッチされて、AutoScaling、セキュリティグループ、起動テンプレート、および IAMインスタンスプロファイルへのアクセス許可があります。
Fargate管理ロール（AWSServiceRoleForAmazonEKSForFargate）
Fargate管理用のロールで、ポリシーAmazonEKSForFargateServiceRolePolicyがアタッチされ、ネットワーク関連にアクセス許可があります。
EKSで必要なロールは、SLRの他に多くの種類がありますので、順番に見ていきます。
下記のロールは作成したリソースから他のAWSリソースを使用する際に必要となるので、SLRとは別途必要となります。
- クラスタIAMロール
- ノードIAMロール
- ポッド実行ロール
- ポッド用ロール
クラスターIAMロール
クラスター作成時に付与するロールです。EKS クラスター（コントロールプレーン）が AWS API を実行するためのロールとなります。EC2に対するアクセス許可が必要となります。
ノード IAMロール
コンピューティング環境としてEC2を使う場合に必要なロールです。ノードとはEC2で動くWorkerノードのことで、ノード上ではkuberet（kubernetesのpod管理エージェント）やアドオンが動作するため、このロールをが必要となります。EKS、EC2やECRに対するアクセス許可が必要です。
ポッド実行ロール
コンピューティング環境としてFargateを使う場合に必要なロールです。Fargateの場合は、EC2と異なりノードに関連するアクセス許可は不要で、ECRに対するアクセス許可が必要です。
ポッド用ロール
ECSではサービスロールという、コンテナで実行するアプリケーションからAWSサービスを利用するためのロールがありますが、EKSでも同様のことを行うことができます。
またEKSの場合は、直接コンテナアプリケーションが動作するポッド（ECSで言うサービス）で使うだけでなく、アドオンなどでも使用するため、Kubernetesにアクセス許可を渡す場合もこのロールを使用します。このため、コンテナアプリケーションで使うAWSリソースへのアクセス許可の他、CloudWatch LogsやSecretをKMSやSecretsManagerと連携させる場合のアクセス許可も必要となります。
IAMロールを割り当てる方法は下記のいずれかとなります。
IAM Roles for Service Accounts(IRSA)
OIDCとiamserviceaccountを使用して、IAMと連携する方法です。もう一つのPod Identityは実行環境がEC2の場合のみとなりますので、FargateとEC2共に使える方式はこちらとなります。
Pod Identity
こちらは比較的新しい方法で、2023年11月に利用可能になったもので、実行環境がEC2の場合に利用することができます。
最終的にService AccountでPodに関連づけることになりますが、途中の設定はEKSの設定となるためEKS管理者にとっては管理しやすい方法かも知れません。
オートモードで使用するIAMロール
EKSは、2025年12月からAWSの管理範囲を広げクラスターの構築や管理を簡易化するオートモードが使えるようになりました。
オートモードで使用するロールは、上記で挙げたクラスターIAMロールとノード IAMロールとなります。
その他
その他、EKSConnector用とOutpost用のSLR（AWSServiceRoleForAmazonEKSConnector、AWSServiceRoleForAmazonEKSLocalOutpost）、EKSConnectorを使う場合のAgent用ロールがありますが、今回は割愛します。
EKS：ロールの設定
ここでは、ロールに設定するポリシーについてまとめます。
クラスターIAMロール
クラスターIAMロールを作成するには、下記の信頼ポリシーのPrincipalのサービスを設定し、AWS管理ポリシーを設定します。ポリシーをカスタマイズして最小限のアクセス許可とする場合は、下記のリンクを参考にカスタムポリシーを作成します。
| 信頼ポリシーのPrincipalのサービス | eks.amazonaws.com |
| AWS管理ポリシー | AmazonEKSClusterPolicy |
ノード IAMロール
ノードIAMロールは、Workerノードに割り当てるロールなので、EC2の信頼ポリシーと同様です。また、オートモードで使う場合も同様です。AWS管理ポリシーとしては、下記を設定すれば良いです。
| 信頼ポリシーのPrincipalのサービス | ec2.amazonaws.com |
| AWS管理ポリシー | AmazonEKSWorkerNodePolicy AmazonEC2ContainerRegistryPullOnly AmazonEKS_CNI_Policy →Amazon VPC CNI plugin for Kubernetes アドオン用のポリシー； 下記で挙げるポッド用ロールでService Accountに対してロールを関連付けることが推奨 |
AutoScalingを使用するには、関連するアクセス許可が必要です。下記が参考になるかと思います。
ポッド実行ロール
ポッド実行ロールを作成するには、下記の信頼ポリシーのPrincipalのサービスを設定し、AWS管理ポリシーを設定します。信頼関係ポリシーを編集しConditionでSourceArnを絞るには、下記のリンクを参考にします。
| 信頼ポリシーのPrincipalのサービス | eks-fargate-pods.amazonaws.com |
| AWS管理ポリシー | AmazonEKSFargatePodExecutionRolePolicy |
ポッド用ロール
ポッド用ロールを使用するためには、IAMの設定だけでなく、下記のいずれか（Fargateの場合はIRSAのみ利用可能）の設定が必要となります。
IAM Roles for Service Accounts(IRSA)
IRSAを使用する場合のロールはeksctl create iamserviceaccountコマンドを実行した時に作成されます。（eksctlコマンドは他もそのケースが多いですが、CloudFormationのスタックが作成されますので、クラスターを削除する場合も、deleteコマンドを使うかスタックを削除しないと作成されたリソース（この場合はロール）が残るので、削除する場合は注意して下さい。）
IRSAを使用する場合の流れは下記となります。詳しくは、後のリンクを参照して下さい。
- IAM OIDC プロバイダーの作成
- Podに適用したいポリシーを作成する
- eksctl create iamserviceaccountを実行する
（このコマンドでポッド用ロールの作成とServiceAccountの作成、ServiceAccountとポッド用ロールの関連付け設定） - Podのdeploy時にService Accountを指定する
Pod Identity
Pod Identity用ロールとしては、信頼関係をpods.eks.amazonaws.comとして設定します。
設定の流れとしては下記のようなものです。詳しくは、後のリンクを参照して下さい。
- EKS Pod Identity エージェントを導入
- 必要なIAMロール/ポリシーを作成
- Pod Identityの関連付け（ロールとNameSpace/ServiceAccountを関連付け）を作成
- Podのdeploy時にService Accountを指定する
参考：EKSでは、CloudWatch Logsにポッドのログを出力する場合や、Secrets Managerを使う場合もポッド用ロールを使用します。
CloudWatch Logsにポッドのログを出力する場合の下記を参考にして下さい。上記のIRSAを使用しDaemonSetからログを連携します。
ASCP(secrets-store-csi-provider-aws)を使いIRSAまたはPod Identityと統合してSecrets Managerを使う場合は下記と参考にして下さい。
オートモードで使用するIAMロール
EKSは、2025年12月からAWSの管理範囲を広げクラスターの構築や管理を簡易化するオートモードが使えるようになりました。
オートモードで使用するロールは、上記で挙げたクラスターIAMロールとノード IAMロールとなります。
このうち、クラスターIAMロールは、オートモードがコンピューティング、ストレージ、ネットワーク部分の管理を行うため、下記のAWS管理ポリシー（または同等のアクセス許可）が必要となります。
- AmazonEKSBlockStoragePolicy
- AmazonEKSClusterPolicy
- AmazonEKSComputePolicy
- AmazonEKSLoadBalancingPolicy
- AmazonEKSNetworkingPolicy
また、信頼ポリシーにsts:AssumeRoleの他に、sts:TagSessionも必要となります。
ノード IAMロールについては、オートモードの際も同様ですが、AWSマネージドポリシーで下記の2つが必要となります。
- AmazonEC2ContainerRegistryPullOnly
- AmazonEKSWorkerNodeMinimalPolicy
マネージメントコンソールからロールの作成
マネージメントコンソールでロールを作る場合、信頼されたエンティティタイプでEKSを指定すると、下記のようなユースケースが表示されるので、整理しておきます。
| ユースケース | デフォルトで選択される許可ポリシー | 信頼ポリシーのPrincipalのサービス | 上記で対応するロール | |
| 1 | EKS – Service | AmazonEKSServiceRolePolicy | eks.amazonaws.com | クラスタ管理ロール |
| 2 | EKS – Cluster | AmazonEKSClusterPolicy | eks.amazonaws.com | クラスターIAMロール |
| 3 | EKS – Nodegroup | AWSServiceRoleForAmazonEKSNodegroup | eks-nodegroup.amazonaws.com | ノードグループ管理ロール |
| 4 | EKS – Fargate pod | AmazonEKSFargatePodExecutionRolePolicy | eks-fargate-pods.amazonaws.com | ポッド用ロール |
| 5 | EKS – Fargate profile | AmazonEKSForFargateServiceRolePolicy | eks-fargate.amazonaws.com | Fargate管理ロール |
| 6 | EKS – Connector | AmazonEKSConnectorServiceRolePolicy | eks-connector.amazonaws.com | EKSConnector用SLR |
| 7 | EKS Local – Outpost | AmazonEKSLocalOutpostServiceRolePolicy | outposts.eks-local.amazonaws.com | Outpost用SLR |
| 8 | EKS – Pod Identity | なし | pods.eks.amazonaws.com | ポッド用ロール |
| 9 | EKS – Auto Cluster | AmazonEKSBlockStoragePolicy AmazonEKSClusterPolicy AmazonEKSComputePolicy AmazonEKSLoadBalancingPolicy AmazonEKSNetworkingPolicy | eks.amazonaws.com | クラスターIAMロール (オートモード用) |
| 10 | EKS – Auto Node | AmazonEC2ContainerRegistryPullOnly AmazonEKSWorkerNodeMinimalPolicy | ec2.amazonaws.com | ノード IAMロール (オートモード用) |
2はクラスタIAMロール、4はポッド実行ロールを作る際に選択します（ノード IAMロールを作る場合は、ユースケースでEC2を選択するか、10を選択して、作成後にカスタマイズすることになります）。
8はポッド用ロール(Pod Identity)を作る際に指定します。9、10はオートモードを使用する場合に、推奨のAWS管理ポリシー付でクラスターIAMロール、ノード IAMロールを作成する際に選択します。
EKS：IAMロールの使用
ここでは、下記のロールの設定箇所についてまとめます。
クラスターIAMロール
クラスターを作成する際に、クラスターIAM ロールを指定します。
マネージメントコンソールでは、クラスター設定で指定します。
CloudFormationのテンプレートでは、ClusterのRoleArnで指定します。
ノード IAMロール
クラスターのコンピューティング環境にEC2を使う場合に、ノードグループを作成しますが、その際に、ノードIAM ロールを指定します。
マネージメントコンソールでは、ノードグループ設定で指定します。
CloudFormationのテンプレートでは、NodegroupのNodeRoleで指定します。
ポッド実行ロール
クラスターのコンピューティング環境にFargateを使う場合に、Fageteプロファイルを作成しますが、その際に、ポッド実行ロールを指定します。
マネージメントコンソールでは、プロファイル設定で指定します。
CloudFormationのテンプレートでは、FargateProfileの PodExecutionRoleArnで指定します。
ポッド用ロール
ポッド用のIAMロールは、下記いずれかの方式で、Service AccountとIAMロールを関連付けます。Kubernetes的には、下記の方法でService Accountを作成し、Annotationを設定しています。
実際のポッドへの適用は、Deployment/Job/Daemonsetを作成する際に、Service Accountを指定することで使うことができます。
なお、Pod IdentityはFargateでは使用できません。
IAM Roles for Service Accounts(IRSA)
IRSAを使用する場合のロールはeksctl create iamserviceaccountコマンドを実行する際に、ロール名を指定することで、Pod（Podで使うService Account）で使うロールを作成できます。
EKS Pod Identity
Pod Identityの関連付けの際に、Pod（Podで使うService Account）で使うロールを指定します。
マネージメントコンソールでは、クラスター→クラスタ名→アクセスタブ→Pod Identityの関連付けから関連付けの作成ができ、この際にIAMロールを指定します。アドオンもマネージメントコンソールから設定できます
CLIでは、eks create-pod-identity-associationコマンドで関連付けを作成することができます。
EKS：ロールの確認方法
ここではIAMロールを設定した後に確認する方法や、動作確認についてまとめます。
クラスターIAM ロール
マネージメントコンソールで確認するには、クラスター→対象のクラスター→概要で設定されたクラスターIAM ロールが表示されます。
CLIでは、eks describe-servicesでクラスタ名指定で確認することができます。
$ aws eks describe-cluster --name ClusterName --query "cluster.roleArn" --output text
arn:aws:iam::123456789012:role/ClusterIAMRoleNameノード IAMロール
マネージメントコンソールで確認するには、クラスター→対象のクラスター→コンピューティング→ノードグループ→対象のノードグループ→詳細でノードIAMロールが確認できます。（表示されない場合は、VPC CNIアドオンがインストールされていないか、VPC CNI用のロールが割り当てられていないことが考えられます）
アクセスエントリが有効になっている場合は、クラスター→対象のクラスター→アクセスでIAMアクセスエントリ→タイプが「EC2」のもので確認ができます。
CLIでは、eks describe-nodegroupでクラスタ名とノードグループ名指定で確認することができます。
$ aws eks describe-nodegroup --cluster-name ClusterName --nodegroup-name NodeGroupName --query "nodegroup.nodeRole" --output text
arn:aws:iam::123456789012:role/NodeIAMRoleNameポッド実行ロール
マネージメントコンソールで確認するには、クラスター→対象のクラスター→コンピューティング→Fargateプロファイル→対象のFargateプロファイル→ポッド実行ロールARNが確認できます。
アクセスエントリが有効になっている場合は、アクセスタブでIAMアクセスエントリで確認できます。
CLIでは、eks describe-nodegroupでクラスタ名とノードグループ名指定で確認することができます。
$ aws eks describe-fargate-profile --cluster-name ClusterName --fargate-profile-name FargateProfileName --query "fargateProfile.podExecutionRoleArn" --output text
arn:aws:iam::123456789012:role/PodExecutionRoleNameポッド用ロール
IAM Roles for Service Accounts(IRSA)
マネージメントコンソールで確認するには、クラスター→対象のクラスター→リソース→ワークロードのポッド→対象のポッド→コンテナ→環境変数でポッドに設定されたロールが確認できます。
CLIでは、eks create-pod-identity-associationコマンドpodに割り当てられたロールを確認することができます。
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
eks-sample-linux-deployment-xxxxxxxxxxxxxxxx 1/1 Running 0 14m
$ kubectl describe pod eks-sample-linux-deployment-xxxxxxxxxxxxxxxx | grep AWS_ROLE_ARN:
AWS_ROLE_ARN: arn:aws:iam::123456789012:role/PodRoleNamePod Identity
Pod IdentityではSTSで一時トークンが割り当てられおり、マネージメントコンソールのPodの情報やkubectl describeでは確認できないため、ここではCLIでpodで使用しているService Account、Namespaceを確認し、Pod Identityの割り当てからロールを確認してみましょう。
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
eks-sample-linux-deployment-xxxxxxxxxxxxxxxx 1/1 Running 0 14m
$ kubectl describe pod eks-sample-linux-deployment-xxxxxxxxxxxxxxxx | grep ""Service Account""
Service Account: ServiceAccount
$ kubectl describe pod eks-sample-linux-deployment-xxxxx | grep Namespace
Namespace: Namespace
$ aws eks list-pod-identity-associations --cluster-name ClusterName --namespace Namespace --service-account ServiceAccount --query associations[].associationId --output text
a-rgtvea4vmghvxxxxx
$ aws eks describe-pod-identity-association --cluster-name ClusterName --association-id a-rgtvea4vmghvxxxxx --query association.roleArn --output text
arn:aws:iam::123456789012:role/PodRoleNameEKS：IAMロール動作確認
ここでは、ロールの設定が正しいことを確認してみます。方法は設定したアクセス許可や環境によりますので、下記は例となります。
クラスターIAM ロール
クラスターが正常に作成できれば問題ありません。オートモードの場合は、ビルドインノードプールが正常に作成されることも確認します。
ビルドインプールは、マネージメントコンソールでは、クラスター→対象のクラスター→コンピューティングで確認できます。
CLIでは、kubectl get nodepoolコマンドで確認することができます。
$ kubectl get nodepool
NAME NODECLASS NODES READY AGE
general-purpose default 0 True 2m8s
system default 2 True 2m8sノード IAMロール
ノードグループが作成されることを確認します。とくにAutoScaling関連のアクセス許可が必要となるため
AutoScalingグループが構成されて、インスタンスが起動していることを確認します。
マネージメントコンソールでは、クラスター→対象のクラスター→コンピューティングで確認できます。
ECRのアクセス許可もノードIAMロールで設定しているため下記はイメージでECRを指定し、kubectlコマンドでPodがデプロイできることを確認する例です。
cat <<EOF > eks-sample-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: eks-sample-deployment
namespace: default
labels:
app: eks-sample-app
spec:
replicas: 1
selector:
matchLabels:
app: eks-sample-app
template:
metadata:
labels:
app: eks-sample-app
spec:
containers:
- name: nginx
image: 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/testecr:nginx-test0.1
ports:
- name: http
containerPort: 80
EOF
$ kubectl apply -f eks-sample-deployment.yaml
deployment.apps/eks-sample-deployment created
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
eks-sample-deployment-xxxxxxxxxxxxxxxx 1/1 Running 0 12sポッド実行ロール
Fargateプロファイルが作成されていることを確認します。
ECRのアクセス許可をポッド実行ロールで設定しているため、kubectlコマンドでPodがデプロイできることを確認します。
※podの確認方法はノードIAMロールと同様です。
ポッド用ロール
ポッドでAWSリソースにアクセスできることを確認します。
ECRのアクセス許可もノードIAMロールで設定しているため、kubectlコマンドでPodがデプロイできることを確認します。
下記は、AWS CLIを実行可能なイメージでAWSコマンドを実行させる例となります。
cat <<EOF > eks-test-pod-awscli.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: eks-test-pod-awscli
namespace: eks-sample-app
spec:
template:
metadata:
labels:
job-name: eks-test-pod-awscli
spec:
restartPolicy: Never
serviceAccountName: test-service-account
containers:
- name: aws-cli
image: public.ecr.aws/aws-cli/aws-cli:latest
command: ["sh", "-c"]
args:
- aws s3 ls s3://test-s3-bucket-20250204;
EOF下記でログを確認します。対象のS3のサブフォルダが表示される例となります。
$ kubectl logs -l job-name=eks-test-pod-awscli
PRE subfolder/
関連記事
-
ECS/EKSのIPアドレス設計 -
AWS CDK + ecspresso + CodeDeployを使用してECSをデプロイする -
GitHub Actions + ecspressoでCI/CDパイプラインを構築する