**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# Amazon EKS の Identity and Access Management
AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御するのに役立つ AWS のサービスです。IAM 管理者は、誰の (サインイン) を*認証*し、誰による Amazon EKS リソースの使用を*承認する* (アクセス許可を付与する) かを制御します。IAM は、AWS のサービスで追加料金は発生しません。
## オーディエンス
AWS Identity and Access Management (IAM) の使用方法は、Amazon EKS で行う作業によって異なります。
**サービスユーザー** – ジョブを実行するために Amazon EKS サービスを使用する場合は、管理者から必要なアクセス許可と認証情報が与えられます。さらに多くの Amazon EKS 機能を使用して作業を行う場合は、追加のアクセス許可が必要になることがあります。アクセスの管理方法を理解すると、管理者から適切なアクセス許可をリクエストするのに役に立ちます。Amazon EKS の機能にアクセスできない場合は、「[IAM のトラブルシューティング](security-iam-troubleshoot.md)」を参照してください。
**サービス管理者** – 社内の Amazon EKS リソースを管理しているユーザーには、通常、Amazon EKS への完全なアクセス権限があります。サービスのユーザーがどの Amazon EKS 機能やリソースにアクセスするかを決めるのは管理者の仕事です。その後、IAM 管理者にリクエストを送信して、サービスユーザーの権限を変更する必要があります。このページの情報を確認して、IAM の基本概念を理解してください。企業が Amazon EKS で IAM を利用する方法については、「[アマゾン EKS で IAM を使用する方法](security-iam-service-with-iam.md)」を参照してください。
**IAM 管理者** – IAM 管理者には、Amazon EKS へのアクセスを管理するポリシーの作成方法を、詳細に把握する必要が生じる場合があります。IAM で使用可能な、Amazon EKS アイデンティティベースのポリシーの例を確認するには、「[Amazon EKS でのアイデンティティベースのポリシーの例](security-iam-id-based-policy-examples.md)」を参照してください。
## アイデンティティを使用した認証
認証とは、アイデンティティ認証情報を使用して AWS にサインインする方法です。ユーザーは、AWS アカウントのルートユーザーもしくは IAM ユーザーとして、または IAM ロールを引き受けることによって、*認証を受ける* (AWS にサインインする) 必要があります。
ID ソースから提供された認証情報を使用して、フェデレーティッドアイデンティティとして AWS にサインインできます。AWSフェデレーティッドアイデンティティの例としては、IAM アイデンティティセンター (IAM アイデンティティセンター) ユーザー、貴社のシングルサインオン認証、Google または Facebook の認証情報などがあります。フェデレーティッド ID としてサインインする場合、IAM ロールを使用して、前もって管理者により ID フェデレーションが設定されています。フェデレーションを使用して AWSにアクセスする場合、間接的にロールを引き受けることになります。
ユーザーのタイプに応じて、AWS マネジメントコンソール または AWS アクセスポータルにサインインできます。AWS へのサインインの詳細については、AWS サインインユーザーガイドの「[AWS アカウントにサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。
プログラムを使用して AWS にアクセスする場合、AWSは Software Development Kit (SDK) とコマンドラインインターフェイス (CLI) を提供し、認証情報を使用してリクエストに暗号で署名します。AWS ツールを使用しない場合は、リクエストに自分で署名する必要があります。リクエストに署名する推奨方法の使用については、「*IAM ユーザーガイド*」の「[AWS API リクエストの署名](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html)」を参照してください。
使用する認証方法を問わず、追加セキュリティ情報の提供をリクエストされる場合もあります。例えば、AWS は、アカウントのセキュリティを強化するために多要素認証 (MFA) を使用することをお勧めします。詳細については、「*AWS IAM Identity Center ユーザーガイド*」の「[多要素認証 (MFA)](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html)」および「*IAM ユーザーガイド*」の「[AWS での多要素認証 (MFA) の使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)」を参照してください。
### AWS アカウントのルートユーザー
AWS アカウントを作成する場合は、このアカウントのすべての AWS サービスとリソースに対して完全なアクセス権を持つ 1 つのサインインアイデンティティから始めます。このアイデンティティは AWS アカウント*ルートユーザー*と呼ばれ、アカウントの作成に使用したメールアドレスとパスワードでのサインインによりアクセスされます。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー資格情報は保護し、ルートユーザーでしか実行できないタスクを実行するときに使用します。ルートユーザーとしてサインインする必要があるタスクの完全なリストについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。
### IAM ユーザーとグループ
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*IAM ユーザー*は、単一のユーザーまたはアプリケーションに対する特定の許可を持つ AWS アカウント内のアイデンティティです。可能であれば、パスワードやアクセスキーなどの長期的な認証情報を保有する IAM ユーザーを作成する代わりに、一時的な認証情報を使用することをお勧めします。ただし、IAM ユーザーでの長期的な認証情報が必要な特定のユースケースがある場合は、アクセスキーをローテーションすることをお勧めします。詳細については、「*IAM ユーザーガイド*」の「[長期的な認証情報を必要とするユースケースのためにアクセスキーを定期的にローテーションする](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials)」を参照してください。
[IAM グループ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、IAM ユーザーのコレクションを指定するアイデンティティです。グループとしてサインインすることはできません。グループを使用して、複数のユーザーに対して一度に権限を指定できます。多数のユーザーグループがある場合、グループを使用することで権限の管理が簡単になります。例えば、*IAMAdmins* という名前のグループを設定して、そのグループに IAM リソースを管理する許可を与えることができます。
ユーザーは、ロールとは異なります。ユーザーは 1 人の人または 1 つのアプリケーションに一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。ユーザーには永続的な長期の認証情報がありますが、ロールでは一時的な認証情報が提供されます。詳細については、「*IAM ユーザーガイド*」の「(ロールではなく) [IAM ユーザーの作成が適している場合](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose)」を参照してください。
### IAM ロール
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*IAM ロール*は、特定のアクセス許可を持つ、AWS アカウント内のアイデンティティです。これは IAM ユーザーに似ていますが、特定のユーザーに関連付けられていません。[ロールを切り替える](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)ことによって、AWS マネジメントコンソールで IAM ロールを一時的に引き受けることができます。ロールを引き受けるには、AWS CLI または AWS API オペレーションを呼び出すか、カスタム URL を使用します。ロールを使用する方法の詳細については、「*IAM ユーザーガイド*」の「[IAM ロールの使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html)」を参照してください。
IAM ロールと一時的な認証情報は、次の状況で役立ちます:
+ **フェデレーションユーザーアクセス** – フェデレーティッド ID に許可を割り当てるには、ロールを作成してそのロールの許可を定義します。フェデレーテッド ID が認証されると、その ID はロールに関連付けられ、ロールで定義されている許可が付与されます。フェデレーションの詳細については、「*IAM ユーザーガイド*」の「[サードパーティーアイデンティティプロバイダー向けロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html)」を参照してください。IAM Identity Center を使用する場合は、許可セットを設定します。アイデンティティが認証後にアクセスできるものを制御するため、IAM Identity Center は、権限セットを IAM のロールに関連付けます。アクセス許可セットの詳細については、「*AWS IAM Identity Center ユーザーガイド*」の「[アクセス許可セット](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)」を参照してください。
+ **一時的な IAM ユーザー権限** - IAM ユーザーまたはロールは、特定のタスクに対して複数の異なる権限を一時的に IAM ロールで引き受けることができます。
+ **クロスアカウントアクセス** - IAM ロールを使用して、自分のアカウントのリソースにアクセスすることを、別のアカウントの人物 (信頼済みプリンシパル) に許可できます。ロールは、クロスアカウントアクセスを許可する主な方法です。ただし、一部の AWS のサービスでは、 (ロールをプロキシとして使用する代わりに) リソースにポリシーを直接アタッチできます。クロスアカウントアクセスにおけるロールとリソースベースのポリシーの違いについては、「*IAM ユーザーガイド*」の「[IAM でのクロスアカウントのリソースへのアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)」を参照してください。
+ **クロスサービスアクセス** – 一部の AWS のサービスは、AWS の他のサービスの機能を使用します。例えば、サービスで呼び出しを行うと、通常そのサービスによって Amazon EC2 でアプリケーションが実行されたり、Amazon S3 にオブジェクトが保存されたりします。サービスは、呼び出し元のプリンシパルの許可、サービスロール、サービスリンクロールを使用してこれを行う場合があります。
+ **転送アクセスセッション (FAS)** – IAM ユーザーまたはロールを使用して AWS でアクションを実行するユーザーは、プリンシパルと見なされます。一部のサービスを使用する際に、アクションを実行することで、別のサービスの別のアクションがトリガーされることがあります。FAS は、AWS サービスを呼び出すプリンシパルの権限を、AWS サービスのリクエストと合わせて使用し、ダウンストリームのサービスに対してリクエストを行います。FAS リクエストは、サービスが、完了するために他の AWS サービスまたはリソースとのやりとりを必要とするリクエストを受け取ったときにのみ行われます。この場合、両方のアクションを実行するためのアクセス許可が必要です。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。
+ **サービスロール** - サービスがユーザーに代わってアクションを実行するために引き受ける [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)です。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除することができます。詳細については、『*IAM ユーザーガイド*』の「[AWS のサービスにアクセス許可を委任するロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)」を参照してください。
+ **サービスリンクロール** – サービスリンクロールは、AWS のサービスにリンクされているサービスロールの一種です。サービスがロールを引き受け、ユーザーに代わってアクションを実行できるようになります。サービスにリンクされたロールは、AWS アカウント内に表示され、サービスによって所有されます。IAM 管理者は、サービスリンクロールのアクセス許可を表示できますが、編集することはできません。
+ **Amazon EC2 で実行されているアプリケーション** – EC2 インスタンスで実行され、AWS CLI または AWS API リクエストを作成しているアプリケーションの一時的な認証情報を管理するには、IAM ロールを使用します。これは、EC2 インスタンス内でのアクセスキーの保存に推奨されます。AWS ロールを EC2 インスタンスに割り当て、そのすべてのアプリケーションで使用できるようにするには、インスタンスに添付されたインスタンスプロファイルを作成します。インスタンスプロファイルにはロールが含まれ、EC2 インスタンスで実行されるプログラムは一時的な認証情報を取得できます。詳細については、*IAM ユーザーガイド*の[Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用して許可を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)を参照してください。
IAM ロールと IAM ユーザーのどちらを使用するかについては、*IAM ユーザーガイド*の[(IAM ユーザーではなく) IAM ロールをいつ作成したら良いのか?](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role)を参照してください。
## ポリシーを使用したアクセス権の管理
AWS でアクセスを制御するには、ポリシーを作成して AWS ID またはリソースにアタッチします。ポリシーは AWS のオブジェクトであり、アイデンティティやリソースに関連付けて、これらのアクセス許可を定義します。AWS は、プリンシパル (ユーザー、ルートユーザー、またはロールセッション) がリクエストを行うと、これらのポリシーを評価します。ポリシーでの権限により、リクエストが許可されるか拒否されるかが決まります。大半のポリシーは JSON ドキュメントとして AWSに保存されます。JSON ポリシードキュメントの構造と内容の詳細については、「*IAM ユーザーガイド*」の「[JSON ポリシー概要](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)」を参照してください。
管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
デフォルトでは、ユーザーやロールに権限はありません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。その後、管理者はロールに IAM ポリシーを追加し、ユーザーはロール引き継ぐことができます。
IAM ポリシーは、オペレーションの実行方法を問わず、アクションの許可を定義します。例えば、`iam:GetRole` アクションを許可するポリシーがあるとします。このポリシーがあるユーザーは、AWS マネジメントコンソール、AWS CLI、または AWS API からロール情報を取得できます。
### アイデンティティベースポリシー
アイデンティティベースのポリシーは、IAM ユーザーグループ、ユーザーのグループ、ロールなど、アイデンティティにアタッチできる JSON 許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件をコントロールします。アイデンティティベースのポリシーを作成する方法については、「IAM ユーザーガイド**」の「[IAM ポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。
アイデンティティベースのポリシーは、さらに*インラインポリシー*または*マネージドポリシー*に分類できます。インラインポリシーは、単一のユーザー、グループ、またはロールに直接埋め込まれています。管理ポリシーは、AWS アカウント内の複数のユーザー、グループ、およびロールにアタッチできるスタンドアロンポリシーです。管理ポリシーには、AWS 管理ポリシーとカスタマー管理ポリシーが含まれます。マネージドポリシーまたはインラインポリシーのいずれかを選択する方法については、*IAM ユーザーガイド*の[マネージドポリシーとインラインポリシーの比較](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline)を参照してください。
### リソースベースのポリシー
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM *ロールの信頼ポリシー*や Amazon S3 *バケットポリシー*があげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスをコントロールできます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーで、[[specify a principal]](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) (プリンシパルを指定する) 必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーティッドユーザー、または AWS のサービスを含めることができます。
リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーでは、IAM からの AWS マネージド型ポリシーを使用することはできません。
### アクセスコントロールリスト (ACL)
アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
Amazon S3、AWS WAF、および Amazon VPC は、ACL をサポートするサービスの例です。ACL の詳細については、*Amazon Simple Storage Service デベロッパーガイド* の [アクセスコントロールリスト (ACL) の概要](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) を参照してください。
### その他のポリシータイプ
AWS では、他の一般的ではないポリシータイプをサポートしています。これらのポリシータイプでは、より一般的なポリシータイプで付与された最大の権限を設定できます。
+ **アクセス許可の境界** - アクセス許可の境界は、アイデンティティベースポリシーによって IAM エンティティ (IAM ユーザーまたはロール) に付与できる権限の上限を設定する高度な機能です。エンティティにアクセス許可の境界を設定できます。結果として得られるアクセス許可は、エンティティのアイデンティティベースポリシーとそのアクセス許可の境界の共通部分になります。`Principal` フィールドでユーザーまたはロールを指定するリソースベースのポリシーでは、アクセス許可の境界は制限されません。これらのポリシーのいずれかを明示的に拒否した場合、権限は無効になります。アクセス許可の境界の詳細については、「*IAM ユーザーガイド*」の「[IAM エンティティのアクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。
+ **サービスコントロールポリシー (SCP)** – SCP とは、AWS Organizations 内の組織または組織単位 (OU) に対し、アクセス許可の上限を指定するための JSON ポリシーです。AWSOrganizations は、ビジネスが所有する複数の AWS アカウントを、グループ化および一元管理するためのサービスです。組織内のすべての機能を有効にすると、サービスコントロールポリシー (SCP) を一部またはすべてのアカウントに適用できます。SCP はメンバーアカウントのエンティティに対するアクセス許可を制限します (各 AWS アカウントルートユーザーなど)。Organizations と SCP の詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。
+ **セッションポリシー** - セッションポリシーは、ロールまたはフェデレーションユーザーの一時的なセッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。結果として得られるセッションの許可は、ユーザーまたはロールのアイデンティティベースポリシーとセッションポリシーの共通部分です。また、リソースベースのポリシーから権限が派生する場合もあります。これらのポリシーのいずれかを明示的に拒否した場合、権限は無効になります。詳細については、「*IAM ユーザーガイド*」の「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」を参照してください。
### 複数のポリシータイプ
1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成されるアクセス許可を理解するのがさらに難しくなります。複数のポリシータイプが関連するとき、リクエストを許可するかどうかを AWS が決定する方法の詳細については、*IAM ユーザーガイド*の[ポリシーの評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)を参照してください。
# アマゾン EKS で IAM を使用する方法
IAM を使用して アマゾン EKS へのアクセスを管理する前に、アマゾン EKS で使用できる IAM 機能について理解しておく必要があります。アマゾン EKS およびその他の AWS のサービスが IAM と連携する方法の概要を把握するには*IAM ユーザーガイド* の「[IAM と連携する AWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
**Topics**
+ [アマゾン EKS のアイデンティティベースのポリシー](#security-iam-service-with-iam-id-based-policies)
+ [アマゾン EKS でのリソースベースのポリシー](#security-iam-service-with-iam-resource-based-policies)
+ [アマゾン EKS タグに基づいた認可](#security-iam-service-with-iam-tags)
+ [アマゾン EKS でのIAM 役割](#security-iam-service-with-iam-roles)
## アマゾン EKS のアイデンティティベースのポリシー
IAM アイデンティティベースのポリシーでは許可または拒否するアクションとリソース、またアクションを許可または拒否する条件を指定できます。アマゾン EKS は特定のアクション、リソース、および条件キーをサポートしています。JSON ポリシーで使用するすべての要素については「*IAM ユーザーガイド*」の「[IAM JSON ポリシーエレメントのリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)」を参照してください。
### アクション
管理者は AWS JSON ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。ポリシーアクションの名前は通常、関連する AWS API オペレーションと同じです。一致する API オペレーションのない*アクセス許可のみのアクション*など、いくつかの例外があります。また、ポリシーに複数のアクションが必要なオペレーションもあります。これらの追加アクションは*依存アクション*と呼ばれます。
このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。
アマゾン EKS のポリシーアクションはアクションの前にプレフィックス `eks:` を付加します。例えば、アマゾン EKS クラスターについて説明する情報を入手するアクセス許可を他のユーザーに付与するにはポリシーに `DescribeCluster` アクションを含めます。ポリシーステートメントには`Action` または `NotAction` 要素を含める必要があります。
単一のステートメントに複数のアクションを指定するには次のようにコンマで区切ります。
```
"Action": ["eks:action1", "eks:action2"]
```
ワイルドカード (\$1) を使用して複数アクションを指定できます。例えば、`Describe` という単語で始まるすべてのアクションを指定するには次のアクションを含めます。
```
"Action": "eks:Describe*"
```
アマゾン EKS アクションの一覧については「サービス認可リファレンス」の「[アマゾン エラスティックKubernetesサービス で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)」を参照してください。
### リソース
管理者は AWS JSON ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件**下で**アクション**を実行できるかということです。
`Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ステートメントには`Resource` または `NotResource` 要素を含める必要があります。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。これは*リソースレベルの許可*と呼ばれる特定のリソースタイプをサポートするアクションに対して実行できます。
オペレーションのリスト化など、リソースレベルの許可をサポートしないアクションの場合はステートメントがすべてのリソースに適用されることを表示するワイルドカード (\$1) を使用します。
```
"Resource": "*"
```
アマゾン EKS クラスターリソースの ARN は次のようになります。
```
arn:aws:eks:region-code:account-id:cluster/cluster-name
```
ARN の形式の詳細については「[アマゾン リソースネーム (ARN) と AWS のサービスの名前空間](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)」を参照してください。
例えば、ステートメントで *マイクラスター* という名前のクラスターを指定するには次の ARN を使用します。
```
"Resource": "arn:aws:eks:region-code:111122223333:cluster/my-cluster"
```
特定のアカウントと AWS リージョンに属するすべてのクラスターを指定するにはワイルドカード (\$1) を使用します。
```
"Resource": "arn:aws:eks:region-code:111122223333:cluster/*"
```
リソースの作成を含む、一部の アマゾン EKS アクションは特定のリソースで実行できません。このような場合はワイルドカード \$1を使用する必要があります。
```
"Resource": "*"
```
アマゾン EKS リソースタイプとその ARN の一覧については「サービス認可リファレンス」の「[アマゾン エラスティックKubernetesサービス で定義されるリソース](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-resources-for-iam-policies)」を参照してください。各リソースの ARN を、どのアクションで指定できるかについては「[アマゾン エラスティックKubernetesサービス で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)」を参照してください。
### 条件キー
アマゾン EKS では独自の条件キーが定義されており、また一部のグローバル条件キーの使用がサポートされています。すべての AWS グローバル条件キーを確認するには、*IAM ユーザーガイド*の「[AWS グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。
OpenID Connect プロバイダーをクラスターに関連付ける場合に条件キーを設定できます。詳細については、「[IAM ポリシーの例](authenticate-oidc-identity-provider.md#oidc-identity-provider-iam-policy)」を参照してください。
すべての Amazon EC2 アクションは `aws:RequestedRegion` および `ec2:Region` 条件キーをサポートします。詳細については「[例: 特定の AWS リージョンへのアクセスの制限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region)」を参照してください。
Amazon EKS 条件キーのリストについては「*サービス認可リファレンス*」の「[Amazon エラスティックKubernetesサービス によって定義された条件](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys)」を参照してください。条件キーを使用できるアクションとリソースについては「[Amazon エラスティックKubernetesサービス で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)」を参照してください。
### 例
アマゾン EKS でのアイデンティティベースのポリシーの例は「[Amazon EKS でのアイデンティティベースのポリシーの例](security-iam-id-based-policy-examples.md)」でご確認ください。
Amazon EKS クラスターを作成すると、このクラスターを作成する [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)にはAmazon EKS コントロールプレーンのクラスター役割ベースアクセスコントロール (RBAC) 設定で、`system:masters` 許可が自動的に付与されます。このプリンシパルは表示可能な設定の中には表示されません。したがって、どのプリンシパルが最初にクラスターを作成したのかを追跡する必要があります。追加の IAM プリンシパルがクラスターとインタラクションできるようにするには Kubernetes 内の `aws-auth ConfigMap` を編集し、`aws-auth ConfigMap` で指定した `group` の名前を使用して、Kubernetes `rolebinding` または `clusterrolebinding` を作成します。
ConfigMap の使用に関する詳細については「[IAM ユーザーおよびロールに Kubernetes API へのアクセスを付与する](grant-k8s-access.md)」を参照してください。
## アマゾン EKS でのリソースベースのポリシー
アマゾン EKS では リソースベースのポリシーはサポートされていません。
## アマゾン EKS タグに基づいた認可
タグはアマゾン EKS リソースにアタッチすることも、アマゾン EKS へのリクエストの際に渡すこともできます。タグに基づいてアクセスを制御するには`aws:ResourceTag/key-name `、`aws:RequestTag/key-name `、または `aws:TagKeys` の条件キーを使用して、ポリシーの[条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)でタグ情報を提供します。アマゾン EKS リソースのタグ付けの詳細については「[タグを使用して Amazon EKS リソースを整理する](eks-using-tags.md)」を参照してください。条件キーでタグを使用できるアクションの詳細については「[Service Authorization Reference](https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html)」(サービス認可のリファレンス) の「[アマゾン EKS で定義されたアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)」を参照してください。
## アマゾン EKS でのIAM 役割
[IAM 役割](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) は特定のアクセス許可を持つ、AWS アカウント内のエンティティです。
### アマゾン EKS での一時的な認証情報の使用
一時的な認証情報を使用して、フェデレーションでサインインする、IAM 役割を引き受ける、またはクロスアカウント役割を引き受けることができます。一時的なセキュリティ認証情報を取得するには[AssumeRole または [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) などの AWS](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) STS API オペレーションを呼び出します。
アマゾン EKS では一時認証情報が使用できます。
### サービスにリンクされたロール
[サービスリンクロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)は、AWS サービスが他のサービスのリソースにアクセスしてお客様の代わりにアクションを完了することを許可します。サービスリンクロールは IAM アカウント内に表示され、サービスによって所有されます。管理者はサービスにリンクされたロールのアクセス許可を確認できますが、編集することはできません。
アマゾン EKS はサービスにリンクされた役割をサポートしています。アマゾン EKS でのサービスにリンクされた役割の作成または管理の詳細については「[Amazon EKS でのサービスにリンクされたロールの使用](using-service-linked-roles.md)」を参照してください。
### サービス役割
この機能により、ユーザーに代わってサービスが[サービスロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-role)を引き受けることが許可されます。この役割により、サービスがお客様に代わって他のサービスのリソースにアクセスし、アクションを完了することが許可されます。サービスロールはIAM アカウントに表示され、アカウントによって所有されます。つまり、IAM 管理者はこの役割の権限を変更できます。ただし、これを行うことにより、サービスの機能が損なわれる場合があります。
アマゾン EKS ではサービス役割がサポートされています。詳細については[Amazon EKS クラスター の IAM ロール](cluster-iam-role.md)および[Amazon EKS ノードの IAM ロール](create-node-role.md)を参照してください。
### アマゾン EKS での IAM 役割の選択
アマゾン EKS でクラスターリソースを作成する場合は他のいくつかの AWS リソースに アマゾン EKS が自動的にアクセスすることを許可するための役割を、ユーザーが選択する必要があります。以前に作成したサービス役割がある場合、アマゾン EKS により、選択できる役割のリストが提示されます。アマゾン EKS 管理のポリシーがアタッチされた役割を選択することが重要です。詳細については[既存のクラスターロールの確認](cluster-iam-role.md#check-service-role)および[既存のノードロールの確認](create-node-role.md#check-worker-node-role)を参照してください。
# Amazon EKS でのアイデンティティベースのポリシーの例
デフォルトでは、IAM ユーザーおよびロールには Amazon EKS リソースを作成または変更するアクセス許可はありません。また、AWS マネジメントコンソール、AWS CLI、または AWS API を使用してタスクを実行することもできません。IAM 管理者は、ユーザーとロールに必要な、指定されたリソースで特定の API オペレーションを実行する権限をユーザーとロールに付与する IAM ポリシーを作成する必要があります。続いて、管理者はそれらの権限が必要な IAM ユーザーまたはグループにそのポリシーをアタッチする必要があります。
これらの JSON ポリシードキュメント例を使用して IAM のアイデンティティベースのポリシーを作成する方法については、『*IAM ユーザーガイド*』の「[JSON タブでのポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor)」を参照してください。
Amazon EKS クラスターを作成すると、このクラスターを作成する [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)には、Amazon EKS コントロールプレーンのクラスターロールベースアクセスコントロール (RBAC) 設定で、`system:masters` 許可が自動的に付与されます。このプリンシパルは表示可能な設定の中には表示されません。したがって、どのプリンシパルが最初にクラスターを作成したのかを追跡する必要があります。追加の IAM プリンシパルがクラスターとインタラクションできるようにするには Kubernetes 内の `aws-auth ConfigMap` を編集し、`aws-auth ConfigMap` で指定した `group` の名前を使用して、Kubernetes `rolebinding` または `clusterrolebinding` を作成します。
ConfigMap の使用に関する詳細については「[IAM ユーザーおよびロールに Kubernetes API へのアクセスを付与する](grant-k8s-access.md)」を参照してください。
**Topics**
+ [ポリシーに関するベストプラクティス](#security-iam-service-with-iam-policy-best-practices)
+ [Amazon EKS コンソールの使用](#security-iam-id-based-policy-examples-console)
+ [自分のアクセス許可の表示を IAM ユーザーに許可する](#security-iam-id-based-policy-examples-view-own-permissions)
+ [AWS Cloud に Kubernetes クラスターを作成する](#policy-create-cluster)
+ [Outpost にローカル Kubernetes クラスターを作成する](#policy-create-local-cluster)
+ [Kubernetes クラスターの更新](#policy-example1)
+ [すべてのクラスターの一覧表示または説明](#policy-example2)
## ポリシーに関するベストプラクティス
ID ベースのポリシーは、ユーザーのアカウント内で誰かが Amazon EKS リソースを作成、アクセス、または削除できるどうかを決定します。これらのアクションを実行すると、AWS アカウントに追加料金が発生する可能性があります。アイデンティティベースポリシーを作成したり編集したりする際には、以下のガイドラインと推奨事項に従ってください:
+ **AWS マネージドポリシーを使用して開始し、最小特権の許可に移行する** – ユーザーとワークロードへの許可の付与を開始するには、多くの一般的なユースケースのために許可を付与する AWS マネージドポリシーを使用します。これらは AWS アカウントで使用できます。ユースケースに固有の AWS カスタマー管理ポリシーを定義して、アクセス許可を絞り込むことをお勧めします。詳細については、*IAM ユーザーガイド* の [AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) または [ジョブ機能の AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) を参照してください。
+ **最小特権を適用する** – IAM ポリシーでアクセス許可を設定する場合は、タスクの実行に必要な許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、*最小特権アクセス許可*とも呼ばれています。IAM を使用して許可を適用する方法の詳細については、*IAM ユーザーガイド* の [IAM でのポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) を参照してください。
+ **IAM ポリシーで条件を使用してアクセスをさらに制限する** - ポリシーに条件を追加して、アクションやリソースへのアクセスを制限できます。たとえば、ポリシー条件を記述して、すべてのリクエストを SSL を使用して送信するように指定できます。また、AWS CloudFormation などの特定の AWS サービスを介して使用する場合、条件を使用してサービスアクションへのアクセスを許可することもできます。詳細については、*IAM ユーザーガイド*」の「[IAM JSON ポリシー要素: 条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)」を参照してください。
+ **IAM Access Analyzer を使用して IAM ポリシーを検証し、安全で機能的なアクセス権限を確保する** - IAM Access Analyzer は、新規および既存のポリシーを検証して、ポリシーが IAM ポリシー言語 (JSON) および IAM のベストプラクティスに準拠するようにします。IAM アクセスアナライザーは 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーの作成をサポートします。詳細については、*IAM ユーザーガイド*の[IAM Access Analyzer ポリシーの検証](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)を参照してください。
+ **多要素認証 (MFA) を要求する** – AWS アカウントで IAM ユーザーまたはルートユーザーを要求するシナリオがある場合は、セキュリティを強化するために MFA をオンにします。API オペレーションが呼び出されるときに MFA を必須にするには、ポリシーに MFA 条件を追加します。詳細については、*IAM ユーザーガイド*の[MFA 保護 API アクセスの設定](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)を参照してください。
IAM でのベストプラクティスの詳細については、*IAM ユーザーガイド*の[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)を参照してください。
## Amazon EKS コンソールの使用
Amazon EKS コンソールにアクセスするには、[IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)に最小限の許可のセットが必要です。これらの許可により、プリンシパルは AWS アカウントの Amazon EKS リソースの詳細をリストおよび表示できます。最小限必要な許可よりも制限されたアイデンティティベースのポリシーを作成すると、そのポリシーをアタッチしたプリンシパルに対してはコンソールが意図したとおりに機能しません。
これらの IAM プリンシパルがまだ Amazon EKS コンソールを使用できるようにするには、`AmazonEKSAdminPolicy` など、独自の名前を付けてポリシーを作成します。ポリシーをプリンシパルにアタッチします。詳細については、*「IAM User Guide」*(IAM ユーザーガイド) の[「Adding and removing IAM identity permissions」](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)(IAM ID アクセス許可の追加と削除) を参照してください。
**重要**
次のポリシー例では、プリンシパルはコンソールの **[設定]** タブで情報を表示できます。AWS マネジメントコンソール で **[概要]** タブと **[リソース]** タブの情報を表示するには、プリンシパルに Kubernetes の許可も必要です。詳細については、「[必要なアクセス許可](view-kubernetes-resources.md#view-kubernetes-resources-permissions)」を参照してください。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "eks.amazonaws.com"
}
}
}
]
}
```
AWS CLI または AWS API のみを呼び出すプリンシパルには、最小限のコンソール許可を付与する必要はありません。代わりに、実行する API オペレーションと一致するアクションのみへのアクセスを許可します。
## 自分のアクセス許可の表示を IAM ユーザーに許可する
この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を IAM ユーザーに許可するポリシーの作成方法を示します。このポリシーには、コンソールで、または AWS CLI もしくは AWS API を使用してプログラム的に、このアクションを完了するための許可が含まれています。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## AWS Cloud に Kubernetes クラスターを作成する
このポリシー例には、*us-west-2* AWS リージョンに *my-cluster* という名前の Amazon EKS クラスターを作成するために必要な最小限の許可が含まれています。AWS リージョンを、クラスターを作成する AWS リージョンに置き換えることができます。AWS マネジメントコンソール で **[ポリシーのアクションはリソースレベルの許可をサポートしていないため、`All resources` を選択する必要があります]** という警告が表示された場合、無視しても問題ありません。アカウントに *AWSServiceRoleForAmazonEKS* ロールが既にある場合は、ポリシーから `iam:CreateServiceLinkedRole` アクションを削除できます。アカウントで Amazon EKS クラスターを作成したことがある場合、削除していない限り、このロールは既に存在します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:CreateCluster",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::111122223333:role/aws-service-role/eks.amazonaws.com/AWSServiceRoleForAmazonEKS",
"Condition": {
"ForAnyValue:StringEquals": {
"iam:AWSServiceName": "eks"
}
}
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/cluster-role-name"
}
]
}
```
## Outpost にローカル Kubernetes クラスターを作成する
このポリシー例には、*us-west-2* AWS リージョンの Outpost 上に *my-cluster* という名前の Amazon EKS ローカルクラスターを作成するために必要な最小限の許可が含まれています。AWS リージョンを、クラスターを作成する AWS リージョンに置き換えることができます。AWS マネジメントコンソール で **[ポリシーのアクションはリソースレベルの許可をサポートしていないため、`All resources` を選択する必要があります]** という警告が表示された場合、無視しても問題ありません。アカウントに `AWSServiceRoleForAmazonEKSLocalOutpost` ロールがすでにある場合、ポリシーから `iam:CreateServiceLinkedRole` アクションを削除できます。アカウントで Outpost 上に Amazon EKS ローカルクラスターを作成したことがある場合、削除していない限り、このロールはすでに存在します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:CreateCluster",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
},
{
"Action": [
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"iam:GetRole"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::111122223333:role/aws-service-role/outposts.eks-local.amazonaws.com/AWSServiceRoleForAmazonEKSLocalOutpost"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole",
"iam:ListAttachedRolePolicies"
],
"Resource": "arn:aws:iam::111122223333:role/cluster-role-name"
},
{
"Action": [
"iam:CreateInstanceProfile",
"iam:TagInstanceProfile",
"iam:AddRoleToInstanceProfile",
"iam:GetInstanceProfile",
"iam:DeleteInstanceProfile",
"iam:RemoveRoleFromInstanceProfile"
],
"Resource": "arn:aws:iam::*:instance-profile/eks-local-*",
"Effect": "Allow"
}
]
}
```
## Kubernetes クラスターの更新
このポリシー例には、us-west-2 AWS リージョンに *my-cluster* という名前のクラスターを更新するために必要な最小限の許可が含まれています。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:UpdateClusterVersion",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
}
]
}
```
## すべてのクラスターの一覧表示または説明
このポリシーの例には、アカウント内のすべてのクラスターを一覧表示して記述するために必要な最小限の許可が含まれています。`update-kubeconfig` AWS CLI コマンドを使用するには、[IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)がクラスターを一覧表示および記述できる必要があります。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:DescribeCluster",
"eks:ListClusters"
],
"Resource": "*"
}
]
}
```
# Amazon EKS でのサービスにリンクされたロールの使用
Amazon エラスティック Kus サービス はAWS アイデンティティとアクセス管理 (IAM) の[サービberneteスにリンクされた役割](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)を使用します。サービスにリンクされた役割はAmazon EKS に直接リンクされた一意のタイプの IAM 役割です。サービスにリンクされた役割はAmazon EKS で事前定義されています。この役割にはサービスがユーザーに代わって他の AWS のサービスを呼び出すために必要な、すべてのアクセス許可が付与されています。
**Topics**
+ [Amazon EKS クラスターのロールの使用](using-service-linked-roles-eks.md)
+ [アマゾン EKS ノードグループでのロールの使用](using-service-linked-roles-eks-nodegroups.md)
+ [Amazon EKS Fargate プロファイルの役割の使用](using-service-linked-roles-eks-fargate.md)
+ [ロールを使用して Kubernetes クラスターを Amazon EKS に接続する](using-service-linked-roles-eks-connector.md)
+ [アウトポスト で アマゾン EKS ローカルクラスターの役割の使用](using-service-linked-roles-eks-outpost.md)
+ [Amazon EKS ダッシュボードのロールの使用](using-service-linked-roles-eks-dashboard.md)
# Amazon EKS クラスターのロールの使用
アマゾン エラスティック Kus サービス はAWS アイデンティティとアクセス管理 (IAM) の[サービberneteスにリンクされた役割](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)を使用します。サービスにリンクされた役割はアマゾン EKS に直接リンクされた一意のタイプの IAM 役割です。サービスにリンクされた役割はアマゾン EKS で事前定義されています。この役割にはサービスがユーザーに代わって他の AWS のサービスを呼び出すために必要な、すべてのアクセス許可が付与されています。
サービスにリンクされた役割を使用することで、必要なアクセス許可を手動で追加する必要がなくなるため、アマゾン EKS の設定が簡単になります。サービスにリンクされた役割のアクセス許可はアマゾン EKS により定義されます。特に指定されている場合を除き、アマゾン EKS のみがその役割を引き受けることができます。定義される許可は信頼ポリシーと許可ポリシーに含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
サービスリンク役割はまずその関連リソースを削除しなければ削除できません。これにより、リソースへのアクセス許可を不用意に削除することが防止され、アマゾン EKS リソースが保護されます。
サービスにリンクされた役割をサポートする他のサービスについては「[IAM と連動する AWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照し、[**サービス-linked roles**] (サービスにリンクされた役割) の列内で [**Yes**] (はい) と表記されたサービスを確認してください。サービスにリンクされた役割に関するドキュメントをサービスで表示するには[**はい**] リンクを選択してください。
## アマゾン EKS でのサービスにリンクされた役割のアクセス許可
Amazon EKS は、`AWSServiceRoleForAmazonEKS` という名前のサービスにリンクされたロールを使用します。このロールにより、Amazon EKS はアカウント内のクラスターを管理できます。アタッチされたポリシーにより、ロールはネットワークインターフェイス、セキュリティグループ、ログ、VPC のリソースを管理できるようになります。
**注記**
`AWSServiceRoleForAmazonEKS` サービスにリンクされたロールは、クラスターの作成に必要なロールとは異なります。詳細については「[Amazon EKS クラスター の IAM ロール](cluster-iam-role.md)」を参照してください。
`AWSServiceRoleForAmazonEKS` サービスリンク役割は役割の引き受けについて以下のサービスを信頼します。
+ `eks.amazonaws.com`
役割のアクセス許可ポリシーは指定したリソースに対して以下のアクションを実行することを アマゾン EKS に許可します。
+ [アマゾンEKSサービスロールポリシー](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html)
サービスにリンクされた役割の作成、編集、削除を IAM エンティティ (ユーザー、グループ、役割など) に許可するにはアクセス許可を設定する必要があります。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。
## アマゾン EKS でのサービスにリンクされた役割の作成
サービスリンク役割を手動で作成する必要はありません。AWS マネジメントコンソール、AWS CLI、または AWS API でクラスターを作成すると、アマゾン EKS によってサービスリンク役割が作成されます。
このサービスリンク役割を削除した後で再度作成する必要が生じた場合は同じ方法でアカウントに役割を再作成できます。サービスにリンクされた役割はクラスターの作成時に アマゾン EKS で自動的に再作成されます。
## アマゾン EKS でのサービスにリンクされた役割の編集
アマゾン EKS では`AWSServiceRoleForAmazonEKS` のサービスにリンクされた役割を編集することはできません。サービスにリンクされた役割を作成すると、多くのエンティティによって役割が参照される可能性があるため、役割名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については『*IAM ユーザーガイド*』の「[サービスにリンクされた役割の編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。
## アマゾン EKS でのサービスにリンクされた役割の削除
サービスリンク役割が必要な機能またはサービスが不要になった場合にはその役割を削除することをお勧めします。そうすることで、モニタリングや保守が積極的に行われていない未使用のエンティティを排除できます。ただし、手動で削除する前に、サービスリンク役割をクリーンアップする必要があります。
### サービスリンク役割のクリーンアップ
IAM を使用してサービスにリンクされた役割を削除するには最初に、その役割で使用されているリソースをすべて削除する必要があります。
**注記**
リソースの削除を試みた際に、対応する役割が アマゾン EKS サービスで使用されている場合、削除が失敗することがあります。失敗した場合は数分待ってから操作を再試行してください。
1. [アマゾン EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで **[Clusters]** (クラスター) を選択してください。
1. クラスターにノードグループまたは Fargate プロファイルがある場合は、クラスターを削除する前にそれらを削除する必要があります。詳細については「[クラスターからマネージドノードグループを削除する](delete-managed-node-group.md)」および「[Fargate プロファイルを削除する](delete-fargate-profile.md)」を参照してください。
1. [**Clusters (クラスター)**] ページで、削除するクラスターを選択し、[**Delete (削除)**] を選択してください。
1. 削除確認ウィンドウにクラスター名を入力し、[**Delete (削除)**] を選択してください。
1. この手順をアカウント内の他のすべてのクラスターに対して繰り返します。すべての削除操作が完了するまで待ちます。
### サービスリンク役割の手動による削除
サービスにリンクされた役割 `AWSServiceRoleForAmazonEKS` を削除するにはIAM コンソール、AWS CLI、または AWS API を使用します。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割の削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。
## Amazon EKS のサービスにリンクされた役割がサポートされるリージョン
Amazon EKS ではこのサービスを利用できるすべてのリージョンで、サービスにリンクされた役割の使用がサポートされます。詳細については「[Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html)」(Amazon EKS エンドポイントとクォータ) を参照してください。
# アマゾン EKS ノードグループでのロールの使用
アマゾン EKS はAWS アイデンティティとアクセス管理 (IAM) の[サービスにリンクされた役割](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)を使用します。サービスにリンクされた役割はアマゾン EKS に直接リンクされた一意のタイプの IAM 役割です。サービスにリンクされた役割はアマゾン EKS で事前定義されています。この役割にはサービスがユーザーに代わって他の AWS のサービスを呼び出すために必要な、すべてのアクセス許可が付与されています。
サービスにリンクされた役割を使用することで、必要なアクセス許可を手動で追加する必要がなくなるため、アマゾン EKS の設定が簡単になります。サービスにリンクされた役割のアクセス許可はアマゾン EKS により定義されます。特に指定されている場合を除き、アマゾン EKS のみがその役割を引き受けることができます。定義される許可は信頼ポリシーと許可ポリシーに含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
サービスリンク役割はまずその関連リソースを削除しなければ削除できません。これにより、リソースへのアクセス許可を不用意に削除することが防止され、アマゾン EKS リソースが保護されます。
サービスにリンクされた役割をサポートする他のサービスについては「[IAM と連動する AWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照し、[**サービス-linked roles**] (サービスにリンクされた役割) の列内で [**Yes**] (はい) と表記されたサービスを確認してください。サービスにリンクされた役割に関するドキュメントをサービスで表示するには[**はい**] リンクを選択してください。
## アマゾン EKS でのサービスにリンクされた役割のアクセス許可
アマゾン EKS は`AWSServiceRoleForAmazonEKSNodegroup` という名前のサービスにリンクされたロールを使用します。このロールにより、アマゾン EKS はアカウント内のノードグループを管理できます。アタッチされた `AWSServiceRoleForAmazonEKSNodegroup` ポリシーにより、ロールは 自動スケーリング グループ、セキュリティグループ、起動テンプレート、および IAM インスタンスプロファイルのリソースを管理できるようになります。詳細については「[AWS 管理ポリシー: AWSServiceRoleForAmazonEKSNodegroup](security-iam-awsmanpol.md#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup)」を参照してください。
`AWSServiceRoleForAmazonEKSNodegroup` サービスリンク役割は役割の引き受けについて以下のサービスを信頼します。
+ `eks-nodegroup.amazonaws.com`
ロールのアクセス許可ポリシーは指定したリソースに対して以下のアクションを実行することを アマゾン EKS に許可します。
+ [AWSServiceRoleForアマゾンEKSNodegroup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html)
サービスにリンクされたロールの作成、編集、削除を IAM エンティティ (ユーザー、グループ、ロールなど) に許可するにはアクセス許可を設定する必要があります。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。
## アマゾン EKS でのサービスにリンクされた役割の作成
サービスリンクロールを手動で作成する必要はありません。AWS マネジメントコンソール、AWS CLI、または AWS API でノードグループを作成すると、アマゾン EKS によってサービスリンクロールが作成されます。
**重要**
このサービスリンクロールはこのロールでサポートされている機能を使用する別のサービスでアクションが完了した場合にアカウントに表示されます。2017 年 1 月 1 日より前に アマゾン EKS サービスを使用している場合、サービスにリンクされたロールのサポートが開始された時点で、AWSServiceRoleForアマゾンEKSNodegroup ロールは アマゾン EKS によりアカウントに作成されています。詳細については[IAM アカウントに新しいロールが表示される](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared)を参照してください。
### Amazon EKS でのサービスにリンクされた役割の作成 (AWS API)
サービスリンクロールを手動で作成する必要はありません。AWS マネジメントコンソール、AWS CLI、または AWS API でマネージド型ノードグループを作成すると、アマゾン EKS によってサービスリンクロールが作成されます。
このサービスリンクロールを削除した後で再度作成する必要が生じた場合は同じ方法でアカウントにロールを再作成できます。別のマネージド型ノードグループを作成すると、Amazon EKS によってサービスリンク役割が再度作成されます。
## アマゾン EKS でのサービスにリンクされた役割の編集
アマゾン EKS では`AWSServiceRoleForAmazonEKSNodegroup` のサービスにリンクされた役割を編集することはできません。サービスにリンクされた役割を作成すると、多くのエンティティによって役割が参照される可能性があるため、役割名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については『*IAM ユーザーガイド*』の「[サービスにリンクされた役割の編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。
## アマゾン EKS でのサービスにリンクされた役割の削除
サービスリンク役割が必要な機能またはサービスが不要になった場合にはその役割を削除することをお勧めします。そうすることで、モニタリングや保守が積極的に行われていない未使用のエンティティを排除できます。ただし、手動で削除する前に、サービスリンク役割をクリーンアップする必要があります。
### サービスリンク役割のクリーンアップ
IAM を使用してサービスにリンクされた役割を削除するには最初に、その役割で使用されているリソースをすべて削除する必要があります。
**注記**
リソースの削除を試みた際に、対応する役割が アマゾン EKS サービスで使用されている場合、削除が失敗することがあります。失敗した場合は数分待ってから操作を再試行してください。
1. [アマゾン EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで **[クラスター]** を選択してください。
1. **[Compute]** (コンピューティング) タブを選択してください。
1. **[Node groups]** (ノードグループ) セクションで、削除するノードグループを選択してください。
1. 削除確認ウィンドウにノードグループの名前を入力し、[**Delete (削除)**] を選択してください。
1. この手順をクラスター内の他のすべてのノードグループに対して繰り返します。すべての削除操作が完了するまで待ちます。
### サービスリンク役割の手動による削除
サービスにリンクされた役割 `AWSServiceRoleForAmazonEKSNodegroup` を削除するにはIAM コンソール、AWS CLI、または AWS API を使用します。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割の削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。
## Amazon EKS のサービスにリンクされた役割がサポートされるリージョン
Amazon EKS ではこのサービスを利用できるすべてのリージョンで、サービスにリンクされた役割の使用がサポートされます。詳細については「[Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html)」(Amazon EKS エンドポイントとクォータ) を参照してください。
# Amazon EKS Fargate プロファイルの役割の使用
アマゾン EKS はAWS アイデンティティとアクセス管理 (IAM) の[サービスにリンクされた役割](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)を使用します。サービスにリンクされた役割はアマゾン EKS に直接リンクされた一意のタイプの IAM 役割です。サービスにリンクされた役割はアマゾン EKS で事前定義されています。この役割にはサービスがユーザーに代わって他の AWS のサービスを呼び出すために必要な、すべてのアクセス許可が付与されています。
サービスにリンクされた役割を使用することで、必要なアクセス許可を手動で追加する必要がなくなるため、アマゾン EKS の設定が簡単になります。サービスにリンクされた役割のアクセス許可はアマゾン EKS により定義されます。特に指定されている場合を除き、アマゾン EKS のみがその役割を引き受けることができます。定義される許可は信頼ポリシーと許可ポリシーに含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
サービスリンク役割はまずその関連リソースを削除しなければ削除できません。これにより、リソースへのアクセス許可を不用意に削除することが防止され、アマゾン EKS リソースが保護されます。
サービスにリンクされた役割をサポートする他のサービスについては「[IAM と連動する AWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照し、[**サービス-linked roles**] (サービスにリンクされた役割) の列内で [**Yes**] (はい) と表記されたサービスを確認してください。サービスにリンクされた役割に関するドキュメントをサービスで表示するには[**はい**] リンクを選択してください。
## アマゾン EKS でのサービスにリンクされた役割のアクセス許可
アマゾン EKS は`AWSServiceRoleForAmazonEKSForFargate` という名前のサービスにリンクされた役割を使用します。このロールにより、Amazon EKS Fargate は Fargate Pod に必要な VPC ネットワーキングを設定できます。アタッチされたポリシーにより、役割は エラスティック・ネットワーク・インターフェイス の作成と削除、エラスティック・ネットワーク・インターフェイス とリソースの記述ができるようになります。
`AWSServiceRoleForAmazonEKSForFargate` サービスリンク役割は役割の引き受けについて以下のサービスを信頼します。
+ `eks-fargate.amazonaws.com`
役割のアクセス許可ポリシーは指定したリソースに対して以下のアクションを実行することを アマゾン EKS に許可します。
+ [アAmazonEKSForFargateServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html)
サービスリンク役割の作成、編集、削除を IAM エンティティ (ユーザー、グループ、役割など) に許可するにはアクセス許可を設定する必要があります。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。
## アマゾン EKS でのサービスにリンクされた役割の作成
サービスリンク役割を手動で作成する必要はありません。AWS マネジメントコンソール、AWS CLI、または AWS API で Fargate プロファイルを作成すると、アマゾン EKS がサービスリンク役割を作成します。
**重要**
このサービスリンク役割はこの役割でサポートされている機能を使用する別のサービスでアクションが完了した場合にアカウントに表示されます。2019 年 12 月 13 日より前に Amazon EKS サービスを使用している場合、サービスにリンクされた役割のサポートが開始された時点で、AWSServiceRoleForAmazonEKSForFargate は Amazon EKS によりアカウントに作成されています。詳細については「[IAM アカウントに表示される新しい役割](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared)」を参照してください。
### Amazon EKS でのサービスにリンクされた役割の作成 (AWS API)
サービスリンク役割を手動で作成する必要はありません。AWS マネジメントコンソール、AWS CLI、または AWS API で Fargate プロファイルを作成すると、アマゾン EKS がサービスリンク役割を作成します。
このサービスリンク役割を削除した後で再度作成する必要が生じた場合は同じ方法でアカウントに役割を再作成できます。別のマネージド型ノードグループを作成すると、Amazon EKS によってサービスリンク役割が再度作成されます。
## アマゾン EKS でのサービスにリンクされた役割の編集
アマゾン EKS では`AWSServiceRoleForAmazonEKSForFargate` のサービスにリンクされた役割を編集することはできません。サービスにリンクされた役割を作成すると、多くのエンティティによって役割が参照される可能性があるため、役割名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については『*IAM ユーザーガイド*』の「[サービスにリンクされた役割の編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。
## アマゾン EKS でのサービスにリンクされた役割の削除
サービスリンク役割が必要な機能またはサービスが不要になった場合にはその役割を削除することをお勧めします。そうすることで、モニタリングや保守が積極的に行われていない未使用のエンティティを排除できます。ただし、手動で削除する前に、サービスリンク役割をクリーンアップする必要があります。
### サービスリンク役割のクリーンアップ
IAM を使用してサービスにリンクされた役割を削除するには最初に、その役割で使用されているリソースをすべて削除する必要があります。
**注記**
リソースの削除を試みた際に、対応する役割が アマゾン EKS サービスで使用されている場合、削除が失敗することがあります。失敗した場合は数分待ってから操作を再試行してください。
1. [アマゾン EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで **[Clusters]** (クラスター) を選択してください。
1. **[Clusters]** (クラスター) ページで、クラスターを選択してください。
1. **[Compute]** (コンピューティング) タブを選択してください。
1. **[Fargate profiles]** (Fargateプロファイル) セクションに Fargate プロファイルがある場合、それぞれを個別に選択し、**[Delete]** (削除)を選択してください。
1. 削除確認ウィンドウにプロファイルの名前を入力し、[**Delete (削除)**] を選択してください。
1. クラスター内のその他の Fargate プロファイルと、アカウント内のその他のクラスターについて、この手順を繰り返します。
### サービスリンク役割の手動による削除
IAM コンソール、AWS CLI、または AWS API を使用して、AWSServiceRoleForAmazonEKSForFargate のサービスにリンクされた役割を削除します。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割の削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。
## Amazon EKS のサービスにリンクされた役割がサポートされるリージョン
Amazon EKS ではこのサービスを利用できるすべてのリージョンで、サービスにリンクされた役割の使用がサポートされます。詳細については「[Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html)」(Amazon EKS エンドポイントとクォータ) を参照してください。
# ロールを使用して Kubernetes クラスターを Amazon EKS に接続する
Amazon EKS はAWS アイデンティティとアクセス管理 (IAM) の[サービスにリンクされた役割](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)を使用します。サービスにリンクされた役割はAmazon EKS に直接リンクされた一意のタイプの IAM 役割です。サービスにリンクされた役割はAmazon EKS で事前定義されています。この役割にはサービスがユーザーに代わって他の AWS のサービスを呼び出すために必要な、すべてのアクセス許可が付与されています。
サービスにリンクされた役割を使用することで、必要なアクセス許可を手動で追加する必要がなくなるため、Amazon EKS の設定が簡単になります。サービスにリンクされた役割のアクセス許可はAmazon EKS により定義されます。特に指定されている場合を除き、Amazon EKS のみがその役割を引き受けることができます。定義される許可は信頼ポリシーと許可ポリシーに含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
サービスリンク役割はまずその関連リソースを削除しなければ削除できません。これにより、リソースへのアクセス許可を不用意に削除することが防止され、Amazon EKS リソースが保護されます。
サービスにリンクされた役割をサポートする他のサービスについては「[IAM と連動する AWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照し、[**サービス-linked roles**] (サービスにリンクされた役割) の列内で [**Yes**] (はい) と表記されたサービスを確認してください。サービスにリンクされた役割に関するドキュメントをサービスで表示するには[**はい**] リンクを選択してください。
## Amazon EKS でのサービスにリンクされた役割のアクセス許可
Amazon EKS は`AWSServiceRoleForAmazonEKSConnector` という名前のサービスにリンクされた役割を使用します。このロールにより、Amazon EKS は Kubernetes クラスターに接続できます。アタッチされたポリシーにより、ロールは、登録された Kubernetes クラスターに接続するために必要なリソースを管理できます。
`AWSServiceRoleForAmazonEKSConnector` サービスリンク役割は役割の引き受けについて以下のサービスを信頼します。
+ `eks-connector.amazonaws.com`
役割のアクセス許可ポリシーは指定したリソースに対して以下のアクションを実行することを Amazon EKS に許可します。
+ [AmazonEKSConnectorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html)
サービスリンク役割の作成、編集、削除を IAM エンティティ (ユーザー、グループ、役割など) に許可するにはアクセス許可を設定する必要があります。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。
このロールは、SSM (Systems Manager) アクセス許可を使用して安全な接続を確立し、接続された Kubernetes クラスターを管理します。
## Amazon EKS でのサービスにリンクされた役割の作成
サービスにリンクされた役割を手動で作成してクラスターを接続する必要はありません。AWS マネジメントコンソール、AWS CLI、`eksctl` または AWS API でクラスターを接続すると、Amazon EKS によってサービスにリンクされた役割が作成されます。
このサービスリンク役割を削除した後で再度作成する必要が生じた場合は同じ方法でアカウントに役割を再作成できます。サービスにリンクされた役割はクラスターの接続時に Amazon EKS で自動的に再作成されます。
## Amazon EKS でのサービスにリンクされた役割の編集
Amazon EKS では`AWSServiceRoleForAmazonEKSConnector` のサービスにリンクされた役割を編集することはできません。サービスにリンクされた役割を作成すると、多くのエンティティによって役割が参照される可能性があるため、役割名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については『*IAM ユーザーガイド*』の「[サービスにリンクされた役割の編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。
## Amazon EKS でのサービスにリンクされた役割の削除
サービスリンク役割が必要な機能またはサービスが不要になった場合にはその役割を削除することをお勧めします。そうすることで、モニタリングや保守が積極的に行われていない未使用のエンティティを排除できます。ただし、手動で削除する前に、サービスリンク役割をクリーンアップする必要があります。
### サービスリンク役割のクリーンアップ
IAM を使用してサービスにリンクされた役割を削除するには最初に、その役割で使用されているリソースをすべて削除する必要があります。
**注記**
リソースの削除を試みた際に、対応する役割が Amazon EKS サービスで使用されている場合、削除が失敗することがあります。失敗した場合は数分待ってから操作を再試行してください。
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで **[Clusters]** (クラスター) を選択してください。
1. **[Clusters]** (クラスター) ページで、クラスターを選択してください。
1. **登録解除**タブをクリックし、**Ok** タブを選択してください。
### サービスリンク役割の手動による削除
IAM コンソール、AWS CLI、または AWS API を使用して、AWSServiceRoleForAmazonEKSConnector のサービスにリンクされた役割を削除します。詳細については IAM ユーザーガイド の「[サービスにリンクされた役割の削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。
# アウトポスト で アマゾン EKS ローカルクラスターの役割の使用
アマゾン エラスティック Kus サービス はAWS アイデンティティとアクセス管理 (IAM) の[サービberneteスにリンクされた役割](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)を使用します。サービスにリンクされた役割はアマゾン EKS に直接リンクされた一意のタイプの IAM 役割です。サービスにリンクされた役割はアマゾン EKS で事前定義されています。この役割にはサービスがユーザーに代わって他の AWS のサービスを呼び出すために必要な、すべてのアクセス許可が付与されています。
サービスにリンクされた役割を使用することで、必要なアクセス許可を手動で追加する必要がなくなるため、アマゾン EKS の設定が簡単になります。サービスにリンクされた役割のアクセス許可はアマゾン EKS により定義されます。特に指定されている場合を除き、アマゾン EKS のみがその役割を引き受けることができます。定義される許可は信頼ポリシーと許可ポリシーに含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
サービスリンク役割はまずその関連リソースを削除しなければ削除できません。これにより、リソースへのアクセス許可を不用意に削除することが防止され、アマゾン EKS リソースが保護されます。
サービスにリンクされた役割をサポートする他のサービスについては「[IAM と連動する AWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照し、[**サービス-linked roles**] (サービスにリンクされた役割) の列内で [**Yes**] (はい) と表記されたサービスを確認してください。サービスにリンクされた役割に関するドキュメントをサービスで表示するには[**はい**] リンクを選択してください。
## アマゾン EKS でのサービスにリンクされた役割のアクセス許可
アマゾン EKS は`AWSServiceRoleForAmazonEKSLocalOutpost` という名前のサービスにリンクされた役割を使用します。この役割により、アマゾン EKS はアカウント内のローカルクラスターを管理できます。アタッチされたポリシーにより、役割はネットワークインターフェイス、セキュリティグループ、ログ、アマゾン EC2 インスタンスのリソースを管理できるようになります。
**注記**
`AWSServiceRoleForAmazonEKSLocalOutpost` サービスにリンクされた役割はクラスターの作成に必要な役割とは異なります。詳細については「[Amazon EKS クラスター の IAM ロール](cluster-iam-role.md)」を参照してください。
`AWSServiceRoleForAmazonEKSLocalOutpost` サービスリンク役割は役割の引き受けについて以下のサービスを信頼します。
+ `outposts.eks-local.amazonaws.com`
役割のアクセス許可ポリシーは指定したリソースに対して以下のアクションを実行することを アマゾン EKS に許可します。
+ [アマゾンEKSサービスロールポリシー](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html)
サービスにリンクされた役割の作成、編集、削除を IAM エンティティ (ユーザー、グループ、役割など) に許可するにはアクセス許可を設定する必要があります。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。
## アマゾン EKS でのサービスにリンクされた役割の作成
サービスリンク役割を手動で作成する必要はありません。AWS マネジメントコンソール、AWS CLI、または AWS API でクラスターを作成すると、アマゾン EKS によってサービスリンク役割が作成されます。
このサービスリンク役割を削除した後で再度作成する必要が生じた場合は同じ方法でアカウントに役割を再作成できます。サービスにリンクされた役割はクラスターの作成時に アマゾン EKS で自動的に再作成されます。
## アマゾン EKS でのサービスにリンクされた役割の編集
アマゾン EKS では`AWSServiceRoleForAmazonEKSLocalOutpost` のサービスにリンクされた役割を編集することはできません。サービスリンク役割を作成すると、多くのエンティティによって役割が参照される可能性があるため、役割名を変更することはできません ただし、IAM を使用した役割記述の編集はできます。詳細については『*IAM ユーザーガイド*』の「[サービスにリンクされた役割の編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。
## アマゾン EKS でのサービスにリンクされた役割の削除
サービスリンク役割が必要な機能またはサービスが不要になった場合にはその役割を削除することをお勧めします。そうすることで、モニタリングや保守が積極的に行われていない未使用のエンティティを排除できます。ただし、手動で削除する前に、サービスリンク役割をクリーンアップする必要があります。
### サービスリンク役割のクリーンアップ
IAM を使用してサービスにリンクされた役割を削除するには最初に、その役割で使用されているリソースをすべて削除する必要があります。
**注記**
リソースの削除を試みた際に、対応する役割が アマゾン EKS サービスで使用されている場合、削除が失敗することがあります。失敗した場合は数分待ってから操作を再試行してください。
1. [アマゾン EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで アマゾン EKS **[Clusters]** (クラスター) を選択してください。
1. クラスターにノードグループまたは Fargate プロファイルがある場合はクラスターを削除する前にそれらを削除する必要があります。詳細については「[クラスターからマネージドノードグループを削除する](delete-managed-node-group.md)」および「[Fargate プロファイルを削除する](delete-fargate-profile.md)」を参照してください。
1. [**Clusters (クラスター)**] ページで、削除するクラスターを選択し、[**Delete (削除)**] を選択してください。
1. 削除確認ウィンドウにクラスター名を入力し、[**Delete (削除)**] を選択してください。
1. この手順をアカウント内の他のすべてのクラスターに対して繰り返します。すべての削除操作が完了するまで待ちます。
### サービスリンク役割の手動による削除
サービスにリンクされた役割 `AWSServiceRoleForAmazonEKSLocalOutpost` を削除するにはIAM コンソール、AWS CLI、または AWS API を使用します。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割の削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。
## Amazon EKS のサービスにリンクされた役割がサポートされるリージョン
Amazon EKS ではこのサービスを利用できるすべてのリージョンで、サービスにリンクされた役割の使用がサポートされます。詳細については「[Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html)」(Amazon EKS エンドポイントとクォータ) を参照してください。
# Amazon EKS ダッシュボードのロールの使用
Amazon EKS ダッシュボードでは、このサービスにリンクされたロールを使用して、複数のリージョンとアカウントからクラスターリソースに関する情報を集約します。ダッシュボードは AWS Organizations と統合され、組織内の複数のアカウントに関する情報を安全に読み取ります。
Amazon EKS ダッシュボードの詳細については、「[EKS ダッシュボードを使用してクラスターリソースに関する集計データを表示する](cluster-dashboard.md)」を参照してください。
## 背景
Amazon EKS はAWS アイデンティティとアクセス管理 (IAM) の[サービスにリンクされた役割](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)を使用します。サービスにリンクされた役割はAmazon EKS に直接リンクされた一意のタイプの IAM 役割です。サービスにリンクされた役割はAmazon EKS で事前定義されています。この役割にはサービスがユーザーに代わって他の AWS のサービスを呼び出すために必要な、すべてのアクセス許可が付与されています。
サービスにリンクされた役割を使用することで、必要なアクセス許可を手動で追加する必要がなくなるため、Amazon EKS の設定が簡単になります。サービスにリンクされた役割のアクセス許可はAmazon EKS により定義されます。特に指定されている場合を除き、Amazon EKS のみがその役割を引き受けることができます。定義される許可は信頼ポリシーと許可ポリシーに含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
サービスリンク役割はまずその関連リソースを削除しなければ削除できません。これにより、リソースへのアクセス許可を不用意に削除することが防止され、Amazon EKS リソースが保護されます。
サービスにリンクされた役割をサポートする他のサービスについては「[IAM と連動する AWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照し、[**サービス-linked roles**] (サービスにリンクされた役割) の列内で [**Yes**] (はい) と表記されたサービスを確認してください。サービスにリンクされた役割に関するドキュメントをサービスで表示するには[**はい**] リンクを選択してください。
## Amazon EKS でのサービスにリンクされた役割のアクセス許可
Amazon EKS は`AWSServiceRoleForAmazonEKSDashboard` という名前のサービスにリンクされた役割を使用します。このロールにより、Amazon EKS はクラスターリソースに関して集約された情報を含む EKS ダッシュボードを生成して表示できます。アタッチされた `AmazonEKSDashboardServiceRolePolicy` ポリシーにより、ロールは 自動スケーリング グループ、セキュリティグループ、起動テンプレート、および IAM インスタンスプロファイルのリソースを管理できるようになります。詳細については、「[AWS マネージドポリシー: AmazonEKSDashboardServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy)」を参照してください。
`AWSServiceRoleForAmazonEKSDashboard` サービスリンク役割は役割の引き受けについて以下のサービスを信頼します。
+ `dashboard.eks.amazonaws.com`
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKSDashboardServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json)」を参照してください。
サービスリンク役割の作成、編集、削除を IAM エンティティ (ユーザー、グループ、役割など) に許可するにはアクセス許可を設定する必要があります。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。
## Amazon EKS でのサービスにリンクされた役割の作成
サービスリンク役割を手動で作成する必要はありません。AWS コンソールでダッシュボードを有効にすると、Amazon EKS によってサービスにリンクされたロールが作成されます。
EKS ダッシュボードの有効化についての詳細は、「[EKS ダッシュボードと AWS Organizations の統合を設定する](cluster-dashboard-orgs.md)」を参照してください。
**重要**
このサービスリンク役割はこの役割でサポートされている機能を使用する別のサービスでアクションが完了した場合にアカウントに表示されます。
## Amazon EKS でのサービスにリンクされた役割の編集
Amazon EKS では`AWSServiceRoleForAmazonEKSDashboard` のサービスにリンクされた役割を編集することはできません。サービスにリンクされた役割を作成すると、多くのエンティティによって役割が参照される可能性があるため、役割名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については『*IAM ユーザーガイド*』の「[サービスにリンクされた役割の編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。
## Amazon EKS でのサービスにリンクされた役割の削除
サービスリンク役割が必要な機能またはサービスが不要になった場合にはその役割を削除することをお勧めします。そうすることで、モニタリングや保守が積極的に行われていない未使用のエンティティを排除できます。ただし、手動で削除する前に、サービスリンク役割をクリーンアップする必要があります。
### サービスリンク役割のクリーンアップ
IAM を使用してサービスにリンクされた役割を削除するには最初に、その役割で使用されているリソースをすべて削除する必要があります。
**注記**
リソースの削除を試みた際に、対応する役割が Amazon EKS サービスで使用されている場合、削除が失敗することがあります。失敗した場合は数分待ってから操作を再試行してください。
EKS ダッシュボードの無効化についての詳細は、「[EKS ダッシュボードと AWS Organizations の統合を設定する](cluster-dashboard-orgs.md)」を参照してください。
### サービスリンク役割の手動による削除
サービスにリンクされた役割 `AWSServiceRoleForAmazonEKSDashboard` を削除するにはIAM コンソール、AWS CLI、または AWS API を使用します。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割の削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。
## Amazon EKS のサービスにリンクされた役割がサポートされるリージョン
Amazon EKS ではこのサービスを利用できるすべてのリージョンで、サービスにリンクされた役割の使用がサポートされます。詳細については「[Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html)」(Amazon EKS エンドポイントとクォータ) を参照してください。
# Amazon EKS Pod 実行 IAM ロール
Pod を AWS Fargate インフラストラクチャで実行するには、Amazon EKS Pod 実行ロールが必要になります。
クラスターが AWS Fargate インフラストラクチャ上で Pod を作成する場合は、Fargate インフラストラクチャ上で実行されているコンポーネントがユーザーに代わって AWS API を呼び出す必要があります。これは、Amazon ECR からコンテナイメージをプルしたり、ログを他の AWS サービスにルーティングしたりするなどのアクションを実行できるようにするためです。Amazon EKS の Pod 実行ロールにより、これらを行うための IAM アクセス許可が付与されます。
Fargate プロファイルを作成するときは、プロファイルを使用して Fargate インフラストラクチャで Amazon EKS コンポーネントを実行できるように、Pod 実行ロールを指定する必要があります。このロールは、承認のためにクラスターの Kubernetes [ロールベースのアクセス制御](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) に追加されます。これにより、Fargate インフラストラクチャで実行されている `kubelet` が Amazon EKS クラスターに登録され、クラスター内でノードとして表示されるようになります。
**注記**
Fargate プロファイルには、Amazon EC2 ノードグループとは異なる IAM ロールが必要です。
**重要**
Fargate Pod で実行されているコンテナは、Pod 実行ロールに関連付けられた IAM アクセス許可を引き受けることはできません。Fargate Pod 内のコンテナに他の AWS サービスへのアクセス許可を付与するには、[IAM ロールをサービスアカウントとして](iam-roles-for-service-accounts.md)使用する必要があります。
Fargate プロファイルを作成する前に、[AmazonEKSFargatePodExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html) で IAM ロールを作成する必要があります。
## 正しく設定された既存の Pod 実行ロールをチェックする
次の手順を使用して、正しく設定された Amazon EKS の Pod 実行ロールがアカウントに既に存在しているかどうかをチェックします。「混乱した代理」のセキュリティ上の問題を回避するには、ロールが `SourceArn` に基づいてアクセスを制限することが重要です。必要に応じて実行ロールを変更し、他のクラスター上で Fargate プロファイルのサポートを含めることができます。
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. **[ロール]** ページで、ロールの一覧から **AmazonEKSFargatePodExecutionRole** を検索します。ロールが存在しない場合は、「[Amazon EKS での Pod 実行ロールの作成](#create-pod-execution-role)」を参照してロールを作成します。ロールが存在する場合は、そのロールを選択します。
1. **[AmazonEKSFargatePodExecutionRole]** ページで、次の操作を実行します。
1. **[許可]** を選択してください。
1. **AmazonEKSFargatePodExecutionRolePolicy** Amazon マネージドポリシーがロールにアタッチされていることを確認します。
1. **[信頼関係]** を選択します。
1. **[信頼ポリシーを編集]** を選択します。
1. **[信頼ポリシーを編集]** ページで、信頼関係に次のポリシーが含まれており、クラスター上で Fargate プロファイルの行が存在していることを確認します。そうである場合は、**[キャンセル]** を選択します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
ポリシーは一致するが、クラスター上で Fargate プロファイルを指定する行が存在しない場合は、`ArnLike` オブジェクトの上部に次の行を追加します。*region-code* はクラスターがある AWS リージョンに、*111122223333* はアカウント ID に、*my-cluster* はクラスターの名前に置き換えます。
```
"aws:SourceArn": "arn:aws:eks:region-code:111122223333:fargateprofile/my-cluster/*",
```
ポリシーが一致しない場合は、前のポリシー全体をフォームにコピーして、**[ポリシーの更新]** を選択します。*region-code* を、クラスターのある AWS リージョンに置き換えます。アカウントで、すべての AWS リージョンで同じロールを使用する場合は、*region-code* を `*` に置き換えます。*111122223333* をアカウント ID に、*my-cluster* をクラスター名に置き換えます。アカウント内のすべてのクラスターに同じロールを使用する場合は、*my-cluster* を `*` に置き換えます。
## Amazon EKS での Pod 実行ロールの作成
クラスター用の Amazon EKS Pod 実行ロールをまだ作成していない場合は、AWS マネジメントコンソール または AWS CLI を使用して作成できます。
AWS マネジメントコンソール
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. **[ロール]** ページで、**[ロールの作成]** を選択してください。
1. **[信頼されたエンティティを選択]** ページで、以下の操作を実行してください：
1. **[信頼するエンティティのタイプ]** で **[AWS サービス]** を選択します。
1. [**他の AWS サービスのユースケース**] ドロップダウンリストから、[**EKS**] を選択します。
1. **[EKS - Fargate Pod]** を選択します。
1. [**次へ**] を選択します。
1. **[アクセス許可を追加]** ページで **[次へ]** を選択します。
1. **[名前を付けて、レビューし、作成する]** ページで、以下の操作を実行します。
1. **[ロール名]** に、`AmazonEKSFargatePodExecutionRole` などのロールの一意の名前を入力します。
1. **[タグの追加 (オプション)]** で、タグをキーバリューのペアとして添付して、メタデータをロールに追加します。IAM でのタグの使用に関する詳細については『*IAM ユーザーガイド*』の「[IAM リソースにタグを付ける](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html)」を参照してください。
1. [**ロールの作成**] を選択してください。
1. **[ロール]** ページで、ロールの一覧から **AmazonEKSFargatePodExecutionRole** を検索します。ロールを選択します。
1. **[AmazonEKSFargatePodExecutionRole]** ページで、次の操作を実行します。
1. **[信頼関係]** を選択します。
1. **[信頼ポリシーを編集]** を選択します。
1. **[信頼ポリシーを編集]** ページで、次の操作を実行します。
1. 次の内容をコピーして、**[信頼ポリシーを編集]** フォームに貼り付けます。*region-code* を、クラスターのある AWS リージョンに置き換えます。アカウントで、すべての AWS リージョンで同じロールを使用する場合は、*region-code* を `*` に置き換えます。*111122223333* をアカウント ID に、*my-cluster* をクラスター名に置き換えます。アカウント内のすべてのクラスターに同じロールを使用する場合は、*my-cluster* を `*` に置き換えます。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. [**ポリシーの更新**] を選択してください。
AWS CLI
1. 次の内容をコピーして、`pod-execution-role-trust-policy.json` という名前のファイルに貼り付けます。*region-code* を、クラスターのある AWS リージョンに置き換えます。アカウントで、すべての AWS リージョンで同じロールを使用する場合は、*region-code* を `*` に置き換えます。*111122223333* をアカウント ID に、*my-cluster* をクラスター名に置き換えます。アカウント内のすべてのクラスターに同じロールを使用する場合は、*my-cluster* を `*` に置き換えます。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Pod 実行 IAM ロールを作成します。
```
aws iam create-role \
--role-name AmazonEKSFargatePodExecutionRole \
--assume-role-policy-document file://"pod-execution-role-trust-policy.json"
```
1. このロールに、必要な Amazon EKS 管理の IAM ポリシーをアタッチします。
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy \
--role-name AmazonEKSFargatePodExecutionRole
```
# Amazon EKS コネクタの IAM ロール
Kubernetes クラスターを接続して AWS マネジメントコンソール に表示することができます。Kubernetes クラスターに接続するには、IAM ロールを作成します。
## 既存の EKS Connector ロールの確認
以下の手順を使用して、アカウントに既に Amazon EKS コネクタロールがあるかどうかを確認できます。
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. ロールのリストで `AmazonEKSConnectorAgentRole` を検索します。`AmazonEKSConnectorAgentRole` が含まれているロールが存在しない場合は、[Amazon EKS コネクタエージェントロールの作成](#create-connector-role) を参照してロールを作成します。`AmazonEKSConnectorAgentRole` が含まれているロールが存在する場合はこのロールを選択してアタッチされているポリシーを表示します。
1. **[許可]** を選択してください。
1. **AmazonEKSConnectorAgentPolicy** 管理ポリシーがロールにアタッチされていることを確認します。ポリシーがアタッチされている場合、Amazon EKS Connector ロールは適切に設定されています。
1. **[信頼関係]** を選択し、**[信頼ポリシーの編集]** を選択してください。
1. 信頼関係に以下のポリシーが含まれていることを確認します。信頼関係が以下のポリシーと一致する場合、**[キャンセル]** を選択してください。信頼関係が一致しない場合、ポリシーを **[信頼ポリシーの編集]** ウィンドウにコピーし、**[ポリシーの更新]** を選択します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
## Amazon EKS コネクタエージェントロールの作成
コネクタエージェントロールを作成するには、AWS マネジメントコンソール または AWS CloudFormation を使用できます。
AWS CLI
1. IAM ロールに使用する次の JSON が含まれる `eks-connector-agent-trust-policy.json` という名前のファイルを作成します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
1. IAM ロールに使用する次の JSON が含まれる `eks-connector-agent-policy.json` という名前のファイルを作成します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SsmControlChannel",
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel"
],
"Resource": "arn:aws:eks:*:*:cluster/*"
},
{
"Sid": "ssmDataplaneOperations",
"Effect": "Allow",
"Action": [
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenDataChannel",
"ssmmessages:OpenControlChannel"
],
"Resource": "*"
}
]
}
```
1. 前のリストアイテムで作成した信頼ポリシーとポリシーを使用して、Amazon EKS Connector エージェントロールを作成します。
```
aws iam create-role \
--role-name AmazonEKSConnectorAgentRole \
--assume-role-policy-document file://eks-connector-agent-trust-policy.json
```
1. Amazon EKS Connector エージェントのロールにポリシーを添付します。
```
aws iam put-role-policy \
--role-name AmazonEKSConnectorAgentRole \
--policy-name AmazonEKSConnectorAgentPolicy \
--policy-document file://eks-connector-agent-policy.json
```
AWS CloudFormation
1. 以下の AWS CloudFormation テンプレートを、テキストファイルとしてローカルシステムに保存します。
**注記**
このテンプレートでは、ここで作成されなければ `registerCluster` API が呼び出されたときに作成される、サービスにリンクされたロールも作成されます。詳細については、「[ロールを使用して Kubernetes クラスターを Amazon EKS に接続する](using-service-linked-roles-eks-connector.md)」を参照してください。
```
---
AWSTemplateFormatVersion: '2010-09-09'
Description: 'Provisions necessary resources needed to register clusters in EKS'
Parameters: {}
Resources:
EKSConnectorSLR:
Type: AWS::IAM::ServiceLinkedRole
Properties:
AWSServiceName: eks-connector.amazonaws.com
EKSConnectorAgentRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action: [ 'sts:AssumeRole' ]
Principal:
Service: 'ssm.amazonaws.com'
EKSConnectorAgentPolicy:
Type: AWS::IAM::Policy
Properties:
PolicyName: EKSConnectorAgentPolicy
Roles:
- {Ref: 'EKSConnectorAgentRole'}
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: 'Allow'
Action: [ 'ssmmessages:CreateControlChannel' ]
Resource:
- Fn::Sub: 'arn:${AWS::Partition}:eks:*:*:cluster/*'
- Effect: 'Allow'
Action: [ 'ssmmessages:CreateDataChannel', 'ssmmessages:OpenDataChannel', 'ssmmessages:OpenControlChannel' ]
Resource: "*"
Outputs:
EKSConnectorAgentRoleArn:
Description: The agent role that EKS connector uses to communicate with AWS services.
Value: !GetAtt EKSConnectorAgentRole.Arn
```
1. [AWS CloudFormation コンソール](https://console.aws.amazon.com/cloudformation/)を開きます。
1. 新しいリソースを使用して **[スタックを作成]** を選択します (標準)。
1. [**テンプレートの指定**] で、[**テンプレートファイルのアップロード**] を選択し、[**ファイルの選択**] を選択します。
1. 作成したファイルを選択し、[**Next (次へ)**] を選択します。
1. [**スタックの名前**] に `eksConnectorAgentRole` などのロール名を入力し、[**次へ**] を選択します。
1. [**スタックオプションの設定**] ページで、[**Next (次へ)**] を選択します。
1. [**Review (レビュー)**] ページの情報から、スタックにより IAM リソースが作成されることを確認し、[**Create stack (スタックの作成)**] を選択します。
# Amazon Elastic Kubernetes Service に関する AWS 管理ポリシー
AWS マネージドポリシーはAWS が作成および管理するスタンドアロンポリシーです。AWS マネージドポリシーは多くの一般的なユースケースに対してアクセス許可を提供するように設計されているため、ユーザー、グループ、役割へのアクセス権の割り当てを開始できます。
AWS マネージドポリシーは特定のユースケースに対して最小特権の許可を付与しない場合があることに注意してください。これはすべての AWS 顧客が使用できる状態になっているためです。ユースケースに固有の[カスタマー管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)を定義して、アクセス許可を絞り込むことをお勧めします。
AWS マネージドポリシーで定義したアクセス権限は変更できません。AWS が AWS マネージドポリシーに定義されているアクセス許可を更新すると、更新はポリシーがアタッチされているすべてのプリンシパルアイデンティティ (ユーザー、グループ、役割) に影響します。新しい AWS サービスを起動するか、既存のサービスで新しい API オペレーションが使用可能になると、AWS が AWS マネージドポリシーを更新する可能性が最も高くなります。
詳細については「*IAM ユーザーガイド*」の「[AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。
## AWS 管理ポリシー: AmazonEKS\$1CNI\$1Policy
`AmazonEKS_CNI_Policy` ポリシーを IAM エンティティにアタッチできます。Amazon EC2 ノードグループを作成する前に、このポリシーを[ノードの IAM ロール](create-node-role.md)、または Amazon VPC CNI Plugin for Kubernetes 専用で使用する IAM ロールにアタッチする必要があります。これはユーザーに代わってアクションを実行できるようにするためです。プラグインでのみ使用される役割にポリシーをアタッチすることをお勧めします。詳細については[Amazon VPC CNI を使用して Pod に IP を割り当てる](managing-vpc-cni.md)および[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)を参照してください。
**許可の詳細**
このポリシーには Amazon EKS に以下のタスクを完了させるための以下の権限が含まれています。
+ **`ec2:*NetworkInterface` および `ec2:*PrivateIpAddresses`** - Amazon VPC CNI プラグインが Pod の Elastic Network Interface や IP アドレスのプロビジョニングなどのアクションを実行し、Amazon EKS で実行されるアプリケーションにネットワークを提供できるようにします。
+ **`ec2` 読み取りアクション** - Amazon VPC CNI プラグインがインスタンスやサブネットを記述して、Amazon VPC サブネット内の空き IP アドレスの量を確認するなどのアクションを実行できるようにします。VPC CNI は各サブネットの空き IP アドレスを使用して、エラスティック・ネットワーク・インターフェイス の作成時に使用する空き IP アドレスが最も多いサブネットを選択できます。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html#AmazonEKS_CNI_Policy-json)」を参照してください。
## AWS 管理ポリシー: AmazonEKSClusterPolicy
IAM エンティティに `AmazonEKSClusterPolicy` をアタッチできます。クラスターを作成する前に、このポリシーをアタッチした[クラスター IAM ロール](cluster-iam-role.md)が必要となります。Amazon EKS によって管理される Kubernetes クラスターは、ユーザーに代わって他の AWS のサービスを呼び出します。これにより、サービスで使用するリソースを管理します。
このポリシーにはアマゾン EKS に以下のタスクを完了させるための以下の権限が含まれています。
+ **`autoscaling`** – 自動スケーリング グループの設定を読み取り、更新します。これらの権限は Amazon EKS では使用されませんが、下位互換性のためにポリシーに残ります。
+ **`ec2`** – Amazon EC2 ノードに関連付けられているボリュームとネットワークリソースを操作します。これは、Kubernetes コントロールプレーンがインスタンスをクラスターに結合し、Kubernetes 永続ボリュームによってリクエストされる Amazon EBS ボリュームを動的にプロビジョニングおよび管理できるようにするために必要です。
+ ** `ec2` ** - VPC CNI によって作成された Elastic Network Interface を削除します。こうした権限付与が必要なのは、VPC CNI が予期せず終了した場合に、残った Elastic Network Interface を EKS によってクリーンアップするためです。
+ ** `elasticloadbalancing` ** – Elastic Load Balancers を操作し、ノードをターゲットとして追加します。これは、Kubernetes コントロールプレーンが Kubernetes サービスによってリクエストされる Elastic Load Balancer を動的にプロビジョニングできるようにするために必要です。
+ ** `iam` ** - サービスにリンクされた役割を作成します。これは、Kubernetes コントロールプレーンが Kubernetes サービスによってリクエストされる Elastic Load Balancer を動的にプロビジョニングできるようにするために必要です。
+ **`kms`** – AWS KMS からキーを読み取ります。これは、Kubernetes コントロールプレーンが `etcd` に保存される Kubernetes シークレットの[シークレット暗号化](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)を管理するために必要です。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json)」を参照してください。
## AWS マネージドポリシー: AmazonEKSDashboardConsoleReadOnly
IAM エンティティに `AmazonEKSDashboardConsoleReadOnly` をアタッチできます。
このポリシーにはアマゾン EKS に以下のタスクを完了させるための以下の権限が含まれています。
+ ** `eks` ** – EKS ダッシュボードのデータ、リソース、クラスターバージョン情報への読み取り専用アクセス。これにより、EKS 関連のメトリクスおよびクラスター設定の詳細を表示できます。
+ ** `organizations` ** – 以下のような AWS Organizations 情報への読み取り専用アクセス。
+ 組織の詳細とサービスアクセスの表示
+ 組織のルート、アカウント、組織単位の一覧表示
+ 組織構造の表示
JSON ポリシードキュメントの最新バージョンを確認するには、「AWS マネージドポリシーのリファレンスガイド」の「[AmazonEKSDashboardConsoleReadOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardConsoleReadOnly.html#AmazonEKSDashboardConsoleReadOnly-json)」を参照してください。
## AWS 管理ポリシー: AmazonEKSFargatePodExecutionRolePolicy
IAM エンティティに `AmazonEKSFargatePodExecutionRolePolicy` をアタッチできます。Fargate プロファイルを作成する前に、Fargate Pod 実行ロールを作成し、このポリシーをアタッチする必要があります。詳細については、「[ステップ 2: Fargate Pod 実行ロールを作成する](fargate-getting-started.md#fargate-sg-pod-execution-role)」および「[起動時にどの Pod が AWS Fargate を使用するのかを定義する](fargate-profile.md)」を参照してください。
このポリシーはロールに対して、Fargate で Amazon EKS Pod を実行するために必要な他の AWS サービスリソースにアクセスするための権限を付与します。
**許可の詳細**
このポリシーにはアマゾン EKS に以下のタスクを完了させるための以下の権限が含まれています。
+ ** `ecr` ** – Fargate で実行中のポッドが、Amazon ECR に格納されているコンテナイメージを取得できるようにします。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKSFargatePodExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html#AmazonEKSFargatePodExecutionRolePolicy-json)」を参照してください。
## AWS マネージドポリシー: AmazonEKSConnectorServiceRolePolicy
IAM エンティティに `AmazonEKSConnectorServiceRolePolicy` をアタッチすることはできません。このポリシーはユーザーに代わって アマゾン EKS がアクションを実行することを許可する、サービスにリンクされた役割にアタッチされます。詳細については、「[ロールを使用して Kubernetes クラスターを Amazon EKS に接続する](using-service-linked-roles-eks-connector.md)」を参照してください。
このロールにより、Amazon EKS は Kubernetes クラスターに接続できます。アタッチされたポリシーにより、ロールは、登録された Kubernetes クラスターに接続するために必要なリソースを管理できます。
**アクセス許可の詳細**
このポリシーにはアマゾン EKS が以下のタスクを完了できるようにする以下の権限が含まれています。
+ ** `SSM Management` ** – SSM アクティベーションを作成、説明、削除し、マネージドインスタンスの登録を解除します。これにより、基本的な Systems Manager オペレーションが可能になります。
+ ** `Session Management` ** – EKS クラスター専用の SSM セッションを開始し、AmazonEKS ドキュメントを使用して非インタラクティブコマンドを実行します。
+ ** `IAM Role Passing` ** – SSM サービスに対して特定の IAM ロールを渡します。この操作は、渡されるロールを `ssm.amazonaws.com` に制限する条件によって制御されます。
+ ** `EventBridge Rules` ** – EventBridge ルールとターゲットを作成します。ただし、`eks-connector.amazonaws.com` によって管理される場合にのみ許可されます。ルールは、イベントソースとして AWS SSM のみに制限されます。
JSON ポリシードキュメントの最新バージョンを確認するには「AWS 管理ポリシーリファレンスガイド」の「[AmazonEKSConnectorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html)」を参照してください。
## AWS 管理ポリシー: AmazonEKSForFargateServiceRolePolicy
IAM エンティティに `AmazonEKSForFargateServiceRolePolicy` をアタッチすることはできません。このポリシーはユーザーに代わって アマゾン EKS がアクションを実行することを許可する、サービスにリンクされた役割にアタッチされます。詳細については「`AWSServiceRoleforAmazonEKSForFargate`」を参照してください。
このポリシーは Fargate タスクを実行するために必要なアクセス権限を Amazon EKS に付与します。このポリシーはFargate ノードがある場合にのみ使用されます。
**アクセス許可の詳細**
このポリシーにはアマゾン EKS が以下のタスクを完了できるようにする以下の権限が含まれています。
+ ** `ec2` ** – Elastic Network Interfaces を作成および削除し、Elastic Network Interfaces とリソースについて説明します。これは Amazon EKS Fargate サービスが Fargate ポッドに必要な VPC ネットワーキングを設定できるようにするために必要です。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKSForFargateServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html#AmazonEKSForFargateServiceRolePolicy-json)」を参照してください。
## AWS マネージドポリシー: AmazonEKSComputePolicy
IAM エンティティに `AmazonEKSComputePolicy` をアタッチできます。このポリシーを[クラスター IAM 役割](cluster-iam-role.md)にアタッチして、EKS がアカウントで管理できるリソースを拡張できます。
このポリシーによって Amazon EKS が EKS クラスター用の EC2 インスタンスを作成および管理するために必要なアクセス許可と、EC2 を設定するために必要な IAM アクセス許可が付与されます。さらに、このポリシーによって、Amazon EKS がユーザーに代わって EC2 スポットサービスにリンクされたロールを作成するためのアクセス許可が付与されます。
### 許可の詳細
このポリシーにはアマゾン EKS に以下のタスクを完了させるための以下の権限が含まれています。
+ ** `ec2` 許可**:
+ `ec2:CreateFleet` および `ec2:RunInstances` - EC2 インスタンスの作成と、EKS クラスターノードのための特定の EC2 リソース (イメージ、セキュリティグループ、サブネット) の使用を許可します。
+ `ec2:CreateLaunchTemplate` - EKS クラスターノードのための EC2 起動テンプレートの作成を許可します。
+ また、このポリシーにはこれらの EC2 許可の使用を、EKS クラスター名および他の関連タグでタグ付けされたリソースに制限する条件も含まれています。
+ `ec2:CreateTags` - `CreateFleet`、`RunInstances`、および `CreateLaunchTemplate` アクションによって作成された EC2 リソースへのタグの追加を許可します。
+ ** `iam` 許可**:
+ `iam:AddRoleToInstanceProfile` - EKS コンピューティングインスタンスプロファイルへの IAM 役割の追加を許可します。
+ `iam:PassRole` - 必要な IAM 役割を EC2 サービスに渡すことを許可します。
JSON ポリシードキュメントの最新バージョンを確認するには「AWS マネージドポリシーリファレンスガイド」の「[AmazonEKSComputePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSComputePolicy.html#AmazonEKSComputePolicy-json)」を参照してください。
## AWS 管理ポリシー: AmazonEKSNetworkingPolicy
IAM エンティティに `AmazonEKSNetworkingPolicy` をアタッチできます。このポリシーを[クラスター IAM 役割](cluster-iam-role.md)にアタッチして、EKS がアカウントで管理できるリソースを拡張できます。
このポリシーは Amazon EKS が EKS クラスターのネットワークインターフェイスを作成および管理するために必要なアクセス許可を付与し、コントロールプレーンとワーカーノードが適切に通信および機能するように設計されています。
### アクセス許可の詳細
このポリシーは Amazon EKS がクラスターのネットワークインターフェイスを管理できるようにする以下のアクセス許可を付与します。
+ **`ec2` ネットワークインターフェイスアクセス許可**:
+ `ec2:CreateNetworkInterface` - EC2 ネットワークインターフェイスの作成を許可します。
+ このポリシーにはこのアクセス許可の使用を EKS クラスター名と Kubernetes CNI ノード名でタグ付けされたネットワークインターフェイスに制限するための条件が含まれています。
+ `ec2:CreateTags` - `CreateNetworkInterface` アクションによって作成されたネットワークインターフェイスへのタグの追加を許可します。
+ **`ec2` ネットワークインターフェイス管理のアクセス許可**:
+ `ec2:AttachNetworkInterface`、`ec2:ModifyNetworkInterfaceAttribute`、`ec2:DetachNetworkInterface` - EC2 インスタンスへのネットワークインターフェイス属性のアタッチ、変更、およびネットワークインターフェイスのデタッチを許可します。
+ `ec2:UnassignPrivateIpAddresses`、`ec2:UnassignIpv6Addresses`、`ec2:AssignPrivateIpAddresses`、`ec2:AssignIpv6Addresses` - ネットワークインターフェイスの IP アドレス割り当ての管理を許可します。
+ これらのアクセス許可はEKS クラスター名でタグ付けされたネットワークインターフェイスに制限されます。
JSON ポリシードキュメントの最新バージョンを確認するにはAWS マネージドポリシーリファレンスガイドの「[AmazonEKSNetworkingPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSNetworkingPolicy.html#AmazonEKSNetworkingPolicy-json)」を参照してください。
## AWS マネージドポリシー: AmazonEKSBlockStoragePolicy
IAM エンティティに `AmazonEKSBlockStoragePolicy` をアタッチできます。このポリシーを[クラスター IAM 役割](cluster-iam-role.md)にアタッチして、EKS がアカウントで管理できるリソースを拡張できます。
このポリシーは Amazon EKS が EKS クラスターのために EC2 ボリュームとスナップショットを作成、管理、メンテナンスするために必要な許可を付与し、Kubernetes ワークロードが必要とする永続的ストレージをコントロールプレーンとワーカーノードがプロビジョニングおよび使用できるようにします。
### アクセス許可の詳細
この IAM ポリシーは Amazon EKS が EC2 ボリュームとスナップショットを管理できるように、次の許可を付与します:
+ **`ec2` ボリューム管理の許可**:
+ `ec2:AttachVolume`、`ec2:DetachVolume`、`ec2:ModifyVolume`、`ec2:EnableFastSnapshotRestores` - EC2 ボリュームの高速スナップショット復元のアタッチ、デタッチ、変更、有効化を許可します。
+ これらの許可はEKS クラスター名でタグ付けされたボリュームに制限されます。
+ `ec2:CreateTags` - `CreateVolume` および `CreateSnapshot` アクションによって作成された EC2 ボリュームとスナップショットへのタグの追加を許可します。
+ **`ec2` ボリューム作成の許可**:
+ `ec2:CreateVolume` - 新しい EC2 ボリュームの作成を許可します。
+ このポリシーにはこの許可の使用を、EKS クラスター名および他の関連タグでタグ付けされたボリュームに制限する条件が含まれています。
+ `ec2:CreateSnapshot` - 新しい EC2 ボリュームスナップショットの作成を許可します。
+ このポリシーにはこの許可の使用を、EKS クラスター名および他の関連タグでタグ付けされたスナップショットに制限する条件が含まれています。
JSON ポリシードキュメントの最新バージョンを確認するには「AWS マネージドポリシーリファレンスガイド」の「[AmazonEKSBlockStoragePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSBlockStoragePolicy.html#AmazonEKSBlockStoragePolicy-json)」を参照してください。
## AWS マネージドポリシー: AmazonEKSLoadBalancingPolicy
IAM エンティティに `AmazonEKSLoadBalancingPolicy` をアタッチできます。このポリシーを[クラスター IAM 役割](cluster-iam-role.md)にアタッチして、EKS がアカウントで管理できるリソースを拡張できます。
この IAM ポリシーは Amazon EKS が Elastic ロードバランサー (ELB) および関連リソースを管理するためにさまざまな AWS サービスと連携するために必要な許可を付与します。
### アクセス許可の詳細
このポリシーによって付与される主な許可は次のとおりです:
+ ** `elasticloadbalancing` **: Elastic Load Balancers とターゲットグループの作成、変更、管理を許可します。これにはロードバランサー、ターゲットグループ、リスナー、ルールを作成、更新、削除するための許可が含まれます。
+ ** `ec2` **: Kubernetes コントロールプレーンがインスタンスをクラスターに参加させ、Amazon EBS ボリュームを管理するために必要なセキュリティグループの作成と管理を許可します。また、インスタンス、VPC、サブネット、セキュリティ グループ、その他のネットワーク リソースなどの EC2 リソースを記述および一覧表示することもできます。
+ ** `iam` **: Kubernetes コントロールプレーンが ELB を動的にプロビジョニングするために必要な、Elastic Load Balancing 用のサービスにリンクされた役割の作成を許可します。
+ **`kms`**: etcd に保存されている Kubernetes シークレットの暗号化をサポートするために Kubernetes コントロールプレーンが必要とする AWS KMS からのキーの読み取りを許可します。
+ **`wafv2`** および **`shield`**: ウェブ ACL 関連付けと関連付け解除、および Elastic ロードバランサー のための AWS Shield 保護の作成/削除を許可します。
+ **`cognito-idp`**、**`acm`**、および **`elasticloadbalancing`**: ユーザープールクライアントの記述、証明書の一覧表示および記述、ならびにターゲットグループの記述を実行するための許可を付与します。これはKubernetes コントロールプレーンが Elastic ロードバランサー を管理するために必要です。
また、このポリシーには`eks:eks-cluster-name` タグを使用して、許可の範囲が管理対象の特定の EKS クラスターに設定されているようにするための条件チェックもいくつか含まれています。
JSON ポリシードキュメントの最新バージョンを確認するには「AWS マネージドポリシーリファレンスガイド」の「[AmazonEKSLoadBalancingPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLoadBalancingPolicy.html#AmazonEKSLoadBalancingPolicy-json)」を参照してください。
## AWS マネージドポリシー: AmazonEKSMCPReadOnlyAccess
IAM エンティティに `AmazonEKSMCPReadOnlyAccess` をアタッチできます。このポリシーは、Amazon EKS リソースおよび関連する AWS サービスへの読み取り専用アクセスを提供し、Amazon EKS モデルコンテキストプロトコル (MCP) サーバーがインフラストラクチャを変更することなくオブザーバビリティおよびトラブルシューティングのオペレーションを実行できるようにします。
**アクセス許可の詳細**
このポリシーには、プリンシパルに以下のタスクを完了させるための以下の権限が含まれています。
+ ** `eks` ** プリンシパルが EKS クラスター、ノードグループ、アドオン、アクセスエントリ、インサイトを記述および一覧表示し、読み取り専用オペレーションのために Kubernetes API にアクセスできるようにします。
+ ** `iam` ** プリンシパルが IAM ロール、ポリシー、およびその添付ファイルに関する情報を取得して、EKS リソースに関連付けられたアクセス許可を理解できるようにします。
+ ** `ec2` ** プリンシパルが VPC、サブネット、ルートテーブルを記述して、EKS クラスターのネットワーク設定を理解できるようにします。
+ ** `sts` ** プリンシパルが認証および認可の目的で発信者 ID 情報を取得できるようにします。
+ ** `logs` ** プリンシパルが、トラブルシューティングとモニタリングのために、CloudWatch Logs でクエリを開始し、クエリ結果を取得できるようにします。
+ ** `cloudwatch` ** プリンシパルがクラスターとワークロードのパフォーマンスをモニタリングするためのメトリクスデータを取得できるようにします。
+ ** `eks-mcp` ** プリンシパルが MCP オペレーションを呼び出し、Amazon EKS MCP サーバー内で読み取り専用ツールを呼び出せるようにします。
JSON ポリシードキュメントの最新バージョンを確認するには、「AWS マネージドポリシーのリファレンスガイド」の「[AmazonEKSMCPReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSMCPReadOnlyAccess.html)」を参照してください。
## AWS 管理ポリシー: AmazonEKSServicePolicy
IAM エンティティに `AmazonEKSServicePolicy` をアタッチできます。2020 年 4 月 16 日より前に作成されたクラスターではIAM 役割を作成し、このポリシーをアタッチする必要がありました。2020 年 4 月 16 日以降に作成されたクラスターでは役割を作成する必要はなく、このポリシーの割り当ても必要ありません。IAM プリンシパルを使用してクラスターを作成する場合、`iam:CreateServiceLinkedRole` 権限がある場合、[AWSServiceRoleforAmazonEKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) のサービスにリンクされた役割が自動的に作成されます。このサービスにリンクされた役割には[管理ポリシー: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) がアタッチされています。
このポリシーにより、Amazon EKS は Amazon EKS クラスターを操作するために必要なリソースを作成および管理できるようになります。
**アクセス許可の詳細**
このポリシーには、Amazon EKS が以下のタスクを完了できるようにする以下の権限が含まれています。
+ ** `eks` ** – 更新を開始した後、クラスターの Kubernetes バージョンを更新します。この権限は Amazon EKS では使用されませんが、下位互換性のためにポリシーに残ります。
+ ** `ec2` ** – Elastic Network Interfaces およびその他のネットワークリソースとタグを操作します。これは、ノードと Kubernetes コントロールプレーン間の通信を容易にするネットワーキングを設定するために、Amazon EKS で必要です。セキュリティグループに関する情報を確認します。セキュリティグループのタグを更新します。
+ ** `route53` ** – VPC をホストゾーンに関連付けます。これは、Kubernetes クラスター API サーバーのプライベートエンドポイントネットワーキングを有効にするために、Amazon EKS で必要です。
+ ** `logs` ** – ログイベント これは、Amazon EKS が Kubernetes コントロールプレーンログを CloudWatch に送信できるようにするために必要です。
+ ** `iam` ** - サービスにリンクされた役割を作成します。これは Amazon EKS がユーザーに代わって [アマゾン EKS でのサービスにリンクされた役割のアクセス許可](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) のサービスにリンクされた役割を作成するために必要です。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html#AmazonEKSServicePolicy-json)」を参照してください。
## AWS 管理ポリシー: AmazonEKSServiceRolePolicy
IAM エンティティに `AmazonEKSServiceRolePolicy` をアタッチすることはできません。このポリシーはユーザーに代わって アマゾン EKS がアクションを実行することを許可する、サービスにリンクされた役割にアタッチされます。詳細については「[アマゾン EKS でのサービスにリンクされた役割のアクセス許可](using-service-linked-roles-eks.md#service-linked-role-permissions-eks)」を参照してください。`iam:CreateServiceLinkedRole` 権限のある IAM プリンシパルを使用してクラスターを作成する場合、[AWSServiceRoleforAmazonEKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) のサービスにリンクされた役割が自動的に作成され、このポリシーがアタッチされます。
このポリシーにより、サービスにリンクされた役割はユーザーに代わって AWS サービスを呼び出します。
**アクセス許可の詳細**
このポリシーにはアマゾン EKS が以下のタスクを完了できるようにする以下の権限が含まれています。
+ ** `ec2` ** – Elastic Network Interface と Amazon EC2 インスタンス、クラスターセキュリティグループ、およびクラスターの作成に必要な VPC を作成、記述します。詳細については「[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)」を参照してください。セキュリティグループに関する情報を確認します。セキュリティグループのタグを更新します。「オンデマンドキャパシティ予約」に関する情報を参照してください。クラスターインサイトの一部として設定の問題を検出するために、ルートテーブルやネットワーク ACL を含む VPC 設定を読み取ります。
+ ** `ec2` Auto Mode** - EKS Auto Mode によって作成された EC2 インスタンスを終了します。詳細については、「[EKS Auto Mode を使用してクラスターインフラストラクチャを自動化する](automode.md)」を参照してください。
+ ** `iam` ** – IAM 役割にアタッチされているすべての管理ポリシーを一覧表示します。これは、Amazon EKS がクラスターの作成に必要なすべての管理ポリシーと権限を一覧表示および検証できるようにするために必要です。
+ **VPC をホストゾーンに関連付ける** – これは、Kubernetes クラスターの API サーバーのプライベートエンドポイントネットワーキングを有効にするために、Amazon EKS で必要です。
+ **ログイベント** – これは、Amazon EKS が Kubernetes コントロールプレーンログを CloudWatch に送信できるようにするために必要です。
+ **Put メトリクス** – これは Amazon EKS が Kubernetes コントロールプレーンログを CloudWatch に送信できるようにするために必要です。
+ ** `eks` ** - クラスターアクセスエントリとポリシーを管理し、EKS リソースにアクセスできるユーザーと、それらのユーザーが実行できるアクションをきめ細かく制御できるようにします。これにはコンピューティング、ネットワーキング、ロードバランシング、ストレージオペレーションのために標準アクセスポリシーを関連付けることが含まれます。
+ ** `elasticloadbalancing` ** - EKS クラスターに関連付けられているロードバランサーとそのコンポーネント (リスナー、ターゲットグループ、証明書) を作成、管理、削除します。ロードバランサーの属性とヘルスステータスを表示します。
+ **`events`** - EKS クラスターに関連する EC2 イベントと AWS ヘルスイベントをモニタリングするための EventBridge ルールを作成および管理し、インフラストラクチャの変更とヘルスアラートへの自動応答を可能にします。
+ ** `iam` ** - EKS ノードの管理に必要な作成、削除、役割の関連付けなど、「eks」プレフィックスを使用して EC2 インスタンスプロファイルを管理します。ユーザーがそれぞれのワーカーノードのカスタムインスタンスプロファイルを定義できるように、インスタンスプロファイルの記述を許可します。
+ ** `pricing` ** ** `shield` ** - AWS の料金情報と Shield 保護ステータスにアクセスし、EKS リソースのコスト管理と高度なセキュリティ機能を可能にします。
+ **リソースのクリーンアップ** - クラスターのクリーンアップオペレーション中に、ボリューム、スナップショット、起動テンプレート、ネットワークインターフェイスなどの EKS タグ付きリソースを安全に削除します。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html#AmazonEKSServiceRolePolicy-json)」を参照してください。
## AWS 管理ポリシー: AmazonEKSVPCResourceController
`AmazonEKSVPCResourceController` ポリシーを IAM アイデンティティにアタッチできます。[ポッドのセキュリティグループ](security-groups-for-pods.md)を使用している場合はユーザーに代わってアクションを実行させるために、このポリシーを [Amazon EKS クラスターの IAM 役割](cluster-iam-role.md)にアタッチする必要があります。
このポリシーはノードの エラスティック・ネットワーク・インターフェイス と IP アドレスを管理するアクセス権限をクラスター役割に付与します。
**許可の詳細**
このポリシーには、Amazon EKS に以下のタスクを完了させるための以下の権限が含まれています。
+ ** `ec2` ** – Elastic Network Interface と IP アドレスを管理し、Pod のセキュリティグループと Windows ノードをサポートします。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKSVPCResourceController](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html#AmazonEKSVPCResourceController-json)」を参照してください。
## AWS 管理ポリシー: AmazonEKSWorkerNodePolicy
`AmazonEKSWorkerNodePolicy` ポリシーを IAM エンティティにアタッチできます。このポリシーを、Amazon EKS がユーザーに代わってアクションを実行することを許可する Amazon EC2 ノードを作成するときに指定する[ノード IAM 役割](create-node-role.md)にアタッチしなければなりません。`eksctl` を使用してノードグループを作成すると、ノード IAM 役割が作成され、このポリシーを役割に自動的にアタッチします。
このポリシーはアマゾン EKS アマゾン EC2 ノードに アマゾン EKS クラスターに接続するためのアクセス権限を付与します。
**許可の詳細**
このポリシーにはアマゾン EKS に以下のタスクを完了させるための以下の権限が含まれています。
+ ** `ec2` ** – インスタンスボリュームとネットワーク情報を読み取ります。これは、Kubernetes ノードが Amazon EKS クラスターに参加するのに必要な Amazon EC2 リソースに関する情報を記述できるようにするために必要です。
+ ** `eks` ** – オプションで、ノードのブートストラップの一部としてクラスターを記述します。
+ ** `eks-auth:AssumeRoleForPodIdentity` ** – ノード上の EKS ワークロードの認証情報を取得できるようにします。これはEKS Pod Identity が正しく機能するために必要です。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[アマゾンEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html#AmazonEKSWorkerNodePolicy-json) Policy」を参照してください。
## AWS マネージドポリシー: AmazonEKSWorkerNodeMinimalPolicy
IAM エンティティに AmazonEKSWorkerNodeMinimalPolicy をアタッチできます。このポリシーを、Amazon EKS がユーザーに代わってアクションを実行することを許可する Amazon EC2 ノードを作成するときに指定するノード IAM 役割にアタッチすることができます。
このポリシーはアマゾン EKS アマゾン EC2 ノードに アマゾン EKS クラスターに接続するためのアクセス権限を付与します。このポリシーのアクセス許可は AmazonEKSWorkerNodePolicy に比べて少なくなります。
**許可の詳細**
このポリシーにはアマゾン EKS に以下のタスクを完了させるための以下の権限が含まれています。
+ `eks-auth:AssumeRoleForPodIdentity` – ノード上の EKS ワークロードの認証情報を取得できるようにします。これはEKS Pod Identity が正しく機能するために必要です。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[アマゾンEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodeMinimalPolicy.html#AmazonEKSWorkerNodeMinimalPolicy-json) Policy」を参照してください。
## AWS 管理ポリシー: AWSServiceRoleForAmazonEKSNodegroup
IAM エンティティに `AWSServiceRoleForAmazonEKSNodegroup` をアタッチすることはできません。このポリシーはユーザーに代わって アマゾン EKS がアクションを実行することを許可する、サービスにリンクされた役割にアタッチされます。詳細については「[アマゾン EKS でのサービスにリンクされた役割のアクセス許可](using-service-linked-roles-eks-nodegroups.md#service-linked-role-permissions-eks-nodegroups)」を参照してください。
このポリシーは `AWSServiceRoleForAmazonEKSNodegroup` 役割権限を付与し、アカウント内の Amazon EC2 ノードグループを作成および管理できるようにします。
**許可の詳細**
このポリシーにはアマゾン EKS に以下のタスクを完了させるための以下の権限が含まれています。
+ ** `ec2` ** – セキュリティグループ、タグ、キャパシティ予約、および起動テンプレートを操作します。これは Amazon EKS マネージド型ノードグループがリモートアクセス設定を有効にし、マネージド型ノードグループで使用できるキャパシティ予約を記述するために必要です。さらに、Amazon EKS マネージド型ノードグループはユーザーに代わって起動テンプレートを作成します。これは各マネージド型ノードグループをバックアップする Amazon EC2 Auto Scaling グループを設定するためです。
+ ** `iam` ** – サービスにリンクされた役割を作成し、役割を渡します。これは Amazon EKS マネージド型ノードグループが、マネージドノードグループの作成時に渡される役割のインスタンスプロファイルを管理するために必要です。このインスタンスプロファイルはマネージド型ノードグループの一部として起動される Amazon EC2 インスタンスによって使用されます。Amazon EKS は Amazon EC2 Auto Scaling グループなどの他のサービスに対してサービスリンクされた役割を作成する必要があります。これらの権限はマネージド型ノードグループの作成に使用されます。
+ ** `autoscaling` **–セキュリティの Auto Scaling グループを使用します。これはAmazon EKS マネージド型ノードグループが、各マネージドノードグループをバックアップする Amazon EC2 Auto Scaling グループを管理するために必要です。また、ノードグループの更新中にノードが終了またはリサイクルされた場合のポッドのエビクションや、マネージド型ノードグループで構成されたウォームプールの管理などの機能のサポートにも使用されます。
JSON ポリシードキュメントの最新バージョンを確認するには「AWS マネージドポリシーリファレンスガイド」の「[AWSServiceRoleForAmazonEKSNodegroup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html#AWSServiceRoleForAmazonEKSNodegroup-json)」を参照してください。
## AWS マネージドポリシー: AmazonEKSDashboardServiceRolePolicy
IAM エンティティに `AmazonEKSDashboardServiceRolePolicy` をアタッチすることはできません。このポリシーはユーザーに代わって アマゾン EKS がアクションを実行することを許可する、サービスにリンクされた役割にアタッチされます。詳細については、「[Amazon EKS でのサービスにリンクされた役割のアクセス許可](using-service-linked-roles-eks-dashboard.md#service-linked-role-permissions-eks-dashboard)」を参照してください。
このポリシーは `AWSServiceRoleForAmazonEKSDashboard` 役割権限を付与し、アカウント内の Amazon EC2 ノードグループを作成および管理できるようにします。
**アクセス許可の詳細**
このポリシーには、以下のタスクを完了させるためにアクセスできる次の権限が含まれています。
+ ** `organizations` ** – AWS Organizations の構造とアカウントに関する情報を表示します。これには、組織内のアカウントを一覧表示する、組織単位とルートを表示する、委任された管理者を一覧表示する、組織にアクセスできるサービスを表示する、および組織とアカウントに関する詳細情報を取得する権限が含まれます。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKSDashboardServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json)」を参照してください。
## AWS 管理ポリシー: AmazonEBSCSIDriverPolicy
`AmazonEBSCSIDriverPolicy` ポリシーは Amazon EBS コンテナ・ストレージ・インターフェース (CSI) ドライバーが、ユーザーに代わってボリュームを作成、変更、コピー、アタッチ、デタッチ、削除できるようにします。これには既存のボリュームのタグの変更や、EBS ボリュームでの高速スナップショット復元 (FSR) の有効化が含まれます。また、EBS CSI ドライバーに、スナップショットを作成、ロック、復元、削除したり、インスタンス、ボリューム、スナップショットを一覧表示する権限も付与します。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEBSCSIDriverServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEBSCSIDriverPolicy.html#AmazonEBSCSIDriverPolicy-json)」を参照してください。
## AWS マネージドポリシー: AmazonEFSCSIDriverPolicy
`AmazonEFSCSIDriverPolicy` ポリシーでは Amazon EFS コンテナストレージインターフェイス (CSI) がユーザーに代わってアクセスポイントを作成および削除できるようにすることができます。また、Amazon EFS CSI ドライバーに、アクセスポイント、ファイルシステム、マウントターゲット、Amazon EC2 アベイラビリティゾーンを一覧表示するアクセス許可を付与することもできます。
JSON ポリシードキュメントの最新バージョンを確認するにはAWS マネージドポリシーリファレンスガイドの「[AmazonEFSCSIDriverServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEFSCSIDriverPolicy.html#AmazonEFSCSIDriverPolicy-json)」を参照してください。
## AWS マネージドポリシー: AmazonEKSLocalOutpostClusterPolicy
このポリシーを IAM エンティティにアタッチできます。ローカルクラスターを作成する前に、このポリシーを[クラスターロール](cluster-iam-role.md)にアタッチする必要があります。Amazon EKS によって管理される Kubernetes クラスターは、ユーザーに代わって他の AWS のサービスを呼び出します。これにより、サービスで使用するリソースを管理します。
`AmazonEKSLocalOutpostClusterPolicy` には以下の権限が含まれています。
+ **`ec2` 読み取りアクション** – コントロールプレーンインスタンスがアベイラビリティーゾーン、ルートテーブル、インスタンス、ネットワークインターフェイスのプロパティを記述できるようにします。Amazon EC2 インスタンスがコントロールプレーンインスタンスとして正常にクラスターに参加するために必要なアクセス許可です。
+ **`ssm`** - Amazon EC2 Systems Manager がコントロールプレーンインスタンスに接続できるようにします。これはアカウントのローカルクラスターと通信して管理するために、Amazon EKS によって使用されます。
+ ** `logs` ** - インスタンスが Amazon CloudWatch にログをプッシュできるようにします。
+ **`secretsmanager`** - インスタンスがコントロールプレーンインスタンスのブートストラップデータを AWS 秘密マネジャー から安全に取得および削除できるようにします。
+ ** `ecr` ** - コントロールプレーンインスタンス上で動作している Pod とコンテナが、Amazon Elastic Container Registry に格納されているコンテナイメージをプルできるようにします。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKSLocalOutpostClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostClusterPolicy.html#AmazonEKSLocalOutpostClusterPolicy-json)」を参照してください。
## AWS マネージドポリシー: AmazonEKSLocalOutpostServiceRolePolicy
このポリシーを IAM エンティティにアタッチすることはできません。`iam:CreateServiceLinkedRole` 権限のある IAM プリンシパルを使用してクラスターを作成する場合、Amazon EKS は [AWSServiceRoleforAmazonEKSLocalOutpost](using-service-linked-roles-eks-outpost.md) のサービスにリンクされた役割を自動的に作成し、このポリシーをアタッチします。このポリシーはサービスにリンクされた役割はローカルクラスターの代わりに AWS サービスを呼び出すことを許可します。
`AmazonEKSLocalOutpostServiceRolePolicy` には以下の権限が含まれています。
+ ** `ec2` ** - Amazon EKS がセキュリティ、ネットワーク、その他のリソースと連携して、アカウント内のコントロールプレーンインスタンスを正常に起動および管理できるようにします。
+ ** `ssm`、`ssmmessages` ** – Amazon EC2 システムマネージャーがコントロールプレーンインスタンスに接続できるようにします。アカウントのローカルクラスターと通信および管理するため、Amazon EKS によって使用されます。
+ ** `iam` ** - Amazon EKS がコントロールプレーンインスタンスに関連付けられたインスタンスプロファイルを管理できるようにします。
+ **`secretsmanager`** - Amazon EKS がコントロールプレーンインスタンスのブートストラップデータを AWS 秘密マネジャー に格納できるようにします。これにより、インスタンスのブートストラップ中に安全に参照できるようになります。
+ ** `outposts` ** - Amazon EKS がお客様のアカウントから Outpost 情報を取得して、Outpost でローカルクラスターを正常に起動できるようにします。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKSLocalOutpostServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostServiceRolePolicy.html#AmazonEKSLocalOutpostServiceRolePolicy-json)」を参照してください。
## Amazon EKS による AWS 管理ポリシーの更新
Amazon EKS の AWS 管理ポリシーの更新に関する詳細を、このサービスがこれらの変更の追跡を開始した以降の分について表示します。
この特定のドキュメントページへのすべてのソースファイルの変更通知を受け取るには、RSS リーダーを使用して次の URL をサブスクライブできます。
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/security/iam-reference/security-iam-awsmanpol.adoc.atom
```
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| [AWS 管理ポリシー: AmazonEKSNetworkingPolicy](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy) にアクセス許可が追加されました。 | `AmazonEKSNetworkingPolicy` に `ec2:ModifyNetworkInterfaceAttribute` アクセス許可を追加しました。これにより、Amazon EKS 自動モードコントローラーは EC2 インスタンスに関連するネットワークインターフェイス属性を変更できます。 | 2026 年 2 月 3 日 |
| 許可を [AWS 管理ポリシー: AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup) に追加しました。 | `AWSServiceRoleForAmazonEKSNodegroup` に `autoscaling:PutWarmPool`、`autoscaling:DeleteWarmPool` および `autoscaling:DescribeWarmPool` のアクセス許可を追加しました。これにより、Amazon EKS Managed Nodegroup はノードグループのライフサイクル全体で基盤となる ASG ウォームプールリソースを管理できます。 | 2026 年 2 月 17 日 |
| [AWS 管理ポリシー: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) にアクセス許可が追加されました。 | `AmazonEKSServiceRolePolicy` 内の、`iam:GetInstanceProfile` アクセス許可のターゲットインスタンスプロファイル名に「eks」プレフィックスを付ける要件を削除しました。これにより、Amazon EKS Auto Mode は「eks」という命名プレフィックスを必要とせずに NodeClasses のカスタムインスタンスプロファイルを検証して使用できます。 | 2026 年 2 月 2 日 |
| [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy) にアクセス許可を追加しました。 | EBS CSI ドライバーが EBS スナップショットを直接ロックできるように、`ec2:LockSnapshot` アクセス許可を追加しました。 | 2026 年 1 月 15 日 |
| [AWS マネージドポリシー: AmazonEKSMCPReadOnlyAccess](#security-iam-awsmanpol-amazoneksmcpreadonlyaccess) について説明しました。 | Amazon EKS は、オブザーバビリティとトラブルシューティングのために、Amazon EKS MCP サーバーで読み取り専用ツールを有効にする新しいマネージドポリシー `AmazonEKSMCPReadOnlyAccess` を導入しました。 | 2025 年 11 月 21 日 |
| [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy) にアクセス許可を追加しました。 | EBS CSI ドライバーが EBS ボリュームを直接コピーできるようにする `ec2:CopyVolumes` アクセス許可を追加しました。 | 2025 年 11 月 17 日 |
| [AWS 管理ポリシー: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) にアクセス許可が追加されました。 | `AmazonEKSServiceRolePolicy` に `ec2:DescribeRouteTables` および `ec2:DescribeNetworkAcls` アクセス許可を追加しました。これにより、Amazon EKS はクラスターインサイトの一部として、ハイブリッドノードの VPC ルートテーブルとネットワーク ACL の設定問題を検出できます。 | 2025 年 10 月 22 日 |
| [AWSServiceRoleForAmazonEKSConnector](using-service-linked-roles-eks-connector.md) にアクセス許可が追加されました | `AmazonEKSConnectorServiceRolePolicy` に `ssmmessages:OpenDataChannel` アクセス許可を追加しました。 | 2025 年 10 月 15 日 |
| [AWS 管理ポリシー: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) にアクセス許可が追加されました | このロールは、新しいアクセスポリシー `AmazonEKSEventPolicy` をアタッチできます。`ec2:DeleteLaunchTemplate` と `ec2:TerminateInstances` の制限されたアクセス許可。 | 2025 年 8 月 26 日 |
| [AWS マネージドポリシー: AmazonEKSLocalOutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) にアクセス許可が追加されました | `AmazonEKSLocalOutpostServiceRolePolicy` に `ssmmessages:OpenDataChannel` アクセス許可が追加されました。 | 2025 年 6 月 26 日 |
| [AWS マネージドポリシー: AmazonEKSComputePolicy](#security-iam-awsmanpol-AmazonEKSComputePolicy) にアクセス許可が追加されました。 | キャパシティ予約 ` arn:aws:ec2:*:*:capacity-reservation/*` を含めるため、`ec2:RunInstances` および `ec2:CreateFleet` アクションのリソースアクセス許可が更新されました。これにより、Amazon EKS Auto Mode は、アカウントの EC2 オンデマンドキャパシティ予約を使用してインスタンスを起動できるようになります。Amazon EKS Auto Mode がユーザーに代わって EC2 スポットサービスにリンクされたロール `AWSServiceRoleForEC2Spot` を作成できるように、`iam:CreateServiceLinkedRole` が追加されました。 | 2025 年 6 月 20 日 |
| [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) にアクセス許可を追加しました。 | アカウントの EC2 オンデマンドキャパシティ予約を使用して Amazon EKS Auto Mode がインスタンスを起動できるように、`ec2:DescribeCapacityReservations` アクセス許可が追加されました。 | 2025 年 6 月 20 日 |
| [AWS マネージドポリシー: AmazonEKSDashboardConsoleReadOnly](#security-iam-awsmanpol-amazoneksdashboardconsolereadonly) について説明しました。 | 新しい `AmazonEKSDashboardConsoleReadOnly` ポリシーを導入しました。 | 2025 年 6 月 19 日 |
| [AWS マネージドポリシー: AmazonEKSDashboardServiceRolePolicy](#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy) について説明しました。 | 新しい `AmazonEKSDashboardServiceRolePolicy` ポリシーを導入しました。 | 2025 年 5 月 21 日 |
| [アマゾンEKSClusterPolicy](#security-iam-awsmanpol-amazoneksclusterpolicy) に権限を追加しました。 | VPC CNI が予期せず終了した場合に残された Elastic Network Interface を Amazon EKS が削除できるように、`ec2:DeleteNetworkInterfaces` アクセス許可が追加されました。 | 2025 年 4 月 16 日 |
| [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) にアクセス許可を追加しました。 | EKS 1.33 バージョンリリースの一環として、EKS AI/ML の顧客が EFA と互換性のあるセキュリティグループ Egress (アウトバウンド) ルールをデフォルトの EKS クラスター SG に追加できるように、`ec2:RevokeSecurityGroupEgress` および `ec2:AuthorizeSecurityGroupEgress` アクセス許可が追加されました。 | 2025 年 4 月 14 日 |
| [アマゾンEKSサービスRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) に許可を追加しました。 | EKS Auto Mode によって作成された EC2 インスタンスを終了できるようにアクセス許可を追加しました。 | 2025 年 2 月 28 日 |
| [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy) にアクセス許可を追加しました。 | EBS CSI ドライバーがすべてのスナップショットを復元することを許可する新しいステートメントを追加しました。これは既存のポリシーでは以前は許可されていましたが、`CreateVolume` の IAM の処理が変更されたため、新しい明示的なステートメントが必要になりました。 EBS CSI ドライバーが既存のボリュームのタグを変更する機能を追加しました。EBS CSI ドライバーは、Kubernetes VolumeAttributesClasses のパラメータを介して既存のボリュームのタグを変更できます。 EBS ボリューム上で高速スナップショット復元 (FSR) を有効にするために EBS CSI ドライバーの機能を追加しました。EBS CSI ドライバーは、Kubernetes ストレージクラスのパラメータを介して、新しいボリュームで FSR を有効にできます。 | 2025年1月13日 |
| 許可を [AWS マネージドポリシー: AmazonEKSLoadBalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy) に追加しました。 | `AmazonEKSLoadBalancingPolicy` を更新して、ネットワークおよび IP アドレス リソースの一覧表示と説明ができるようになりました。 | 2024 年 12 月 26 日 |
| 許可を [AWS 管理ポリシー: AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup) に追加しました。 | `AWSServiceRoleForAmazonEKSNodegroup` が中国リージョンとの互換性のために更新されました。 | 2024 年 11 月 22 日 |
| アクセス許可を [AWS マネージドポリシー: AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) に追加しました。 | 各ノードが存在するアベイラビリティーゾーンを、クラスターコントロールプレーンの AWS クラウド コントローラー マネージャー が識別できるように、`AmazonEKSLocalOutpostClusterPolicy` に `ec2:DescribeAvailabilityZones` 許可を追加しました。 | 2024 年 11 月 21 日 |
| 許可を [AWS 管理ポリシー: AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup) に追加しました。 | Amazon EKS マネージドノードグループによって作成されたインスタンスのために `ec2:RebootInstances` を許可するように `AWSServiceRoleForAmazonEKSNodegroup` ポリシーを更新しました。Amazon EC2 リソースについての `ec2:CreateTags` 許可を制限しました。 | 2024 年 11 月 20 日 |
| 許可を [AWS 管理ポリシー: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) に追加しました。 | EKS が AWS マネージドポリシー `AmazonEKSServiceRolePolicy` を更新しました。EKS アクセスポリシー、ロードバランサーの管理、クラスターリソースの自動クリーンアップの許可を追加しました。 | 2024 年 11 月 16 日 |
| [AWS マネージドポリシー: AmazonEKSComputePolicy](#security-iam-awsmanpol-AmazonEKSComputePolicy) について説明しました。 | EKS が AWS マネージドポリシー `AmazonEKSComputePolicy` を更新しました。`iam:AddRoleToInstanceProfile` アクションのリソース許可を更新しました。 | 2024 年 11 月 7 日 |
| [AWS マネージドポリシー: AmazonEKSComputePolicy](#security-iam-awsmanpol-AmazonEKSComputePolicy) について説明しました。 | AWS は `AmazonEKSComputePolicy` を導入しました。 | 2024 年 11 月 1 日 |
| アクセス許可を `AmazonEKSClusterPolicy` に追加しました。 | Amazon EKS がトポロジ情報をラベルとしてノードにアタッチできるようにする `ec2:DescribeInstanceTopology` 許可を追加しました。 | 2024 年 11 月 1 日 |
| [AWS マネージドポリシー: AmazonEKSBlockStoragePolicy](#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy) について説明しました。 | AWS は `AmazonEKSBlockStoragePolicy` を導入しました。 | 2024 年 10 月 30 日 |
| [AWS マネージドポリシー: AmazonEKSLoadBalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy) について説明しました。 | AWS は `AmazonEKSLoadBalancingPolicy` を導入しました。 | 2024 年 10 月 30 日 |
| [アマゾンEKSサービスRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) に許可を追加しました。 | Amazon EKS が Amazon CloudWatch にメトリクスを発行できるようにする `cloudwatch:PutMetricData` 許可を追加しました。 | 2024 年 10 月 29 日 |
| [AWS 管理ポリシー: AmazonEKSNetworkingPolicy](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy) について説明しました。 | AWS は `AmazonEKSNetworkingPolicy` を導入しました。 | 2024 年 10 月 28 日 |
| `AmazonEKSServicePolicy` および `AmazonEKSServiceRolePolicy` にアクセス許可を追加しました。 | EKS がセキュリティグループ情報を読み取り、関連するタグを更新できるように、`ec2:GetSecurityGroupsForVpc` および関連するタグの許可を追加しました。 | 2024 年 10 月 10 日 |
| [AmazonEKSWorkerNodeMinimalPolicy](#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy) を導入しました。 | AWS は `AmazonEKSWorkerNodeMinimalPolicy` を導入しました。 | 2024 年 10 月 3 日 |
| [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup) に権限を追加しました。 | Amazon EKS が管理する 自動スケーリング グループで Amazon EKS が `AZRebalance` を一時停止および再開できるようにする `autoscaling:ResumeProcesses` および `autoscaling:SuspendProcesses` アクセス許可が追加されました。 | 2024 年 8 月 21 日 |
| [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup) に権限を追加しました。 | Amazon EKS がユーザーのアカウントでキャパシティ予約を記述できるようにする `ec2:DescribeCapacityReservations` アクセス許可を追加しました。`CAPACITY_BLOCK` ノードグループでスケジュールされたスケーリングの設定を有効にする `autoscaling:PutScheduledUpdateGroupAction` アクセス許可を追加しました。 | 2024 年 6 月 27 日 |
| [AmazonEKS\$1CNI\$1Policy](#security-iam-awsmanpol-amazoneks-cni-policy) – 既存のポリシーへの更新 | Amazon EKS は、Amazon VPC CNI Plugin for Kubernetes で Amazon VPC サブネット内の空き IP アドレスの量を確認できるようにする新しい `ec2:DescribeSubnets` 許可を追加しました。VPC CNI は各サブネットの空き IP アドレスを使用して、エラスティック・ネットワーク・インターフェイス の作成時に使用する空き IP アドレスが最も多いサブネットを選択できます。 | 2024 年 3 月 4 日 |
| [AmazonEKSWorkerNodePolicy](#security-iam-awsmanpol-amazoneksworkernodepolicy) – 既存のポリシーへの更新 | Amazon EKS は EKS Pod Identity を許可する新しいアクセス権限を追加しました。Amazon EKS Pod Identity エージェントはノード役割を使用します。 | 2023 年 11 月 26 日 |
| [AmazonEFSCSIDriverPolicy](#security-iam-awsmanpol-amazonefscsidriverservicerolepolicy) を導入しました。 | AWS は `AmazonEFSCSIDriverPolicy` を導入しました。 | 2023 年 7 月 26 日 |
| [アマゾンEKSClusterPolicy](#security-iam-awsmanpol-amazoneksclusterpolicy) に権限を追加しました。 | ロードバランサーを作成しながら、サブネットの自動検出中に Amazon EKS が AZ の詳細を取得できるようにする `ec2:DescribeAvailabilityZones` 許可が追加されました。 | 2023 年 2 月 7 日 |
| [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy) のポリシー条件が更新されました。 | `StringLike` キーフィールドにワイルドカード文字を含む無効なポリシー条件を削除しました。また `ec2:DeleteVolume` に新しい条件 `ec2:ResourceTag/kubernetes.io/created-for/pvc/name: "*"` も追加され、ツリー内プラグインで作成されたボリュームを EBS CSI ドライバーが削除できるようになりました。 | 2022 年 11 月 17 日 |
| [AmazonEKSLocalOutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) にアクセス許可を追加しました。 | 前提条件の検証とマネージドライフサイクルの管理が向上するように、`ec2:DescribeVPCAttribute`、`ec2:GetConsoleOutput`、`ec2:DescribeSecret` を追加しました。また、Outposts のコントロールプレーン Amazon EC2 インスタンスの配置制御をサポートするため、`ec2:DescribePlacementGroups`、`"arn:aws:ec2:*:*:placement-group/*"`、`ec2:RunInstances` が追加しました。 | 2022 年 10 月 24 日 |
| [AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) の Amazon Elastic Container Registry のアクセス権限を更新します。 | `ecr:GetDownloadUrlForLayer` アクションを、全リソースセクションからスコープされたセクションに移動しました。` arn:aws:ecr:*:*:repository/eks/ ` リソースを追加しました。` arn:aws:ecr:` リソースを削除しました。このリソースは追加された ` arn:aws:ecr:*:*:repository/eks/*` リソースでカバーします。 | 2022 年 10 月 20 日 |
| [AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) にアクセス許可を追加しました。 | クラスターコントロールプレーンインスタンスがいくつかの `kubelet` 引数を更新できるように、` arn:aws:ecr:*:*:repository/kubelet-config-updater` Amazon Elastic Container Registry リポジトリを追加しました。 | 2022 年 8 月 31 日 |
| [AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) を導入しました。 | AWS は `AmazonEKSLocalOutpostClusterPolicy` を導入しました。 | 2022 年 8 月 24 日 |
| [AmazonEKSLocalOutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) を導入しました。 | AWS は `AmazonEKSLocalOutpostServiceRolePolicy` を導入しました。 | 2022 年 8 月 23 日 |
| [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy) を導入しました。 | AWS は `AmazonEBSCSIDriverPolicy` を導入しました。 | 2022 年 4 月 4 日 |
| [AmazonEKSWorkerNodePolicy](#security-iam-awsmanpol-amazoneksworkernodepolicy) に権限を追加しました。 | インスタンスレベルのプロパティを自動検出できる Amazon EKS に最適化された AMI を有効化する `ec2:DescribeInstanceTypes` を追加しました。 | 2022 年 3 月 21 日 |
| [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup) に権限を追加しました。 | Amazon EKS がメトリクスの収集を有効にすることを許可する `autoscaling:EnableMetricsCollection` アクセス許可を追加しました。 | 2021 年 12 月 13 日 |
| [アマゾンEKSClusterPolicy](#security-iam-awsmanpol-amazoneksclusterpolicy) に権限を追加しました。 | `ec2:DescribeAccountAttributes`、`ec2:DescribeAddresses`、`ec2:DescribeInternetGateways` の権限を追加し、Amazon EKS が Network Load Balancer のサービスにリンクされた役割を作成できるようになりました。 | 2021 年 6 月 17 日 |
| Amazon EKS が変更の追跡を開始しました。 | Amazon EKS が AWS 管理ポリシーの変更の追跡を開始しました。 | 2021 年 6 月 17 日 |
# IAM のトラブルシューティング
このトピックでは、IAM での Amazon EKS の使用中に表示される一般的なエラーとその回避方法について説明します。
## AccessDeniedException
AWS API オペレーションの呼び出し時に `AccessDeniedException` を受け取った場合、使用している [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)の認証情報には、その呼び出しに必要な許可がありません。
```
An error occurred (AccessDeniedException) when calling the DescribeCluster operation:
User: arn:aws:iam::111122223333:user/user_name is not authorized to perform:
eks:DescribeCluster on resource: arn:aws:eks:region:111122223333:cluster/my-cluster
```
前記のメッセージの例では、ユーザーには Amazon EKS `DescribeCluster` API オペレーションを呼び出す許可がありません。IAM プリンシパルに Amazon EKS 管理者の許可を付与するには、「[Amazon EKS でのアイデンティティベースのポリシーの例](security-iam-id-based-policy-examples.md)」を参照してください。
IAM の一般的な情報については、*IAM ユーザーガイド*の「[ポリシーを使用したアクセスの制御](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html)」を参照してください。
## **[Compute]** (コンピューティング) タブに **[Nodes]** (ノード) が表示されず、また **[Resources]** (リソース) タブにも何も表示されず、AWS マネジメントコンソール でエラーが表示される
`Your current user or role does not have access to Kubernetes objects on this EKS cluster`というコンソールのエラーメッセージが表示されることがあります。AWS マネジメントコンソール を使用している [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)ユーザーに必要な許可があることを確認してください。詳細については、「[必要なアクセス許可](view-kubernetes-resources.md#view-kubernetes-resources-permissions)」を参照してください。
## aws-auth `ConfigMap` がクラスターへのアクセスを許可しない
[AWS IAM Authenticator](https://github.com/kubernetes-sigs/aws-iam-authenticator) は、`ConfigMap` で使用されるロール ARN でパスを許可しません。したがって、`rolearn` を指定する前に、パスを削除してください。例えば、` arn:aws:iam::111122223333:role/team/developers/eks-admin ` を ` arn:aws:iam::111122223333:role/eks-admin ` に変更します。
## iam:PassRole を実行する権限がありません
`iam:PassRole` アクションを実行する権限がないというエラーが表示された場合は、ポリシーを更新して Amazon EKS にロールを渡せるようにする必要があります。
一部の AWS サービスでは、新しいサービスロールまたはサービスリンクロールを作成せずに、既存のロールをサービスに渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。
次の例のエラーは、`marymajor` という IAM ユーザーがコンソールを使用して Amazon EKS でアクションを実行しようとする場合に発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与されたアクセス許可が必要です。Mary には、ロールをサービスに渡すアクセス許可がありません。
```
User: {arn-aws}iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
この場合、メアリーのポリシーを更新してメアリーに `iam:PassRole` アクションの実行を許可する必要があります。
サポートが必要な場合は、AWS 管理者に問い合わせてください。サインイン認証情報を提供した担当者が管理者です。
## AWS アカウント以外のユーザーに Amazon EKS リソースへのアクセスを許可したい
他のアカウントのユーザーや組織外のユーザーが、リソースへのアクセスに使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。
詳細については、以下を参照してください。
+ Amazon EKS がこれらの機能をサポートしているかどうかについては、「[アマゾン EKS で IAM を使用する方法](security-iam-service-with-iam.md)」を参照してください。
+ 所有している AWS アカウント間でリソースへのアクセスを付与する方法については、*IAM ユーザーガイド* の「[所有している別の AWS アカウントへのアクセスを IAM ユーザーに許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)」を参照してください。
+ リソースへのアクセスをサードパーティーの AWS アカウントに提供する方法については、IAM ユーザーガイドの「[サードパーティーが所有する AWS アカウントへのアクセスの提供](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)」を参照してください。
+ ID フェデレーションを介してアクセスを提供する方法については、*IAM ユーザーガイド* の [外部で認証されたユーザー (ID フェデレーション) へのアクセスの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) を参照してください。
+ クロスアカウントアクセスにおけるロールとリソースベースのポリシーの使用方法の違いについては、*IAM ユーザーガイド* の [IAM でのクロスアカウントのリソースへのアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。
## ポッドコンテナは次のエラーを受け取ります: `An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region`
アプリケーションが AWS STS グローバルエンドポイント (`https://sts.amazonaws`) に明示的にリクエストを行っていて、Kubernetes サービスアカウントがリージョンエンドポイントを使用するように設定されている場合、コンテナはこのエラーを受け取ります。次のいずれかのオプションを使用して問題を解決できます。
+ アプリケーションコードを更新して、AWS STS グローバルエンドポイントへの明示的な呼び出しを削除します。
+ アプリケーションコードを更新して、`https://sts.us-west-2.amazonaws.com` などのリージョンエンドポイントへの明示的な呼び出しを行います。AWS リージョン内のサービスに障害が発生した場合に別の AWS リージョンを選択するよう、アプリケーションに冗長性が組み込まれている必要があります。詳細については、IAM ユーザーガイドの「[AWS リージョンでの AWS STS の管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html)」を参照してください。
+ グローバルエンドポイントを使用するようにサービスアカウントを設定します。クラスターでは、デフォルトでリージョンエンドポイントが使用されます。詳細については、「[サービスアカウントの AWS Security Token Service エンドポイントを設定する](configure-sts-endpoint.md)」を参照してください。
# Amazon EKS クラスター の IAM ロール
Amazon EKS クラスター IAM ロールはクラスターごとに必要です。Amazon EKS によって管理される Kubernetes クラスターはこのロールを使用してノードを管理し、[レガシークラウドプロバイダー](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider)はこのロールを使用して Elastic Load Balancing によるロードバランサーをサービス用に作成します。
Amazon EKS クラスターを使用するには、事前に次の IAM ポリシーのいずれかを持つ IAM ロールを作成する必要があります。
+ [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html)
+ カスタム IAM ポリシー。以下の最小限の許可では、Kubernetes クラスターがノードを管理することはできますが、[レガシークラウドプロバイダー](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider)が Elastic Load Balancing によるロードバランサーを作成することはできません。カスタム IAM ポリシーには、少なくとも以下の許可が必要です。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"ForAnyValue:StringLike": {
"aws:TagKeys": "kubernetes.io/cluster/*"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeVpcs",
"ec2:DescribeDhcpOptions",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeInstanceTopology",
"kms:DescribeKey"
],
"Resource": "*"
}
]
}
```
**注記**
2023 年 10 月 3 日より前は、各クラスターの IAM ロールには [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) が必要でした。
2020 年 4 月 16 日までは、[AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) および [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) が必須であり、ロールに推奨される名前は `eksServiceRole` でした。`AWSServiceRoleForAmazonEKS` のサービスにリンクされたロールにより、2020 年 4 月 16 日以降に作成されたクラスターに対しては、[AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) ポリシーは必要なくなりました。
## 既存のクラスターロールの確認
次の手順を使用して、アカウントに Amazon EKS クラスターロールが既に存在しているかどうかが確認できます。
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. ロールのリストで `eksClusterRole` を検索します。`eksClusterRole` が含まれているロールが存在しない場合は、[Amazon EKS でのクラスターロールの作成](#create-service-role) を参照してロールを作成します。`eksClusterRole` が含まれているロールが存在する場合はこのロールを選択してアタッチされているポリシーを表示します。
1. **[許可]** を選択してください。
1. **AmazonEKSClusterPolicy** 管理ポリシーがロールにアタッチされていることを確認します。ポリシーがアタッチされている場合、Amazon EKS クラスターロールは適切に設定されています。
1. **[Trust relationships]** (信頼関係）を 選択し、**[Edit trust policy]** (信頼ポリシーの編集）を選択してください。
1. 信頼関係に以下のポリシーが含まれていることを確認します。信頼関係が以下のポリシーと一致する場合、**[キャンセル]** を選択してください。信頼関係が一致しない場合、ポリシーを **[信頼ポリシーの編集]** ウィンドウにコピーし、**[ポリシーの更新]** を選択します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
## Amazon EKS でのクラスターロールの作成
クラスターロールを作成するにはAWS マネジメントコンソール または AWS CLI を使用できます。
AWS マネジメントコンソール
1. https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。
1. [**ロール**] を選択してから [**ロールの作成**] を選びます。
1. [**信頼できるエンティティタイプ**] の下で、[**AWS サービス**] を選択してください。
1. [**他の AWS サービスのユースケース**] ドロップダウンリストから、[**EKS**] を選択してください。
1. ユースケースに **[EKS - Cluster]** (EKS - クラスター）を 選択し、**[ 次へ]** (次へ）を 選択してください。
1. **[Add permissions]** (アクセス許可を追加する) タブで、**[Next]** (次へ) を選択します。
1. **[ロール名]** に、`eksClusterRole` などのロールの一意の名前を入力します。
1. **[Description]** (説明） には`Amazon EKS - Cluster role` のような説明文を入力してください。
1. [**ロールの作成**] を選択してください。
AWS CLI
1. 次の内容を *cluster-trust-policy.jsonl* という名前のファイルにコピーします。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. ロールを作成します。*eksClusterRole* は、任意の名前で置き換えることができます。
```
aws iam create-role \
--role-name eksClusterRole \
--assume-role-policy-document file://"cluster-trust-policy.json"
```
1. 必要な IAM ポリシーをロールにアタッチします。
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy \
--role-name eksClusterRole
```
# Amazon EKS ノードの IAM ロール
Amazon EKS ノード `kubelet` デーモンが、ユーザーに代わって AWS API への呼び出しを実行します。ノードは、IAM インスタンスプロファイルおよび関連ポリシーを通じて、これらの API コールのアクセス許可を受け取ります。ノードを起動してクラスターに登録する前に、起動するときに使用するノード用の IAM ロールを作成する必要があります。この要件は、Amazon が提供する Amazon EKS 最適化 AMI で起動されたノード、または使用する予定の他のノード AMI で起動されたノードに適用されます。さらに、この要件はマネージド型ノードグループとセルフマネージド型ノードの両方に適用されます。
**注記**
クラスターの作成に使用したロールは使用できません。
ノードを使用するには、次の アクセス許可を持つ IAM ロールを作成する必要があります。
+ `kubelet` が VPC 内の Amazon EC2 リソースを記述するためのアクセス許可 ([AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html) ポリシーで規定されているなど)。このポリシーは、Amazon EKS Pod Identity エージェントのアクセス許可も提供します。
+ `kubelet` が Amazon Elastic Container Registry (Amazon ECR) のコンテナイメージを使用するためのアクセス許可 ([AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ContainerRegistryPullOnly.html) ポリシーで規定されているなど)。ネットワーキング用の組み込みアドオンは Amazon ECR のコンテナイメージを使用するポッドを実行するため、Amazon Elastic Container Registry (Amazon ECR) のコンテナイメージを使用する許可が必要です。
+ (オプション) Amazon EKS Pod Identity エージェントが `eks-auth:AssumeRoleForPodIdentity` アクションを使用してポッドの認証情報を取得するためのアクセス許可。[AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html) を使用しない場合、EKS Pod Identity を使用するには EC2 アクセス許可に加えてこのアクセス許可も提供する必要があります。
+ (任意) IRSA または EKS Pod Identity を使用して VPC CNI ポッドにアクセス許可を付与しない場合は、インスタンスロールで VPC CNI のアクセス許可を付与する必要があります。[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html) マネージドポリシー (`IPv4` ファミリーを使用してクラスターを作成した場合) または[作成した IPv6 ポリシー](cni-iam-role.md#cni-iam-role-create-ipv6-policy) (`IPv6` ファミリーを使用してクラスターを作成した場合) のいずれかを使用できます。ただし、このロールにポリシーをアタッチするのではなく、Amazon VPC CNI アドオン専用の別のロールにポリシーをアタッチすることをお勧めします。Amazon VPC CNI アドオン用に別のロールを作成する方法の詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。
**注記**
Amazon EC2 ノードグループには、Fargate プロファイルとは異なる IAM ロールが必要です。詳細については、「[Amazon EKS Pod 実行 IAM ロール](pod-execution-role.md)」を参照してください。
## 既存のノードロールの確認
以下の手順を使用して、アカウントに既に Amazon EKS ノードロールがあるかどうかが確認できます。
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. ロールのリストで `eksNodeRole`、`AmazonEKSNodeRole`、または `NodeInstanceRole` を検索します。これらの名前のいずれかを持つロールが存在しない場合、「[Amazon EKS ノードでの IAM ロールの作成](#create-worker-node-role)」を参照してロールを作成してください。`eksNodeRole`、`AmazonEKSNodeRole`、あるいは `NodeInstanceRole` を含むロールが存在する場合、そのロールを選択して、アタッチされているポリシーを表示します。
1. **[許可]** を選択してください。
1. **AmazonEKSWorkerNodePolicy** および **AmazonEC2ContainerRegistryPullOnly** のマネージドポリシーがロールにアタッチされていること、またはカスタムポリシーが最小限の許可でアタッチされていることを確認します。
**注記**
そのロールに [**AmazonEKS\$1CNI\$1Policy**] ポリシーがアタッチされている場合は、そのポリシーを一度削除して、`aws-node` Kubernetes サービスアカウントにマッピングされた IAM ロールにアタッチし直すことをお勧めします。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。
1. **[信頼関係]** を選択し、**[信頼ポリシーの編集]** を選択します。
1. 信頼関係に以下のポリシーが含まれていることを確認します。信頼関係が以下のポリシーと一致する場合、**[キャンセル]** を選択してください。信頼関係が一致しない場合、ポリシーを **[信頼ポリシーの編集]** ウィンドウにコピーし、**[ポリシーの更新]** を選択してください。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Principal": {
"Service": [
"ec2.amazonaws.com"
]
}
}
]
}
```
## Amazon EKS ノードでの IAM ロールの作成
AWS マネジメントコンソール または AWS CLI を使用して、ノードの IAM ロールを作成できます。
AWS マネジメントコンソール
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. **[ロール]** ページで、**[ロールの作成]** を選択してください。
1. **[信頼されたエンティティを選択]** ページで、以下の操作を実行してください：
1. **[信頼するエンティティのタイプ]** で **[AWS サービス]** を選択してください。
1. **[ユースケース]** で、**[EC2]** を選択してください。
1. [**次へ**] を選択します。
1. **[アクセス許可を追加]** ページで、カスタムポリシーをアタッチするか、以下の操作を行います。
1. **[フィルタポリシー]** ボックスに `AmazonEKSWorkerNodePolicy` と入力します。
1. 検索結果の **[AmazonEKSWorkerNodePolicy]** の左にあるチェックボックスを選択します。
1. **[フィルターのクリア]** を選択します。
1. **[フィルタポリシー]** ボックスに `AmazonEC2ContainerRegistryPullOnly` と入力します。
1. 検索結果の **[AmazonEC2ContainerRegistryPullOnly]** の左にあるチェックボックスを選択します。
このロールまたは `aws-node` Kubernetes サービスアカウントにマッピングされた別のロールに、**AmazonEKS\$1CNI\$1Policy** マネージドポリシーまたは作成した [IPv6 ポリシー](cni-iam-role.md#cni-iam-role-create-ipv6-policy)をアタッチする必要もあります。このロールに対してではなく、Kubernetes サービスアカウントに関連付けられたロールに、前出のポリシーを割り当てることをお勧めします。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。
1. **[Next]** (次へ) を選択します。
1. **[名前を付けて、レビューし、作成する]** ページで、以下の操作を実行します。
1. **[ロール名]** に、`AmazonEKSNodeRole` などのロールの一意の名前を入力します。
1. **[説明]** では現在のテキストを「`Amazon EKS - Node role`」などの説明文に置き換えます。
1. **[タグの追加 (オプション)]** で、タグをキーバリューのペアとして添付して、メタデータをロールに追加します。IAM でのタグの使用に関する詳細については『*IAM ユーザーガイド*』の「[IAM リソースにタグを付ける](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html)」を参照してください。
1. [**ロールの作成**] を選択してください。
AWS CLI
1. 次のコマンドを実行して、`node-role-trust-relationship.json` ファイルを作成します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Principal": {
"Service": [
"ec2.amazonaws.com"
]
}
}
]
}
```
1. IAM ロールの作成
```
aws iam create-role \
--role-name AmazonEKSNodeRole \
--assume-role-policy-document file://"node-role-trust-relationship.json"
```
1. IAM ロールに、2 つの必須なマネージド IAM ポリシーをアタッチします。
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \
--role-name AmazonEKSNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly \
--role-name AmazonEKSNodeRole
```
1. クラスターを作成した IP ファミリーに応じて、次の IAM ポリシーの 1 つを IAM ロールにアタッチします。このポリシーは、このロール、または、Kubernetes の `aws-node` サービスアカウントに関連付けられたロールにアタッチされる必要があります。これらのロールは、Amazon VPC CNI plugin for Kubernetes で使用されます。このポリシーは、Kubernetes サービスアカウントに関連付けられたロールにを割り当てることをお勧めします。Kubernetes サービスアカウントに関連付けられたロールへのポリシーの割り当てについては、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照しください。
+ IPv4
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \
--role-name AmazonEKSNodeRole
```
+ IPv6
1. 次のテキストをコピーし、`vpc-cni-ipv6-policy.json` という名前のファイルに保存します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssignIpv6Addresses",
"ec2:DescribeInstances",
"ec2:DescribeTags",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeInstanceTypes"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
1. IAM ポリシーを作成する
```
aws iam create-policy --policy-name AmazonEKS_CNI_IPv6_Policy --policy-document file://vpc-cni-ipv6-policy.json
```
1. IAM ロールに IAM ポリシーをアタッチします。*111122223333* は、ご自分のアカウント ID に置き換えます。
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::111122223333:policy/AmazonEKS_CNI_IPv6_Policy \
--role-name AmazonEKSNodeRole
```
# Amazon EKS 自動モードl クラスター IAM ロール
Amazon EKS クラスター IAM ロールはクラスターごとに必要です。Amazon EKS によって管理される Kubernetes クラスターはこのロールを使用して、ストレージ、ネットワーキング、コンピューティングの自動スケーリングのルーチンタスクを自動化します。
Amazon EKS クラスターを使用するにはEKS 自動モードl に必要なポリシーを持つ IAM ロールを作成する必要があります。推奨の AWS IAM マネージドポリシーをアタッチするか、同等のアクセス許可を持つカスタムポリシーを作成することができます。
+ [Amazon EKSコンピュートポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [Amazon EKSブロックストレージポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [Amazon EKSロードバランシングポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [Amazon EKSネットワーキングポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
## 既存のクラスターロールの確認
次の手順を使用して、アカウントに Amazon EKS クラスターロールが既に存在しているかどうかが確認できます。
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. ロールのリストで `AmazonEKSAutoClusterRole` を検索します。`AmazonEKSAutoClusterRole` を含むロールが存在しない場合は次のセッションの手順を参照してロールを作成します。`AmazonEKSAutoClusterRole` が含まれているロールが存在する場合はこのロールを選択してアタッチされているポリシーを表示します。
1. **[許可]** を選択してください。
1. **AmazonEKSClusterPolicy** 管理ポリシーがロールにアタッチされていることを確認します。ポリシーがアタッチされている場合、Amazon EKS クラスターロールは適切に設定されています。
1. **[Trust relationships]** (信頼関係）を 選択し、**[Edit trust policy]** (信頼ポリシーの編集）を選択してください。
1. 信頼関係に以下のポリシーが含まれていることを確認します。信頼関係が以下のポリシーと一致する場合、**[キャンセル]** を選択してください。信頼関係が一致しない場合、ポリシーを **[信頼ポリシーの編集]** ウィンドウにコピーし、**[ポリシーの更新]** を選択してください。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
**注記**
AWS ではこのロールの名前 `AmazonEKSAutoClusterRole` は必要ありません。
## Amazon EKS でのクラスターロールの作成
クラスターロールを作成するにはAWS マネジメントコンソール または AWS CLI を使用できます。
### AWS マネジメントコンソール
1. https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。
1. [**ロール**] を選択してから [**ロールの作成**] を選びます。
1. [**信頼できるエンティティタイプ**] の下で、[**AWS サービス**] を選択してください。
1. [**他の AWS サービスのユースケース**] ドロップダウンリストから、[**EKS**] を選択してください。
1. ユースケースに **[EKS - Cluster]** (EKS - クラスター）を 選択し、**[ 次へ]** (次へ）を 選択してください。
1. **[アクセス許可を追加]** タブで、ポリシーを選択し、**[次へ]** を選択してください。
+ [Amazon EKSコンピュートポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [Amazon EKSブロックストレージポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [Amazon EKSロードバランシングポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [Amazon EKSネットワーキングポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [アマゾンEKSクラスターポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
1. **[ロール名]** に、`AmazonEKSAutoClusterRole` などのロールの一意の名前を入力します。
1. **[Description]** (説明） には`Amazon EKS - Cluster role` のような説明文を入力してください。
1. [**ロールの作成**] を選択してください。
### AWS CLI
1. 次の内容を *cluster-trust-policy.jsonl* という名前のファイルにコピーします。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
1. ロールを作成します。*AmazonEKSAutoClusterRole* は任意の名前に置き換えることができます。
```
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://"cluster-trust-policy.json"
```
1. 必要な IAM ポリシーをロールにアタッチします：
**AmazonEKSClusterPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
```
**AmazonEKSコンピュートポリシー**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSComputePolicy
```
**AmazonEKSブロックストレージポリシー**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSBlockStoragePolicy
```
**AmazonEKSロードバランシングポリシー**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSLoadBalancingPolicy
```
**Amazon EKSネットワーキングポリシー**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSNetworkingPolicy
```
# Amazon EKS 自動モードl ノードの IAM ロール
**注記**
クラスターの作成に使用したロールは使用できません。
ノードを作成する前に、次のパイプラインまたは同等のアクセス許可を持つ IAM ロールを作成する必要があります：
+ [Amazon EKSワーカーノードミニマルポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [Amazon EC2コンテナレジストリプルオンリー](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
## 既存のノードロールの確認
以下の手順を使用して、アカウントに既に Amazon EKS ノードロールがあるかどうかが確認できます。
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. ロールのリストで `AmazonEKSAutoNodeRole` を検索します。これらの名前のいずれかを持つロールが存在しない場合は次のセクションの手順を参照してロールを作成します。`AmazonEKSAutoNodeRole` を含むロールがある場合はロールを選択して、アタッチされたポリシーを表示します。
1. **[許可]** を選択してください。
1. 上記の必要なポリシーまたは同等のカスタムポリシーがアタッチされていることを確認します。
1. **[信頼関係]** を選択し、**[信頼ポリシーの編集]** を選択してください。
1. 信頼関係に以下のポリシーが含まれていることを確認します。信頼関係が以下のポリシーと一致する場合、**[キャンセル]** を選択してください。信頼関係が一致しない場合、ポリシーを **[信頼ポリシーの編集]** ウィンドウにコピーし、**[ポリシーの更新]** を選択してください。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
## Amazon EKS ノードでの IAM ロールの作成
AWS マネジメントコンソール または AWS CLI を使用して、ノードの IAM ロールを作成できます。
### AWS マネジメントコンソール
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. **[ロール]** ページで、**[ロールの作成]** を選択してください。
1. **[信頼されたエンティティを選択]** ページで、以下の操作を実行してください：
1. **[信頼するエンティティのタイプ]** で **[AWS サービス]** を選択してください。
1. **[ユースケース]** で、**[EC2]** を選択してください。
1. [** 次へ**] を選択してください。
1. **[アクセス許可を追加]** ページで、次のポリシーをアタッチします：
+ [Amazon EKSワーカーノードミニマルポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [Amazon EC2コンテナレジストリプルオンリー](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
1. **[名前を付けて、レビューし、作成する]** ページで、以下の操作を実行してください：
1. **[ロール名]** に、`AmazonEKSAutoNodeRole` などのロールの一意の名前を入力します。
1. **[説明]** では現在のテキストを「`Amazon EKS - Node role`」などの説明文に置き換えます。
1. **[タグの追加 (オプション)]** で、タグをキーバリューのペアとして添付して、メタデータをロールに追加します。IAM でのタグの使用に関する詳細については『*IAM ユーザーガイド*』の「[IAM リソースにタグを付ける](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html)」を参照してください。
1. [**ロールの作成**] を選択してください。
### AWS CLI
**ノード IAM ロールを作成する**
前のステップの **node-trust-policy.json** ファイルを使用して、ロールを引き受けることができるエンティティを定義します。次のコマンドを実行してノード IAM ロールを作成します：
```
aws iam create-role \
--role-name AmazonEKSAutoNodeRole \
--assume-role-policy-document file://node-trust-policy.json
```
**ロールの ARN をメモする**
ロールを作成したら、ノード IAM ロールの ARN を取得して保存します。以降のステップでこの ARN が必要になります。次のコマンドを使用して ARN を取得します：
```
aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text
```
**必要なポリシーをアタッチする**
次の AWS マネージドポリシーをノード IAM ロールにアタッチして、必要なアクセス許可を付与します：
Amazon EKSワーカーノードミニマルポリシー をアタッチするには:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy
```
Amazon EC2コンテナレジストリプルオンリー をアタッチするには:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
# Amazon EKS 機能 IAM ロール
EKS 機能には、機能 IAM ロール (または機能ロール) を設定する必要があります。機能は、このロールを使用して AWS サービスに対してアクションを実行し、自動的に作成されたアクセスエントリを介してクラスター内の Kubernetes リソースにアクセスします。
機能の作成時に機能ロールを指定する場合は、事前に IAM ロールを作成してその機能のタイプに適した信頼ポリシーとアクセス許可を付与する必要があります。このように作成した IAM ロールは、任意の数の機能リソースで再利用できます。
## 機能ロールの要件
機能ロールは、以下の要件を満たしている必要があります。
+ クラスターおよび機能リソースと同じ AWS アカウントに存在する必要があります
+ 信頼ポリシーにより、EKS 機能サービスがロールを引き受けることを許可する必要があります。
+ 機能タイプとユースケースの要件に適したアクセス許可を付与する必要があります (「[機能タイプ別のアクセス許可](#capability-permissions)」を参照)。
## 機能ロールの信頼ポリシー
すべての機能ロールに、次の信頼ポリシーを含める必要があります。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
この信頼ポリシーにより、EKS は以下のことを行うことができます。
+ AWS API オペレーションを実行するロールを引き受けます。
+ 監査と追跡の目的でセッションにタグを付けます。
## 機能タイプ別のアクセス許可
必要な IAM アクセス許可は、使用している機能と現在のデプロイモデルによって異なります。
**注記**
本番稼働でのデプロイに IAM ロールセレクターと ACK を使用する場合や、AWS サービスを統合することなく kro または Argo CD を使用する場合、機能ロールには信頼ポリシー以外に IAM アクセス許可は必要ありません。
**kro (Kube Resource Orchestrator)**
必須の IAM アクセス許可はありません。ポリシーをアタッチせずに機能ロールを作成できます。kro に必要なのは Kubernetes リソースを作成および管理するための Kubernetes RBAC アクセス許可のみです。
**Kubernetes 用 AWS コントローラー (ACK)**
ACK は、2 つのアクセス許可モデルをサポートしています。
+ **シンプルなセットアップ (開発/テスト)**: AWS サービスアクセス許可を機能ロールに直接追加します。これは、使用を開始する場合、シングルアカウントでデプロイする場合、またはすべてのユーザーに同じアクセス許可が必要な場合に適しています。
+ **本番稼働のベストプラクティス**: IAM ロールセレクターを使用して最小特権のアクセスを実装します。このアプローチで機能ロールに必要なのは、サービス固有のロールを引き受ける `sts:AssumeRole` アクセス許可のみです。機能ロール自体に AWS サービスアクセス許可 (S3 や RDS など) を追加しないでください。そうしたアクセス許可は、特定の名前空間にマッピングされた個々の IAM ロールに付与します。
IAM ロールセレクターにより、以下のことを行うことができます。
+ 名前空間レベルでのアクセス許可の分離
+ クロスアカウントリソース管理
+ チームに固有の IAM ロール
+ 最小特権セキュリティモデル
IAM ロールセレクターによるアプローチでの機能ロールポリシーの例:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::111122223333:role/ACK-S3-Role",
"arn:aws:iam::111122223333:role/ACK-RDS-Role",
"arn:aws:iam::444455556666:role/ACKCrossAccountRole"
]
}
]
}
```
IAM ロールセレクターなど ACK アクセス許可の詳細な設定については、「[ACK アクセス許可を設定する](ack-permissions.md)」を参照してください。
**Argo CD**
デフォルトでは、必須の IAM アクセス許可はありません。以下のものには、オプションでアクセス許可が必要になる場合があります。
+ **AWS Secrets Manager**: Secrets Manager を使用して Git リポジトリ認証情報を保存する場合
+ **AWS CodeConnections**: Git リポジトリの認証に CodeConnections を使用する場合
Secrets Manager と CodeConnections のポリシーの例:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "arn:aws:secretsmanager:region:account-id:secret:argocd/*"
},
{
"Effect": "Allow",
"Action": [
"codeconnections:UseConnection",
"codeconnections:GetConnection"
],
"Resource": "arn:aws:codeconnections:region:account-id:connection/*"
}
]
}
```
Argo CD アクセス許可要件の詳細については、「[Argo CD に関する考慮事項](argocd-considerations.md)」を参照してください。
## 既存の機能ロールを確認する
アカウントに既にユースケースに適した機能 IAM ロールがあるかどうかを確認するには、次の手順を使用できます。
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. ロールのリストを検索して、機能ロール名 (`ACKCapabilityRole` や `ArgoCDCapabilityRole` など) を確認します。
1. ロールが存在する場合は、そのロールを選択して、アタッチされたポリシーおよび信頼関係を表示します。
1. **[信頼関係]** を選択し、**[信頼ポリシーの編集]** を選択してください。
1. 信頼関係が[機能信頼ポリシー](#capability-trust-policy)と一致することを確認します。一致しない場合は、信頼ポリシーを更新します。
1. **[アクセス許可]** を選択し、ロールに機能タイプとユースケースに適したアクセス許可が付与されていることを確認します。
## 機能 IAM ロールを作成する
AWS マネジメントコンソール または AWS CLI を使用して、機能ロールを作成できます。
** AWS マネジメントコンソール **
1. https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。
1. [**ロール**] を選択してから [**ロールの作成**] を選びます。
1. **[信頼されたエンティティタイプ]** で、**[カスタム信頼ポリシー]** を選択します。
1. [機能信頼ポリシー](#capability-trust-policy)をコピーして、信頼ポリシーエディタに貼り付けます。
1. [**次へ**] を選択します。
1. **[アクセス許可を追加]** タブで、機能タイプに適したポリシーを選択または作成します (「[機能タイプ別のアクセス許可](#capability-permissions)」を参照)。kro では、このステップをスキップできます。
1. [**次へ**] を選択します。
1. **[ロール名]** に、`ACKCapabilityRole`、`ArgoCDCapabilityRole`、`kroCapabilityRole` などロールの一意の名前を入力します。
1. **[Description]** (説明） には`Amazon EKS - ACK capability role` のような説明文を入力してください。
1. [**ロールの作成**] を選択してください。
**AWS CLI**
1. [機能信頼ポリシー](#capability-trust-policy)を `capability-trust-policy.json` という名前のファイルにコピーします。
1. ロールを作成します。`ACKCapabilityRole` を目的のロール名で置き換えます。
```
aws iam create-role \
--role-name ACKCapabilityRole \
--assume-role-policy-document file://capability-trust-policy.json
```
1. 必要な IAM ポリシーをロールにアタッチします。ACK の場合、管理する AWS サービスのポリシーをアタッチします。Argo CD の場合、必要に応じて Secrets Manager または CodeConnections のポリシーをアタッチします。kro では、このステップをスキップできます。
ACK に S3 アクセス許可を付与した例:
```
aws iam put-role-policy \
--role-name ACKCapabilityRole \
--policy-name S3Management \
--policy-document file://s3-policy.json
```
## 機能ロールの問題をトラブルシューティングする
**機能の作成が「無効な IAM ロール」で失敗する**
以下を確認してください。
+ ロールがクラスターと同じアカウントに存在する
+ 信頼ポリシーが[機能信頼ポリシー](#capability-trust-policy)と一致する
+ ロールに `iam:PassRole` アクセス許可が付与されている
**機能でアクセス許可エラーが表示される**
以下を確認してください。
+ ロールに、機能タイプに必要な IAM アクセス許可が付与されている
+ ロールのアクセスエントリがクラスターに存在する
+ 必要に応じて追加の Kubernetes アクセス許可が設定される (「[その他の Kubernetes アクセス許可](capabilities-security.md#additional-kubernetes-permissions)」を参照)
**ACK リソースが「アクセス許可が拒否されました」というエラーで失敗する**
以下を確認してください。
+ ロールに、ユースケースに必要な IAM アクセス許可が付与されている
+ ACK コントローラーがシークレットを参照する場合、適切な名前空間に範囲が限定された `AmazonEKSSecretReaderPolicy` アクセスエントリポリシーを関連付けていることを確認します。
トラブルシューティングの詳しいガイダンスについては、「[EKS 機能のセキュリティに関する考慮事項](capabilities-security.md)」を参照してください。