**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# Amazon EKS でのアクセスコントロールの仕組みについて説明します。
Amazon EKS クラスターへのアクセスを管理する方法について説明します。Amazon EKS を使用するには、Kubernetes と AWS Identity and Access Management (AWS IAM) がどのようにアクセスコントロールをするのかについての知識が必要になります。
**このセクションには以下が含まれます。**
** [IAM ユーザーおよびロールに Kubernetes API へのアクセスを付与する](grant-k8s-access.md) ** — アプリケーションまたはユーザーが Kubernetes API を認証できるようにする方法について説明します。アクセスエントリ、aws-auth ConfigMap、または外部の OIDC プロバイダーを使用できます。
** [AWS マネジメントコンソール に Kubernetes リソースを表示する](view-kubernetes-resources.md) ** — Amazon EKS クラスターと通信するように AWS マネジメントコンソールを設定する方法について説明します。コンソールを使用して、名前空間、ノード、Pod など、クラスター内の Kubernetes リソースを表示します。
** [Kubernetes API への書き込みアクセスを AWS サービスに付与する](mutate-kubernetes-resources.md) ** – Kubernetes リソースの変更に必要なアクセス許可について説明します。
** [kubeconfig ファイルを作成して kubectl を EKS クラスターに接続する](create-kubeconfig.md) ** — Amazon EKS クラスターと通信するように kubectl を設定する方法について説明します。AWS CLI を使用して kubeconfig ファイルを作成します。
** [Kubernetes ワークロードに Kubernetes サービスアカウントを使用して AWS へのアクセスを許可する](service-accounts.md) ** —Kubernetes サービスアカウントを AWS IAM ロールに関連付ける方法について説明します。サービスアカウント (IRSA) には、Pod Identity または IAM ロールを使用できます。
## 一般的なタスク
+ 開発者に Kubernetes API へのアクセスを許可します。AWS マネジメントコンソールに Kubernetes リソースを表示します。
+ 解決策: [アクセスエントリを使用](access-entries.md)して、Kubernetes RBAC アクセス許可を AWS IAM ユーザーまたはロールに関連付けます。
+ AWS 認証情報を使用して、kubectl を Amazon EKS クラスターと通信するように設定します。
+ 解決策: AWS CLI を使用して [kubeconfig ファイルを作成](create-kubeconfig.md)します。
+ Ping Identity など外部 ID プロバイダーを使用して、Kubernetes API に対してユーザーを認証します。
+ 解決策: [外部の OIDC プロバイダーをリンクします](authenticate-oidc-identity-provider.md)。
+ Kubernetes クラスターのワークロードに AWS API を呼び出す機能を付与します。
+ 解決策: [Pod Identity を使用](pod-identities.md)して AWS IAM ロールを Kubernetes サービスアカウントに関連付けます。
## 背景
+ [Kubernetes サービスアカウントの仕組みを学びます。](https://kubernetes.io/docs/concepts/security/service-accounts/)
+ [Kubernetes ロールベースアクセスコントロール (RBAC) モデルを確認します。](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
+ AWS リソースへのアクセスを管理する方法については、「[AWS IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html)」を参照してください。あるいは、無料の [AWS IAM の使用に関する入門トレーニング](https://explore.skillbuilder.aws/learn/course/external/view/elearning/120/introduction-to-aws-identity-and-access-management-iam)も受講できます。
## EKS Auto Mode に関する考慮事項
EKS Auto Mode は、EKS Pod Identity および EKS EKS アクセスエントリと統合されます。
+ EKS Auto Mode は、アクセスエントリを使用して EKS コントロールプレーンに Kubernetes アクセス許可を付与します。例えば、アクセスポリシーにより、EKS Auto Mode はネットワークエンドポイントとサービスに関する情報を読み取ることができます。
+ EKS Auto Mode クラスターのアクセスエントリを無効にすることはできません。
+ 任意で `aws-auth` `ConfigMap` を有効にできます。
+ EKS Auto Mode のアクセスエントリは自動的に設定されます。このアクセスエントリは表示できますが、変更することはできません。
+ NodeClass を使用してカスタムノード IAM ロールを作成する場合は、AmazonEKSAutoNodePolicy アクセスポリシーを使用してロールのアクセスエントリを作成する必要があります。
+ AWS サービスのアクセス許可をワークロードに付与する場合は、EKS Pod Identity を使用します。
+ EKS Auto Mode クラスターに Pod Identity エージェントをインストールする必要はありません。
# IAM ユーザーおよびロールに Kubernetes API へのアクセスを付与する
クラスターには Kubernetes API エンドポイントがあります。Kubectl はこの API を使用します。この API は、次の 2 種類の ID を使用して認証することができます。
+ **AWS Identity and Access Management (IAM) プリンシパル (ロールまたはユーザー)** — このタイプには IAM への認証が必要です。[IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) ユーザーとして、または ID ソースから提供された認証情報を使用して、[フェデレーテッド ID](https://aws.amazon.com/identity/federation/) で AWS にサインインできます。IAM ロールを使用して前もって管理者により ID フェデレーションが設定されている場合、フェデレーティッド ID としてのみサインインできます。フェデレーションを使用して AWS にアクセスする場合、間接的に[ロールを引き受ける](https://docs.aws.amazon.com/IAM/latest/UserGuide/when-to-use-iam.html#security-iam-authentication-iamrole)ことになります。ユーザーがこのタイプの ID を使用すると、次のことが行われます。
+ ユーザーがクラスター上の Kubernetes オブジェクトを操作できるように Kubernetes アクセス許可を割り当てることができます。IAM プリンシパルにアクセス許可を割り当てて、クラスター上の Kubernetes オブジェクトにアクセスできるようにする方法の詳細については、「[EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する](access-entries.md)」を参照してください。
+ IAM アクセス許可を割り当てて、ユーザーが Amazon EKS API、AWS CLI、AWS CloudFormation、AWS マネジメントコンソール、または `eksctl` を使用して Amazon EKS クラスターとそのリソースを操作できるようにすることができます。詳細については、サービス認可リファレンスの「[Amazon Elastic Kubernetes Service で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)」を参照してください。
+ ノードは IAM ロールを引き受けることでクラスターに参加します。IAM プリンシパルを使用してクラスターにアクセスできます。プリンシパルは、Amazon EKS コントロールプレーンで実行される [AWS IAM Authenticator for Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme) によって提供されます。
+ **独自の OpenID Connect (OIDC) プロバイダーのユーザー** — このタイプでは、[OIDC](https://openid.net/connect/) プロバイダーへの認証が必要です。Amazon EKS クラスターで独自の OIDC プロバイダーを設定する方法については、「[外部 OIDC プロバイダーを使用して Kubernetes へのアクセスをユーザーに許可する](authenticate-oidc-identity-provider.md)」を参照してください。ユーザーがこのタイプの ID を使用すると、次のことが行われます。
+ ユーザーがクラスター上の Kubernetes オブジェクトを操作できるように Kubernetes アクセス許可を割り当てることができます。
+ IAM アクセス許可を割り当てて、ユーザーが Amazon EKS API、AWS CLI、AWS CloudFormation、AWS マネジメントコンソール、または `eksctl` を使用して Amazon EKS クラスターとそのリソースを操作できるようにすることはできません。
クラスターでは両方のタイプの ID を使用できます。IAM の認証方法を無効にすることはできません。OIDC 認証は任意です。
## IAM アイデンティティと Kubernetes のアクセス許可を関連付ける
[AWS IAM Authenticator for Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme) はクラスターのコントロールプレーンにインストールされます。これにより、クラスター上の Kubernetes リソースへのアクセスを許可する [AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) (IAM) プリンシパル (ロールとユーザー) が有効になります。次のいずれかの方法を使用して、IAM プリンシパルにクラスター上の Kubernetes オブジェクトへのアクセスを許可できます。
+ **アクセスエントリの作成** — クラスターが、クラスターの Kubernetes バージョンの「[前提条件](access-entries.md)」セクションに記載されているプラットフォームバージョンと同じかそれ以降の場合は、このオプションを使用することをお勧めします。
*アクセスエントリ*を使用して、クラスター外から IAM プリンシパルの Kubernetes アクセス許可を管理します。クラスターへのアクセスの追加および管理には、EKS API、AWS コマンドラインインターフェイス、AWS SDK、AWS CloudFormation、および AWS マネジメントコンソール を使用できます。つまり、クラスターを作成したのと同じツールでユーザーを管理できるということです。
開始するには、「[アクセスエントリを使用するように認証モードを変更する](setting-up-access-entries.md)」に従い、次に「[既存の aws-auth ConfigMap エントリをアクセスエントリに移行する](migrating-access-entries.md)」に従います。
+ **`aws-auth` `ConfigMap` へのエントリの追加** — クラスターのプラットフォームバージョンが「[前提条件](access-entries.md)」セクションに記載されているバージョンよりも前の場合は、このオプションを使用する必要があります。クラスターのプラットフォームバージョンが、クラスターの Kubernetes バージョンの「[前提条件](access-entries.md)」セクションに記載されているプラットフォームバージョンと同じかそれ以降で、`ConfigMap` にエントリを追加した場合は、それらのエントリをアクセスエントリに移行することをお勧めします。ただし、マネージド型ノードグループで使用される IAM ロールのエントリや Fargate プロファイルなど、Amazon EKS が `ConfigMap` に追加したエントリは移行できません。詳細については、「[IAM ユーザーおよびロールに Kubernetes API へのアクセスを付与する](#grant-k8s-access)」を参照してください。
+ `aws-auth` `ConfigMap` オプションを使用する必要がある場合は、`eksctl create iamidentitymapping` コマンドを使用してエントリを `ConfigMap` に追加できます。詳細については、`eksctl`ドキュメントの「[IAM ユーザーとロールの管理](https://eksctl.io/usage/iam-identity-mappings/)」を参照してください。
## クラスター認証モードを設定する
各クラスターには*認証モード*があります。認証モードによって、IAM プリンシパルがクラスター上の Kubernetes オブジェクトにアクセスできるようにするために使用できる方法が決まります。認証モードは 3 つあります。
**重要**
アクセス入力メソッドを一度有効にすると、無効にすることはできません。
`ConfigMap` メソッドがクラスターの作成時に有効になっていない場合、後で有効にすることはできません。アクセスエントリの導入前に作成されたすべてのクラスターでは、`ConfigMap` メソッドが有効になっています。
クラスターでハイブリッドノードを使用している場合は、`API`または `API_AND_CONFIG_MAP` クラスター認証モードを使用する必要があります。
**クラスター内部の `aws-auth` `ConfigMap`**
これは Amazon EKS クラスターのオリジナルの認証モードです。クラスターを作成した IAM プリンシパルは、`kubectl` を使用してクラスターにアクセスできる初期ユーザーです。初期ユーザーは、`aws-auth` `ConfigMap` のリストに他のユーザーを追加し、クラスター内の他のユーザーに影響を与えるアクセス許可を割り当てる必要があります。`ConfigMap` には管理するエントリがないため、これらの他のユーザーは初期ユーザーを管理したり削除したりできません。
**`ConfigMap` とアクセスエントリの両方**
この認証モードでは、両方の方法を使用して IAM プリンシパルをクラスターに追加できます。それぞれの方法には別々のエントリが保存されることに注意してください。例えば、AWS CLI からアクセスエントリを追加しても、`aws-auth` `ConfigMap` は更新されません。
**アクセスエントリのみ**
この認証モードでは、EKS API、AWS コマンドラインインターフェイス、AWS SDK、AWS CloudFormation、および AWS マネジメントコンソール を使用して IAM プリンシパルのクラスターへのアクセスを管理できます。
各アクセスエントリには*タイプ*があり、プリンシパルを特定の名前空間に制限する*アクセススコープ*と、事前設定された再利用可能なアクセス許可ポリシーを設定する*アクセスポリシー*を組み合わせて使用できます。また、STANDARD タイプと Kubernetes RBAC グループを使用してカスタムアクセス許可を割り当てることもできます。
| 認証モード | 方法 |
| --- | --- |
| `ConfigMap` のみ (`CONFIG_MAP`) | `aws-auth` `ConfigMap` |
| EKS API と `ConfigMap` (`API_AND_CONFIG_MAP`) | EKS API、AWS コマンドラインインターフェイス、AWS SDK、AWS CloudFormation、AWS マネジメントコンソール、および `aws-auth` `ConfigMap` のアクセスエントリ |
| EKS API のみ (`API`) | EKS API、AWS コマンドラインインターフェイス、AWS SDK、AWS CloudFormation、および AWS マネジメントコンソール のアクセスエントリ |
**注記**
Amazon EKS Auto Mode にはアクセスエントリが必要です。
# EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する
このセクションでは、アクセスエントリとポリシーを使用して、Amazon Elastic Kubernetes Service (EKS) の Kubernetes クラスターへの IAM プリンシパルアクセスを管理する方法について説明します。認証モードの変更、レガシー `aws-auth` ConfigMap エントリからの移行、アクセスエントリの作成、更新、削除、ポリシーとエントリの関連付け、事前定義されたポリシーのアクセス許可の確認、安全なアクセス管理の主な前提条件と考慮事項について詳しく説明します。
## 概要
EKS アクセスエントリはユーザーに Kubernetes API へのアクセスを許可する最善の方法です。例えば、アクセス エントリを使用して、開発者に kubectl を使用するアクセス権を付与できます。基本的に、EKS アクセスエントリは一連の Kubernetes アクセス許可を IAM ロールなどの IAM アイデンティティに関連付けます。例えば、開発者は IAM ロールを引き受け、それを使用して EKS クラスターを認証できます。
## 機能
+ **認証と認可の一元化**: Amazon EKS API を介して Kubernetes クラスターへのアクセスを直接制御するため、ユーザーアクセス許可のために AWS と Kubernetes API を切り替える必要がなくなります。
+ **詳細なアクセス権限の管理**: アクセスエントリとアクセスポリシーを使用して、クラスター作成者からのクラスター管理者権限の変更または取り消しなど、AWS IAM プリンシパルの詳細な権限を定義できます。
+ **IaC ツールの統合**: AWS CloudFormation、Terraform、AWS CDK などの Infrastructure as Code (IaC) ツールをに対応し、クラスターの作成時にアクセス構成を定義できます。
+ **設定ミスリカバリ**: Kubernetes API に直接アクセスすることなく、Amazon EKS API を介してクラスターアクセスの復元を許可します。
+ **オーバーヘッドの削減とセキュリティの強化**: CloudTrail 監査ログ記録や多要素認証などの AWS IAM 機能を活用しながら、オペレーションを一元化してオーバーヘッドを削減します。
## アクセス許可をアタッチする方法
Kubernetes アクセス許可をアタッチして、次の 2 つの方法でエントリにアクセスできます：
+ アクセス ポリシーを使用します。アクセスポリシーは、AWS によって管理される事前定義された Kubernetes アクセス許可テンプレートです。詳細については「[アクセスポリシーアクセス許可を確認する](access-policy-permissions.md)」を参照してください。
+ Kubernetes グループを参照してください。IAM アイデンティティを Kubernetes グループに関連付けると、グループのアクセス許可を付与する Kubernetes リソースを作成できます。詳細についてはKubernetes ドキュメントの「[RBAC 認可を使用する](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)」を参照してください。
## 考慮事項
既存のクラスターで EKS アクセスエントリを有効にするときは、次の点に注意してください。
+ **レガシークラスターの動作**: アクセスエントリが導入される前に作成されたクラスター ([プラットフォームバージョン要件](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html)で指定されているものよりも前の初期プラットフォームバージョンを持つもの) の場合、EKS は既存のアクセス許可を反映するアクセスエントリを自動的に作成します。このエントリには、最初にクラスターを作成した IAM ID と、クラスターの作成中にその ID に付与された管理アクセス許可が含まれます。
+ **レガシー `aws-auth` ConfigMap の処理**: クラスターがアクセス管理のためにレガシー `aws-auth` ConfigMap に依存している場合、アクセスエントリを有効にすると、元のクラスター作成者のアクセスエントリのみが自動的に作成されます。ConfigMap に追加された追加のロールまたはアクセス許可 (デベロッパーまたはサービスのカスタム IAM ロールなど) は自動的に移行されません。これに対処するには、対応するアクセスエントリを手動で作成します。
## はじめに
1. 使用する IAM アイデンティティとアクセスポリシーを決定します。
+ [アクセスポリシーアクセス許可を確認する](access-policy-permissions.md)
1. クラスターで EKS アクセスエントリを有効にします。サポートされているプラットフォームバージョンがあることを確認します。
+ [アクセスエントリを使用するように認証モードを変更する](setting-up-access-entries.md)
1. IAM アイデンティティを Kubernetes 権限に関連付けるアクセスエントリを作成します。
+ [アクセスエントリを作成する](creating-access-entries.md)
1. IAM アイデンティティを使用してクラスターを認証します。
+ [AWS CLI の設定](install-awscli.md)
+ [`kubectl` および `eksctl` のセットアップ](install-kubectl.md)
# アクセスポリシーをアクセスエントリに関連付ける
1 つ以上のアクセスポリシーを タイプ `STANDARD` のアクセスエントリに割り当てることができます。Amazon EKS は、クラスターで正しく機能するために必要なアクセス許可を他のタイプのアクセスエントリに自動的に付与します。Amazon EKS アクセスポリシーには、IAM アクセス許可ではなく Kubernetes アクセス許可が含まれます。アクセスポリシーをアクセスエントリに関連付ける前に、各アクセスポリシーに含まれる Kubernetes アクセス許可を既に理解できていることを確かめてください。詳細については、「[アクセスポリシーアクセス許可を確認する](access-policy-permissions.md)」を参照してください。どのアクセスポリシーも要件を満たさない場合は、アクセスポリシーをアクセスエントリに関連付けないでください。代わりに、アクセスエントリに 1 つ以上の*グループ名*を指定し、Kubernetes ロールベースのアクセス制御オブジェクトを作成して管理します。詳細については、「[アクセスエントリを作成する](creating-access-entries.md)」を参照してください。
+ 既存のアクセスエントリ。作成する場合は「[アクセスエントリを作成する](creating-access-entries.md)」を参照してください。
+ `ListAccessEntries`、`DescribeAccessEntry`、`UpdateAccessEntry`、`ListAccessPolicies`、`AssociateAccessPolicy`、および `DisassociateAccessPolicy` のアクセス許可を持つ AWS Identity and Access Management ロールまたはユーザー。詳細については、「*サービス認証リファレンス*」の「[Actions defined by Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)」を参照してください。
アクセスポリシーをアクセスエントリに関連付ける前に、以下の要件を考慮してください。
+ 各アクセスエントリには複数のアクセスポリシーを関連付けることができますが、各ポリシーを 1 つのアクセスエントリに関連付けることができるのは 1 回だけです。複数のアクセスポリシーを関連付ける場合、アクセスエントリの IAM プリンシパルには、関連するすべてのアクセスポリシーに含まれるすべてのアクセス許可が付与されます。
+ アクセスポリシーをクラスター上のすべてのリソースに範囲指定することも、1 つ以上の Kubernetes 名前空間の名前を指定して範囲指定することもできます。名前空間の名前にはワイルドカード文字を使用できます。例えば、`dev-` で始まるすべての名前空間にアクセスポリシーを適用する場合は、名前空間の名前として `dev-*` を指定できます。名前空間がクラスターに存在し、スペルがクラスター上の実際の名前空間の名前と一致していることを確認してください。Amazon EKS は、クラスター上の名前空間のスペルや存在を確認しません。
+ アクセスポリシーをアクセスエントリに関連付けた後、アクセスポリシーのアクセス範囲を変更できます。アクセスポリシーの範囲を Kubernetes 名前空間に設定した場合は、必要に応じて関連付けの名前空間を追加および削除できます。
+ グループ名も指定されているアクセスエントリにアクセスポリシーを関連付けると、IAM プリンシパルには、関連するすべてのアクセスポリシーのすべてのアクセス許可が付与されます。また、グループ名を指定する Kubernetes `Role` および `RoleBinding` オブジェクトで指定されている Kubernetes `Role` または `ClusterRole` オブジェクトのすべてのアクセス許可も保持されます。
+ `kubectl auth can-i --list` コマンドを実行しても、コマンドを実行したときに使用している IAM プリンシパルのアクセスエントリに関連付けられているアクセスポリシーによって割り当てられた Kubernetes アクセス許可は表示されません。このコマンドは、アクセスエントリに指定したグループ名またはユーザー名にバインドした Kubernetes `Role` または `ClusterRole` オブジェクトでアクセス許可を付与した場合にのみ、Kubernetes アクセス許可を表示します。
+ `--as username ` または `--as-group group-name ` で `kubectl` コマンドを使用するなど、クラスター上の Kubernetes オブジェクトを操作する際に Kubernetes ユーザーまたはグループになりすますと、Kubernetes RBAC 認可の使用を強制することになります。その結果、IAM プリンシパルには、アクセスエントリに関連付けられたアクセスポリシーによって割り当てられるアクセス許可はありません。IAM プリンシパルを偽装するユーザーまたはグループが持つ Kubernetes アクセス許可は、グループ名またはユーザー名にバインドした Kubernetes `Role` または `ClusterRole` オブジェクトで付与した Kubernetes アクセス許可だけです。IAM プリンシパルが関連するアクセスポリシー内のアクセス許可を持つようにするには、Kubernetes ユーザーまたはグループを偽装しないでください。IAM プリンシパルには、アクセスエントリに指定したグループ名またはユーザー名にバインドした Kubernetes `Role` または `ClusterRole` オブジェクトで付与したアクセス許可も引き続き保持されます。詳細については、Kubernetes ドキュメントの「[ユーザーの偽装](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation)」を参照してください。
AWS マネジメントコンソール または AWS CLI を使用してアクセスポリシーをアクセスエントリに関連付けることができます。
## AWS マネジメントコンソール
1. [アマゾン EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. アクセスポリシーを関連付けるアクセスエントリがあるクラスターの名前を選択します。
1. **[リモートアクセス]** タブを選択してください。
1. アクセスエントリのタイプが**標準**の場合は、Amazon EKS **アクセスポリシー**を関連付けたり関連付けを解除したりできます。アクセスエントリのタイプが**標準**以外の場合、このオプションは使用できません。
1. **[アクセスポリシーを関連付ける]** を選択します。
1. **[ポリシー名]** には、IAM プリンシパルに付与したいアクセス許可を持つポリシーを選択します。各ポリシーに含まれるアクセス許可を表示するには、「[アクセスポリシーアクセス許可を確認する](access-policy-permissions.md)」を参照してください。
1. **[アクセススコープ]** では、アクセス範囲を選択します。**[クラスター]** を選択すると、すべての Kubernetes 名前空間のリソースについて、アクセスポリシー内のアクセス許可が IAM プリンシパルに付与されます。**[Kubernetes 名前空間]** を選択した場合は、**[新しい名前空間の追加]** を選択できます。表示される **[名前空間]** フィールドには、クラスター上の Kubernetes 名前空間の名前を入力できます。IAM プリンシパルに複数の名前空間のアクセス許可を持たせたい場合は、複数の名前空間を入力できます。
1. **[アクセスポリシーを追加]** を選択します。
## AWS CLI
1. ご使用のデバイスまたは AWS CloudShell で、バージョン `2.12.3` 以降、または AWS コマンドラインインターフェイス (AWS CLI) のバージョン `1.27.160` 以降がインストールおよび設定されていること。現在のバージョンを確認するには「`aws --version | cut -d / -f2 | cut -d ' ' -f1`」を参照してください。`yum`、`apt-get`、macOS 用の Homebrew などのパッケージマネージャーは、多くの場合 AWS CLI の最新バージョンより数バージョン古くなっています。最新バージョンをインストールするには「*AWS コマンドラインインターフェイスユーザーガイド*」の「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」および「[aws configure を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。AWS クラウドシェル にインストールされている AWS CLI バージョンも最新バージョンより数バージョン遅れることがあります。更新するには、「AWS CloudShell ユーザーガイド」の「[ホームディレクトリへの AWS CLI のインストール](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)」を参照してください。
1. 利用可能なアクセスポリシーを表示します。
```
aws eks list-access-policies --output table
```
出力例は次のとおりです。
```
---------------------------------------------------------------------------------------------------------
| ListAccessPolicies |
+-------------------------------------------------------------------------------------------------------+
|| accessPolicies ||
|+---------------------------------------------------------------------+-------------------------------+|
|| arn | name ||
|+---------------------------------------------------------------------+-------------------------------+|
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSAdminPolicy | AmazonEKSAdminPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy | AmazonEKSClusterAdminPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSEditPolicy | AmazonEKSEditPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSViewPolicy | AmazonEKSViewPolicy ||
|+---------------------------------------------------------------------+-------------------------------+|
```
各ポリシーに含まれるアクセス許可を表示するには、「[アクセスポリシーアクセス許可を確認する](access-policy-permissions.md)」を参照してください。
1. 既存のアクセスエントリを表示します。*マイクラスター* の部分は自分のクラスター名に置き換えます。
```
aws eks list-access-entries --cluster-name my-cluster
```
出力例は次のとおりです。
```
{
"accessEntries": [
"arn:aws:iam::111122223333:role/my-role",
"arn:aws:iam::111122223333:user/my-user"
]
}
```
1. アクセスポリシーをアクセスエントリに関連付けます。次の例では、`AmazonEKSViewPolicy` アクセスポリシーをアクセスエントリに関連付けます。*my-role* IAM ロールがクラスター上の Kubernetes オブジェクトにアクセスしようとするたびに、Amazon EKS は、ポリシー内のアクセス許可を使用して *my-namespace1* と *my-namespace2* の Kubernetes 名前空間のみの Kubernetes オブジェクトにアクセスするアクセス許可をロールに付与します。*my-cluster* をクラスターの名前、*111122223333* を AWS アカウント ID に、*my-role* を Amazon EKS に Kubernetes クラスターオブジェクトへのアクセスを許可してほしい IAM ロールの名前に置き換えます。
```
aws eks associate-access-policy --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role \
--access-scope type=namespace,namespaces=my-namespace1,my-namespace2 --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy
```
IAM プリンシパルにクラスター全体のアクセス許可を持たせたい場合は、`type=namespace,namespaces=my-namespace1,my-namespace2 ` を `type=cluster` に置き換えてください。複数のアクセスポリシーをアクセスエントリに関連付ける場合は、それぞれに固有のアクセスポリシーを指定してコマンドを複数回実行します。関連するアクセスポリシーにはそれぞれ独自の範囲があります。
**注記**
関連するアクセスポリシーの範囲を後で変更する場合は、新しい範囲で前のコマンドをもう一度実行してください。例えば、*my-namespace2* を削除したい場合は、`type=namespace,namespaces=my-namespace1 ` のみを使用してコマンドを再実行します。範囲を `namespace` から `cluster` に変更する場合は、`type=cluster` を使用して `type=namespace,namespaces=my-namespace1,my-namespace2 ` を削除してコマンドを再実行します。
1. どのアクセスポリシーをアクセスエントリに関連付けるかを決定します。
```
aws eks list-associated-access-policies --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role
```
出力例は次のとおりです。
```
{
"clusterName": "my-cluster",
"principalArn": "arn:aws:iam::111122223333",
"associatedAccessPolicies": [
{
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
"accessScope": {
"type": "cluster",
"namespaces": []
},
"associatedAt": "2023-04-17T15:25:21.675000-04:00",
"modifiedAt": "2023-04-17T15:25:21.675000-04:00"
},
{
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy",
"accessScope": {
"type": "namespace",
"namespaces": [
"my-namespace1",
"my-namespace2"
]
},
"associatedAt": "2023-04-17T15:02:06.511000-04:00",
"modifiedAt": "2023-04-17T15:02:06.511000-04:00"
}
]
}
```
前の例では、このアクセスエントリの IAM プリンシパルには、クラスター上のすべての名前空間に対する表示アクセス許可と、2 つの Kubernetes 名前空間に対する管理者アクセス許可があります。
1. アクセスポリシーとアクセスエントリの関連付けを解除します。この例では、`AmazonEKSAdminPolicy` ポリシーとアクセスエントリの関連付けが解除されます。ただし、IAM プリンシパルは *my-namespace1* と *my-namespace2* 名前空間のオブジェクトに対する `AmazonEKSViewPolicy` アクセスポリシー内のアクセス許可を保持します。これは、そのアクセスポリシーがアクセスエントリとの関連付けを解除されていないためです。
```
aws eks disassociate-access-policy --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy
```
利用可能なアクセスポリシーを一覧表示するには、「[アクセスポリシーアクセス許可を確認する](access-policy-permissions.md)」を参照してください。
# 既存の `aws-auth ConfigMap` エントリをアクセスエントリに移行する
クラスター上の `aws-auth` `ConfigMap` にエントリを追加した場合は、`aws-auth` `ConfigMap` 内の既存のエントリのアクセスエントリを作成することをお勧めします。アクセスエントリを作成したら、そのエントリを `ConfigMap` から削除できます。`aws-auth``ConfigMap` のエントリに[アクセスポリシー](access-policies.md)を関連付けることはできません。アクセスポリシーを IAM プリンシパルに関連付けるには、アクセスエントリを作成します。
**重要**
クラスターが `API_AND_CONFIGMAP` 認証モードで、`aws-auth` `ConfigMap` およびアクセスエントリの両方に同じ IAMロールのマッピングがある場合、ロールによってアクセスエントリのマッピングが認証に使用されます。アクセスエントリは、同じ IAM プリンシパルの `ConfigMap` エントリよりも優先されます。
[マネージドノードグループ](managed-node-groups.md)または [Fargate プロファイル](fargate-profile.md)用に Amazon EKS によってお使いのクラスターに作成された既存の `aws-auth` `ConfigMap` エントリを削除する際は、事前にそれらの特定リソースの正しいアクセスエントリが Amazon EKS クラスターに存在するかどうかを再確認してください。同等のアクセスエントリがない状態で Amazon EKS が `ConfigMap` で作成したエントリを削除した場合、クラスターが正しく機能しません。
## 前提条件
+ アクセスエントリとアクセスポリシーに関する知識。詳細については、「[EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する](access-entries.md)」および「[アクセスポリシーをアクセスエントリに関連付ける](access-policies.md)」を参照してください。
+ 「[EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する](access-entries.md)」のトピックの前提条件に記載されているバージョンと同じかそれ以降のプラットフォームバージョンの既存のクラスター。
+ デバイスまたは AWS CloudShell にインストールされている `eksctl` コマンドラインツールのバージョン `0.215.0` 以降。`eksctl` をインストールまたはアップグレードするには`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。
+ `kube-system` 名前空間内の `aws-auth` `ConfigMap` を変更する Kubernetes アクセス許可。
+ `CreateAccessEntry` および `ListAccessEntries` のアクセス許可を持つ AWS Identity and Access Management ロールまたはユーザー。詳細については、サービス認可リファレンスの「[Amazon Elastic Kubernetes Service で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)」を参照してください。
## `eksctl`
1. `aws-auth ConfigMap` 内の既存のエントリを表示します。*マイクラスター* の部分は自分のクラスター名に置き換えます。
```
eksctl get iamidentitymapping --cluster my-cluster
```
出力例は次のとおりです。
```
ARN USERNAME GROUPS ACCOUNT
arn:aws:iam::111122223333:role/EKS-my-cluster-Admins Admins system:masters
arn:aws:iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers my-namespace-Viewers Viewers
arn:aws:iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
arn:aws:iam::111122223333:user/my-user my-user
arn:aws:iam::111122223333:role/EKS-my-cluster-fargateprofile1 system:node:{{SessionName}} system:bootstrappers,system:nodes,system:node-proxier
arn:aws:iam::111122223333:role/EKS-my-cluster-managed-ng system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
```
1. 前の出力で返された作成済み `ConfigMap` エントリのいずれかへの [アクセスエントリを作成する](creating-access-entries.md)。アクセスエントリを作成するときは、出力で返される`ARN`、`USERNAME`、`GROUPS` および `ACCOUNT` と同じ値を指定してください。出力例では、最後の 2 つのエントリを除くすべてのエントリのアクセスエントリを作成します。これらのエントリは Fargate プロファイルとマネージド型ノードグループ用に Amazon EKS によって作成されたものだからです。
1. 作成したすべてのアクセスエントリのエントリを `ConfigMap` から削除します。`ConfigMap` からエントリを削除しない場合、IAM プリンシパル ARN のアクセスエントリの設定によって `ConfigMap` エントリが上書きされます。*111122223333* は AWS アカウント ID に、*EKS-my-cluster-my-namespace-Viewers* は、`ConfigMap` のエントリに含まれるロールの名前に置き換えます。削除するエントリが IAM ロールではなく IAM ユーザー用のものである場合は、`role` を `user` に、*EKS-my-cluster-my-namespace-Viewers* をユーザー名に置き換えます。
```
eksctl delete iamidentitymapping --arn arn:aws:iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers --cluster my-cluster
```
# アクセスポリシーアクセス許可を確認する
アクセスポリシーには、Kubernetes `verbs` (アクセス許可) と `resources` を含む `rules` が含まれます。アクセスポリシーには IAM のアクセス許可やリソースは含まれません。Kubernetes `Role` および `ClusterRole` オブジェクトと同様に、アクセスポリシーには `allow` `rules` のみが含まれます。アクセスポリシーの内容は変更できません。独自のアクセスポリシーを作成することはできません。アクセスポリシーのアクセス許可がニーズに合わない場合は、Kubernetes RBAC オブジェクトを作成し、アクセスエントリの*グループ名*を指定します。詳細については、「[アクセスエントリを作成する](creating-access-entries.md)」を参照してください。アクセスポリシーに含まれるアクセス許可は、Kubernetes ユーザー向けのクラスターロールのアクセス許可と似ています。詳細については、Kubernetes ドキュメントの「[ユーザー向け Role](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)」を参照してください。
## すべてのポリシーをリストする
このページに記載されているいずれかのアクセスポリシーを使用するか、AWS CLI を使用して使用可能なすべてのアクセスポリシーのリストを取得します。
```
aws eks list-access-policies
```
予想される出力は次のようになります (簡潔にするために省略しています)。
```
{
"accessPolicies": [
{
"name": "AmazonAIOpsAssistantPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonAIOpsAssistantPolicy"
},
{
"name": "AmazonARCRegionSwitchScalingPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonARCRegionSwitchScalingPolicy"
},
{
"name": "AmazonEKSAdminPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy"
},
{
"name": "AmazonEKSAdminViewPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy"
},
{
"name": "AmazonEKSAutoNodePolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy"
}
// Additional policies omitted
]
}
```
## AmazonEKSAdminPolicy
このアクセスポリシーには、リソースに対するほとんどのアクセス許可を IAM プリンシパルに付与するアクセス許可が含まれています。アクセスエントリに関連付けられている場合、そのアクセス範囲は通常 1 つ以上の Kubernetes 名前空間です。IAM プリンシパルにクラスター上のすべてのリソースへの管理者アクセスを許可する場合は、代わりに [AmazonEKSClusterAdminPolicy](#access-policy-permissions-amazoneksclusteradminpolicy) アクセスポリシーをアクセスエントリに関連付けてください。
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy`
| Kubernetes API グループ | Kubernetes resources | Kubernetes 動詞（許可） |
| --- | --- | --- |
| `apps` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `replicasets`, `replicasets/scale`, `statefulsets`, `statefulsets/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `authorization.k8s.io` | `localsubjectaccessreviews` | `create` |
| `autoscaling` | `horizontalpodautoscalers` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `batch` | `cronjobs`, `jobs` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `ingresses`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicationcontrollers/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `networkpolicies` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| `rbac.authorization.k8s.io` | `rolebindings`, `roles` | `create`, `delete`, `deletecollection`, `get`, `list`, `patch`, `update`, `watch` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`,`list`, `watch` |
| | `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy`, `secrets`, `services/proxy` | `get`, `list`, `watch` |
| | `configmaps`, `events`, `persistentvolumeclaims`, `replicationcontrollers`, `replicationcontrollers/scale`, `secrets`, `serviceaccounts`, `services`, `services/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `pods`, `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `serviceaccounts` | `impersonate` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, `resourcequotas/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`,`list`, `watch` |
## AmazonEKSClusterAdminPolicy
このアクセスポリシーには、IAM プリンシパル管理者にクラスターへのアクセス権を付与するアクセス許可が含まれています。アクセスエントリに関連付けられている場合、そのアクセス範囲は通常、Kubernetes 名前空間ではなくクラスターになります。IAM プリンシパルの管理範囲をより限定したい場合は、代わりに [AmazonEKSAdminPolicy](#access-policy-permissions-amazoneksadminpolicy) アクセスポリシーをアクセスエントリに関連付けることを検討してください。
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy`
| Kubernetes API グループ | Kubernetes nonResourceURL | Kubernetes resources | Kubernetes 動詞（許可） |
| --- | --- | --- | --- |
| `*` | | `*` | `*` |
| | `*` | | `*` |
## AmazonEKSAdminViewPolicy
このアクセスポリシーには、IAM プリンシパルにクラスターの全リソースをリスト/表示するアクセス権を付与するアクセス許可が含まれています。これには [Kubernetes シークレット](https://kubernetes.io/docs/concepts/configuration/secret/)が含まれることに注意してください。
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy`
| Kubernetes API グループ | Kubernetes resources | Kubernetes 動詞（許可） |
| --- | --- | --- |
| `*` | `*` | `get`, `list`, `watch` |
## AmazonEKSEditPolicy
このアクセスポリシーには、IAM プリンシパルがほとんどの Kubernetes リソースを編集できるようにするアクセス許可が含まれています。
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy`
| Kubernetes API グループ | Kubernetes resources | Kubernetes 動詞（許可） |
| --- | --- | --- |
| `apps` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `replicasets`, `replicasets/scale`, `statefulsets`, `statefulsets/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `jobs` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `ingresses`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicationcontrollers/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `networkpolicies` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `policy` | `poddisruptionbudgets` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`, `list`, `watch` |
| | `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy`, `secrets`, `services/proxy` | `get`, `list`, `watch` |
| | `serviceaccounts` | `impersonate` |
| | `pods`, `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `configmaps`, `events`, `persistentvolumeclaims`, `replicationcontrollers`, `replicationcontrollers/scale`, `secrets`, `serviceaccounts`, `services`, `services/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`, `list`, `watch` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, `resourcequotas/status` | `get`, `list`, `watch` |
## AmazonEKSViewPolicy
このアクセスポリシーには、IAM プリンシパルがほとんどの Kubernetes リソースを表示できるようにするアクセス許可が含まれています。
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy`
| Kubernetes API グループ | Kubernetes resources | Kubernetes 動詞（許可） |
| --- | --- | --- |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`, `list`, `watch` |
| | `bindings`、`events`、`limitranges`、`namespaces/status`、`pods/log`、`pods/status`、`replicationcontrollers/status`、`resourcequotas`、r`esourcequotas/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`, `list`, `watch` |
## AmazonEKSSecretReaderPolicy
このアクセスポリシーに含まれているアクセス許可により、IAM プリンシパルは [Kubernetes シークレット](https://kubernetes.io/docs/concepts/configuration/secret/)を読み取ることができます。
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicy`
| Kubernetes API グループ | Kubernetes resources | Kubernetes 動詞 (許可) |
| --- | --- | --- |
| | `secrets` | `get`, `list`, `watch` |
## AmazonEKSAutoNodePolicy
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy`
このポリシーには、Amazon EKS コンポーネントが以下のタスクを完了できるようにする次のアクセス許可が含まれています。
+ `kube-proxy` – ネットワークエンドポイントおよびサービスをモニタリングし、関連するイベントを管理します。これにより、クラスター全体のネットワークプロキシ機能が有効になります。
+ `ipamd` – AWS VPC ネットワーキングリソースと Container Network Interface (CNI) を管理します。これにより、IP アドレス管理デーモンがポッドネットワーキングを処理できるようになります。
+ `coredns` – エンドポイントやサービスなどのサービス検出リソースにアクセスします。これにより、クラスター内の DNS 解決が有効になります。
+ `ebs-csi-driver` – Amazon EBS ボリュームのストレージ関連リソースを操作します。これにより、永続ボリュームの動的なプロビジョニングとアタッチが可能になります。
+ `neuron` – AWS Neuron デバイスのノードとポッドをモニタリングします。これにより、AWS Inferentia および Trainium アクセラレーターを管理できます。
+ `node-monitoring-agent` – ノード診断およびイベントにアクセスします。これにより、クラスターのヘルスモニタリングと診断の収集が可能になります。
各コンポーネントは専用のサービスアカウントを使用し、その特定の機能に必要なアクセス許可のみに制限されます。
NodeClass でノード IAM ロールを手動で指定する場合には、新しいノード IAM ロールをこのアクセスポリシーに関連付けるアクセスエントリを作成する必要があります。
## Amazon EKSブロックストレージポリシー
**注記**
このポリシーは AWS サービスリンクロール専用で、カスタマーマネージドロールには使用できません。
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSBlockStoragePolicy`
このポリシーには、Amazon EKS がストレージオペレーションのリーダー選出および調整リソースを管理できるようにするアクセス許可が含まれています。
+ `coordination.k8s.io` – リーダー選出用のリースオブジェクトを作成および管理します。これにより、EKS ストレージコンポーネントは、リーダー選出メカニズムを通じてクラスター全体のアクティビティを調整できます。
ポリシーは、クラスター内の他の調整リソースへのアクセス競合を防ぐために、EKS ストレージコンポーネントで使用される特定のリースリソースを対象とします。
Amazon EKS は、Auto Mode が有効の場合、クラスター IAM ロールのこのアクセスポリシーを使用してアクセスエントリを自動的に作成し、ブロックストレージ機能が正しく機能するのに必要なアクセス許可を設定します。
## AmazonEKSLoadBalancingPolicy
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSLoadBalancingPolicy`
このポリシーには、Amazon EKS がロードバランシングのリーダー選出リソースを管理できるようにするアクセス許可が含まれています。
+ `coordination.k8s.io` – リーダー選出用のリースオブジェクトを作成および管理します。これにより、EKS ロードバランシングコンポーネントはリーダーを選出することで、複数のレプリカ間でアクティビティを調整できます。
このポリシーは、クラスター内の他のリースリソースへのアクセスを防止しながら、適切な調整を実現するために、特にロードバランシングリースリソースを対象とします。
Amazon EKS は、Auto Mode が有効の場合、クラスター IAM ロールのこのアクセスポリシーを使用してアクセスエントリを自動的に作成し、ネットワーク機能が正しく機能するのに必要なアクセス許可を設定します。
## AmazonEKSNetworkingPolicy
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSNetworkingPolicy`
このポリシーには、Amazon EKS がネットワーキングのリーダー選出リソースを管理できるようにするアクセス許可が含まれています。
+ `coordination.k8s.io` – リーダー選出用のリースオブジェクトを作成および管理します。これにより、EKS ネットワークコンポーネントはリーダーを選出することで、IP アドレス割り当てアクティビティを調整できます。
このポリシーは、クラスター内の他のリースリソースへのアクセスを防止しながら、適切な調整を実現するために、特にネットワークリースリソースを対象とします。
Amazon EKS は、Auto Mode が有効の場合、クラスター IAM ロールのこのアクセスポリシーを使用してアクセスエントリを自動的に作成し、ネットワーク機能が正しく機能するのに必要なアクセス許可を設定します。
## AmazonEKSComputePolicy
**注記**
このポリシーは AWS サービスリンクロール専用で、カスタマーマネージドロールには使用できません。
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSComputePolicy`
このポリシーには、Amazon EKS がコンピューティングオペレーションのリーダー選出リソースを管理できるようにするアクセス許可が含まれています。
+ `coordination.k8s.io` – リーダー選出用のリースオブジェクトを作成および管理します。これにより、EKS コンピューティングコンポーネントは、リーダーを選出することでノードスケーリングアクティビティを調整できます。
このポリシーは、クラスター内のすべてのリースリソースへの基本的な読み取りアクセス (`get`、`watch`) を許可しながら、特にコンピューティング管理リースリソースを対象とします。
Amazon EKS は、Auto Mode が有効の場合、クラスター IAM ロールのこのアクセスポリシーを使用してアクセスエントリを自動的に作成し、ネットワーク機能が正しく機能するのに必要なアクセス許可を設定します。
## AmazonEKSBlockStorageClusterPolicy
**注記**
このポリシーは AWS サービスリンクロール専用で、カスタマーマネージドロールには使用できません。
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSBlockStorageClusterPolicy`
このポリシーは、Amazon EKS Auto Mode のブロックストレージ機能に必要なアクセス許可を付与します。これにより、Amazon EKS クラスター内のブロックストレージリソースを効率的に管理できます。 ポリシーには以下のアクセス許可が含まれています。
CSI ドライバー管理:
+ CSI ドライバー (特にブロックストレージ用) の作成、読み取り、更新、削除を行います。
ボリューム管理:
+ 永続ボリュームの一覧表示、監視、作成、更新、パッチ適用、削除を行います。
+ 永続ボリュームのクレームを一覧表示、監視、更新します。
+ パッチ永続ボリュームのクレームのステータス。
ノードとポッドのインタラクション:
+ ノードおよびポッドの情報を読み取ります。
+ ストレージオペレーションに関連するイベントを管理します。
ストレージクラスおよび属性:
+ ストレージクラスと CSI ノードを読み取ります。
+ ボリューム属性クラスを読み取ります。
ボリュームのアタッチ:
+ ボリュームのアタッチとそのステータスを一覧表示、監視、変更します。
スナップショットオペレーション:
+ ボリュームのスナップショット、スナップショットコンテンツ、スナップショットクラスを管理します。
+ ボリュームグループスナップショットおよび関連リソースのオペレーションを処理します。
このポリシーは、Auto Mode で実行されている Amazon EKS クラスター内の包括的なブロックストレージ管理をサポートするように設計されています。ブロックストレージボリュームのプロビジョニング、アタッチ、サイズ変更、スナップショット作成など、さまざまなオペレーションに対するアクセス許可を組み合わせます。
Amazon EKS は、Auto Mode が有効の場合、クラスター IAM ロールのこのアクセスポリシーを使用してアクセスエントリを自動的に作成し、ブロックストレージ機能が正しく機能するのに必要なアクセス許可を設定します。
## AmazonEKSComputeClusterPolicy
**注記**
このポリシーは AWS サービスリンクロール専用で、カスタマーマネージドロールには使用できません。
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSComputeClusterPolicy`
このポリシーは、Amazon EKS Auto Mode のコンピューティング管理機能に必要なアクセス許可を付与します。これにより、Amazon EKS クラスター内のコンピューティングリソースを効率的にオーケストレーションおよびスケールできます。 ポリシーには以下のアクセス許可が含まれています。
ノード管理:
+ NodePools および NodeClaims のステータスの作成、読み取り、更新、削除、管理を行います。
+ 作成、変更、削除を含め、NodeClasses を管理します。
スケジューリングとリソース管理:
+ ポッド、ノード、永続ボリューム、永続ボリュームのクレーム、レプリケーションコントローラー、名前空間への読み取りアクセス。
+ ストレージクラス、CSI ノード、ボリュームのアタッチへの読み取りアクセス。
+ デプロイ、デーモンセット、レプリカセット、ステートフルセットを一覧表示および監視します。
+ ポッド中断の予算を読み取ります。
イベント処理:
+ クラスターイベントの作成、読み取り、管理を行います。
ノードのプロビジョニング解除とポッドエビクション:
+ ノードの更新、パッチ適用、削除を行います。
+ 必要に応じて、ポッドエビクションを作成してポッドを削除します。
カスタムリソース定義 (CRD) 管理:
+ 新しい CRD を作成します。
+ ノード管理に関連する特定の CRD (NodeClasses、NodePools、NodeClaims、NodeDiagnostics) を管理します。
このポリシーは、Auto Mode で実行されている Amazon EKS クラスター内の包括的なコンピューティング管理をサポートするように設計されています。ノードのプロビジョニング、スケジューリング、スケーリング、リソースの最適化など、さまざまなオペレーションのアクセス許可を組み合わせます。
Amazon EKS は、Auto Mode が有効の場合、クラスター IAM ロールのこのアクセスポリシーを使用してアクセスエントリを自動的に作成し、コンピューティング管理機能が正しく機能するのに必要なアクセス許可を設定します。
## AmazonEKSLoadBalancingClusterPolicy
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSLoadBalancingClusterPolicy`
このポリシーは、Amazon EKS Auto Mode のロードバランシング機能に必要なアクセス許可を付与します。これにより、Amazon EKS クラスター内のロードバランシングリソースを効率的に管理および設定できます。 ポリシーには以下のアクセス許可が含まれています。
イベントとリソースの管理:
+ イベントを作成してパッチを適用します。
+ ポッド、ノード、エンドポイント、名前空間への読み取りアクセス。
+ ポッドのステータスを更新します。
サービスおよびイングレス管理:
+ サービスとそのステータスの完全な管理。
+ イングレスとそのステータスの包括的な制御。
+ エンドポイントスライスとイングレスクラスへの読み取りアクセス。
ターゲットグループのバインディング:
+ ターゲットグループのバインディングとそのステータスを作成および変更します。
+ イングレスクラスパラメータへの読み取りアクセス。
カスタムリソース定義 (CRD) 管理:
+ すべての CRD の作成および読み取りを行います。
+ targetgroupbindings.eks.amazonaws.com および ingressclassparams.eks.amazonaws.com CRD の特定の管理。
ウェブフック設定:
+ 変異および検証ウェブフック設定の作成および読み取りを行います。
+ eks-load-balancing-webhook 設定を管理します。
このポリシーは、Auto Mode で実行されている Amazon EKS クラスター内の包括的なロードバランシング管理をサポートするように設計されています。サービスの公開、イングレスルーティング、AWS ロードバランシングサービスとの統合など、さまざまなオペレーションのアクセス許可を組み合わせます。
Amazon EKS は、Auto Mode が有効の場合、クラスター IAM ロールのこのアクセスポリシーを使用してアクセスエントリを自動的に作成し、ロードバランシング機能が正しく機能するのに必要なアクセス許可を設定します。
## AmazonEKSNetworkingClusterPolicy
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSNetworkingClusterPolicy`
AmazonEKSNetworkingClusterPolicy
このポリシーは、Amazon EKS Auto Mode のネットワーキング機能に必要なアクセス許可を付与します。これにより、Amazon EKS クラスター内のネットワーキングリソースを効率的に管理および設定できます。 ポリシーには以下のアクセス許可が含まれています。
ノードとポッドの管理:
+ NodeClasses とそのステータスへの読み取りアクセス。
+ NodeClaims とそのステータスへの読み取りアクセス。
+ ポッドへの読み取りアクセス。
CNI ノード管理:
+ 作成、読み取り、更新、削除、パッチ適用などの、CNINodes とそのステータスのアクセス許可。
カスタムリソース定義 (CRD) 管理:
+ すべての CRD の作成および読み取りを行います。
+ cninodes.eks.amazonaws.com CRD の特定の管理 (更新、パッチ適用、削除)。
イベント管理:
+ イベントを作成してパッチを適用します。
このポリシーは、Auto Mode で実行されている Amazon EKS クラスター内の包括的なネットワーク管理をサポートするように設計されています。ノードネットワーキング設定、CNI (Container Network Interface) 管理、関連するカスタムリソース処理など、さまざまなオペレーションのアクセス許可を組み合わせます。
このポリシーにより、ネットワーキングコンポーネントはノード関連のリソースを操作し、CNI 固有のノード設定を管理し、クラスター内のネットワーキングオペレーションに不可欠なカスタムリソースを処理できます。
Amazon EKS は、Auto Mode が有効の場合、クラスター IAM ロールのこのアクセスポリシーを使用してアクセスエントリを自動的に作成し、ネットワーク機能が正しく機能するのに必要なアクセス許可を設定します。
## AmazonEKSHybridPolicy
**注記**
このポリシーは AWS サービスリンクロール専用で、カスタマーマネージドロールには使用できません。
このアクセスポリシーには、クラスターのノードへの EKS アクセスを許可するアクセス許可が含まれています。アクセスエントリに関連付けられている場合、そのアクセス範囲は通常、Kubernetes 名前空間ではなくクラスターになります。このポリシーは、Amazon EKS Hybrid Nodes で使用されます。
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSHybridPolicy`
| Kubernetes API グループ | Kubernetes nonResourceURL | Kubernetes resources | Kubernetes 動詞 (許可) |
| --- | --- | --- | --- |
| `*` | | `nodes` | `list` |
## AmazonEKSClusterInsightsPolicy
**注記**
このポリシーは AWS サービスリンクロール専用で、カスタマーマネージドロールには使用できません。
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterInsightsPolicy`
このポリシーは、Amazon EKS クラスターインサイト機能の読み取り専用アクセス許可を付与します。 ポリシーには以下のアクセス許可が含まれています。
ノードアクセス: - クラスターノードの一覧表示および表示 - ノードのステータス情報の読み取り
DaemonSet アクセス: - kube-proxy 設定に対する読み取りアクセス
このポリシーは、クラスターインサイトの EKS サービスによって自動的に管理されます。詳細については、「[Kubernetes バージョンアップグレードの準備およびクラスターインサイトでの設定ミスのトラブルシューティング](cluster-insights.md)」を参照してください。
## AWSBackupFullAccessPolicyForBackup
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AWSBackupFullAccessPolicyForBackup`
AWSBackupFullAccessPolicyForBackup
このポリシーは、AWS バックアップが EKS クラスターのバックアップを管理および作成するために必要なアクセス許可を付与します。このポリシーには、以下のアクセス許可が含まれています。
| Kubernetes API グループ | Kubernetes resources | Kubernetes 動詞 (許可) |
| --- | --- | --- |
| `*` | `*` | `list`, `get` |
## AWSBackupFullAccessPolicyForRestore
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AWSBackupFullAccessPolicyForRestore`
AWSBackupFullAccessPolicyForRestore
このポリシーは、AWS バックアップが EKS クラスターのバックアップを管理および復元するために必要なアクセス許可を付与します。このポリシーには、以下のアクセス許可が含まれています。
| Kubernetes API グループ | Kubernetes resources | Kubernetes 動詞 (許可) |
| --- | --- | --- |
| `*` | `*` | `list`, `get`, `create` |
## AmazonEKSACKPolicy
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSACKPolicy`
このポリシーは、Kubernetes 用 AWS コントローラー (ACK) 機能が Kubernetes から AWS リソースを管理するために必要なアクセス許可を付与します。 ポリシーには以下のアクセス許可が含まれています。
ACK カスタムリソース管理:
+ S3、RDS、DynamoDB、Lambda、EC2 など、50 を超える AWS サービス全体ですべての ACK サービスカスタムリソースにフルアクセスします。
+ ACK カスタムリソース定義を作成、読み取り、更新、および削除します。
名前空間アクセス:
+ リソースを編成するために名前空間に読み取りアクセスします。
リーダー選出:
+ リーダーを選出するために調整リースを作成および読み取ります。
+ 特定の ACK サービスコントローラーリースを更新および削除します。
イベント管理:
+ ACK のオペレーション用にイベントを作成してパッチを適用します。
このポリシーは、Kubernetes API を介した包括的な AWS リソース管理をサポートするように設計されています。ACK 機能の作成時に機能 IAM ロールを指定した場合、Amazon EKS により、このアクセスポリシーに従ってそのロールへのアクセスエントリが自動的に作成されます。
| Kubernetes API グループ | Kubernetes resources | Kubernetes 動詞 (許可) |
| --- | --- | --- |
| | `namespaces` | `get`, `watch`, `list` |
| `services.k8s.aws`, `acm.services.k8s.aws`, `acmpca.services.k8s.aws`, `apigateway.services.k8s.aws`, `apigatewayv2.services.k8s.aws`, `applicationautoscaling.services.k8s.aws`, `athena.services.k8s.aws`, `bedrock.services.k8s.aws`, `bedrockagent.services.k8s.aws`, `bedrockagentcorecontrol.services.k8s.aws`, `cloudfront.services.k8s.aws`, `cloudtrail.services.k8s.aws`, `cloudwatch.services.k8s.aws`, `cloudwatchlogs.services.k8s.aws`, `codeartifact.services.k8s.aws`, `cognitoidentityprovider.services.k8s.aws`, `documentdb.services.k8s.aws`, `dynamodb.services.k8s.aws`, `ec2.services.k8s.aws`, `ecr.services.k8s.aws`, `ecrpublic.services.k8s.aws`, `ecs.services.k8s.aws`, `efs.services.k8s.aws`, `eks.services.k8s.aws`, `elasticache.services.k8s.aws`, `elbv2.services.k8s.aws`, `emrcontainers.services.k8s.aws`, `eventbridge.services.k8s.aws`, `iam.services.k8s.aws`, `kafka.services.k8s.aws`, `keyspaces.services.k8s.aws`, `kinesis.services.k8s.aws`, `kms.services.k8s.aws`, `lambda.services.k8s.aws`, `memorydb.services.k8s.aws`, `mq.services.k8s.aws`, `networkfirewall.services.k8s.aws`, `opensearchservice.services.k8s.aws`, `organizations.services.k8s.aws`, `pipes.services.k8s.aws`, `prometheusservice.services.k8s.aws`, `ram.services.k8s.aws`, `rds.services.k8s.aws`, `recyclebin.services.k8s.aws`, `route53.services.k8s.aws`, `route53resolver.services.k8s.aws`, `s3.services.k8s.aws`, `s3control.services.k8s.aws`, `sagemaker.services.k8s.aws`, `secretsmanager.services.k8s.aws`, `ses.services.k8s.aws`, `sfn.services.k8s.aws`, `sns.services.k8s.aws`, `sqs.services.k8s.aws`, `ssm.services.k8s.aws`, `wafv2.services.k8s.aws` | `*` | `*` |
| `coordination.k8s.io` | `leases` | `create`, `get`, `list`, `watch` |
| `coordination.k8s.io` | `leases` (特定の ACK サービスコントローラーリース専用) | `delete`, `update`, `patch` |
| | `events` | `create`, `patch` |
| `apiextensions.k8s.io` | `customresourcedefinitions` | `*` |
## AmazonEKSArgoCDClusterPolicy
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy`
このポリシーは、Argo CD 機能がリソースを検出し、クラスター範囲のオブジェクトを管理するために必要なクラスターレベルのアクセス許可を付与します。 ポリシーには以下のアクセス許可が含まれています。
名前空間の管理:
+ アプリケーションの名前空間を管理するための名前空間を作成、読み取り、更新、および削除します。
カスタムリソース定義の管理:
+ Argo CD 固有の CRD (Application、AppProject、ApplicationSet) を管理します。
API 検出:
+ リソースを検出するために Kubernetes API エンドポイントに読み取りアクセスします。
このポリシーは、名前空間の管理や CRD のインストールなど、クラスターレベルの Argo CD オペレーションをサポートするように設計されています。Argo CD 機能の作成時に機能 IAM ロールを指定した場合、Amazon EKS により、このアクセスポリシーに従ってそのロールへのアクセスエントリが自動的に作成されます。
| Kubernetes API グループ | Kubernetes nonResourceURL | Kubernetes resources | Kubernetes 動詞 (許可) |
| --- | --- | --- | --- |
| | | `namespaces` | `create`, `get`, `update`, `patch`, `delete` |
| `apiextensions.k8s.io` | | `customresourcedefinitions` | `create` |
| `apiextensions.k8s.io` | | `customresourcedefinitions` (Argo CD CRD のみ) | `get`, `update`, `patch`, `delete` |
| | `/api`, `/api/*`, `/apis`, `/apis/*` | | `get` |
## AmazonEKSArgoCDPolicy
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy`
このポリシーは、Argo CD 機能がアプリケーションをデプロイおよび管理するために必要な名前空間レベルのアクセス許可を付与します。 ポリシーには以下のアクセス許可が含まれています。
シークレットの管理:
+ Git 認証情報用のシークレットとクラスターシークレットにフルアクセスします。
ConfigMap アクセス:
+ ConfigMaps に読み取りアクセスして、サポート対象外の Argo CD ConfigMaps を使用しようとしたら警告を送信します。
イベント管理:
+ アプリケーションライフサイクルを追跡するためのイベントを読み取りおよび作成します。
Argo CD リソース管理:
+ Application、ApplicationSet、AppProject にフルアクセスします。
+ Argo CD リソースのファイナライザーおよびステータスを管理します。
このポリシーは、アプリケーションのデプロイや管理など、名前空間レベルの Argo CD オペレーションをサポートするように設計されています。Argo CD 機能の作成時に機能 IAM ロールを指定した場合、Amazon EKS により、このアクセスポリシーに従ってそのロールへのアクセスエントリが自動的に作成され、その範囲が Argo CD 名前空間に限定されます。
| Kubernetes API グループ | Kubernetes resources | Kubernetes 動詞 (許可) |
| --- | --- | --- |
| | `secrets` | `*` |
| | `configmaps` | `get`, `list`, `watch` |
| | `events` | `get`, `list`, `watch`, `patch`, `create` |
| `argoproj.io` | `applications`, `applications/finalizers`, `applications/status`, `applicationsets`, `applicationsets/finalizers`, `applicationsets/status`, `appprojects`, `appprojects/finalizers`, `appprojects/status` | `*` |
## AmazonEKSKROPolicy
**ARN** — ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSKROPolicy`
このポリシーは、kro (Kube Resource Orchestrator) 機能がカスタム Kubernetes API を作成および管理するために必要なアクセス許可を付与します。 ポリシーには以下のアクセス許可が含まれています。
kro リソース管理:
+ ResourceGraphDefinitions やカスタムリソースインスタンスを含めすべての kro リソースにフルアクセスします。
カスタムリソース定義の管理:
+ ResourceGraphDefinitions に定義されたカスタム API の CRD を作成、読み取り、更新、および削除します。
リーダー選出:
+ リーダーを選出するために調整リースを作成および読み取ります。
+ kro コントローラーリースを更新および削除します。
イベント管理:
+ kro のオペレーション用にイベントを作成してパッチを適用します。
このポリシーは、kro を介した包括的なリソース構成とカスタム API 管理をサポートするように設計されています。kro 機能の作成時に機能 IAM ロールを指定した場合、Amazon EKS により、このアクセスポリシーに従ってそのロールへのアクセスエントリが自動的に作成されます。
| Kubernetes API グループ | Kubernetes resources | Kubernetes 動詞 (許可) |
| --- | --- | --- |
| `kro.run` | `*` | `*` |
| `apiextensions.k8s.io` | `customresourcedefinitions` | `*` |
| `coordination.k8s.io` | `leases` | `create`, `get`, `list`, `watch` |
| `coordination.k8s.io` | `leases` (kro コントローラーリースのみ) | `delete`, `update`, `patch` |
| | `events` | `create`, `patch` |
## アクセスポリシーの更新
アクセスポリシーが導入されてからのアクセスポリシーへの更新に関する詳細を表示します。このページの変更に関する自動通知については、[ドキュメント履歴](doc-history.md) の RSS フィードを購読してください。
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| EKS 機能用のポリシーを追加する | EKS 機能を管理できるように `AmazonEKSACKPolicy`、`AmazonEKSArgoCDClusterPolicy`、`AmazonEKSArgoCDPolicy`、`AmazonEKSKROPolicy` を発行します。 | 2025 年 11 月 22 日 |
| `AmazonEKSSecretReaderPolicy` を追加します。 | 読み取り専用アクセス用の新しいポリシーをシークレットに追加する | 2025 年 11 月 6 日 |
| EKS クラスターインサイトのポリシーを追加する | `AmazonEKSClusterInsightsPolicy` を発行 | 2024 年 12 月 2 日 |
| Amazon EKS Hybrid のポリシーを追加 | `AmazonEKSHybridPolicy` を発行 | 2024 年 12 月 2 日 |
| Amazon EKS Auto Mode のポリシーを追加 | このアクセスポリシーは、クラスター IAM ロールとノード IAM ロールに Kubernetes API を呼び出すアクセス許可を付与します。AWS ではこれらを使用して、ストレージ、コンピューティング、およびネットワーキングリソースのルーチンタスクを自動化します。 | 2024 年 12 月 2 日 |
| `AmazonEKSAdminViewPolicy` を追加します。 | Secrets などのリソースを含む、拡張ビューアクセス用の新しいポリシーを追加します。 | 2024 年 4 月 23 日 |
| アクセスポリシーが導入されました。 | Amazon EKS はアクセスポリシーを導入しました。 | 2023 年 5 月 29 日 |
# アクセスエントリを使用するように認証モードを変更する
アクセスエントリを使い始めるにはクラスターの認証モードを `API_AND_CONFIG_MAP` または `API` モードに変更する必要があります。これにより、アクセスエントリ用の API が追加されます。
## AWS コンソール
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. アクセスエントリを作成するクラスターの名前を選択してください。
1. **[リモートアクセス]** タブを選択してください。
1. **[認証モード]** にはクラスターの現在の認証モードが表示されます。モードが EKS API と表示されている場合は既にアクセスエントリを追加でき、残りの手順は省略できます。
1. **[アクセスの管理]** を選択してください。
1. **クラスター認証モード**の場合は、EKS API でモードを選択してください。認証モードを、EKS API およびアクセスエントリを削除するモードに戻すことはできないことに注意してください。
1. **[Save changes]** (変更の保存) をクリックします。Amazon EKS がクラスターの更新を開始し、クラスターのステータスが「更新中」に変わり、変更が **[更新履歴]** タブに記録されます。
1. クラスターのステータスが [アクティブ] に戻るまで待ちます。クラスターが [アクティブ] になったら、「[アクセスエントリを作成する](creating-access-entries.md)」の手順に従って IAM プリンシパルのクラスターへのアクセスを追加できます。
## AWS CLI
1. 「*AWS コマンドラインインターフェイスユーザーガイド*」の「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」の説明に従って、AWS CLI をインストールします。
1. 以下のコマンドを実行してください。*マイクラスター* の部分は自分のクラスター名に置き換えます。`ConfigMap` メソッドを完全に無効にする場合は`API_AND_CONFIG_MAP` を `API` に置き換えてください。
Amazon EKS がクラスターの更新を開始し、クラスターのステータスが [UPDATING] に変わり、変更が **aws eks list-updates** に記録されます。
```
aws eks update-cluster-config --name my-cluster --access-config authenticationMode=API_AND_CONFIG_MAP
```
1. クラスターのステータスが [アクティブ] に戻るまで待ちます。クラスターが [アクティブ] になったら、「[アクセスエントリを作成する](creating-access-entries.md)」の手順に従って IAM プリンシパルのクラスターへのアクセスを追加できます。
## 必要なプラットフォームバージョン
*アクセスエントリ*を使用するには、クラスターのプラットフォームバージョンが、次の表に記載されているバージョンと同じかそれ以降、または表に記載されている Kubernetes バージョンよりも新しいバージョンである必要があります。Kubernetes バージョンがリストにない場合は、すべてのプラットフォームバージョンでアクセスエントリがサポートされます。
| Kubernetes バージョン | プラットフォームバージョン |
| --- | --- |
| リストに記載なし | すべてサポート |
| `1.30` | `eks.2` |
| `1.29` | `eks.1` |
| `1.28` | `eks.6` |
詳細については、「[platform-versions](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html)」を参照してください。
# アクセスエントリを作成する
アクセスエントリを作成する前に、次の点を考慮してください：
+ 適切に設定された認証モード。「[アクセスエントリを使用するように認証モードを変更する](setting-up-access-entries.md)」を参照してください。
+ アクセスエントリには1 つだけの既存の IAM プリンシパルの Amazon リソースネーム (ARN) が含まれます。IAM プリンシパルは複数のアクセスエントリに含めることはできません。指定する ARN に関するその他の考慮事項
+ IAM のベストプラクティスでは長期認証情報を持つ IAM ユーザーではなく、短期認証情報を持つ IAM ロールを使用してクラスターにアクセスすることを推奨しています。詳細は「*IAM ユーザーガイド*」の「[人間のユーザーが一時的な認証情報を使用して AWS にアクセスするにはID プロバイダーとのフェデレーションの使用が必要です](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。
+ ARN が IAM ロール用の場合はパスを含めることができます。`aws-auth` `ConfigMap` エントリの ARN にはパスを含めることはできません。例えば、ARN は ` arn:aws:iam::<111122223333>:role/` または ` arn:aws:iam::<111122223333>:role/` にすることができます。
+ アクセスエントリのタイプが `STANDARD` 以外の場合 (タイプに関する次の考慮事項を参照)、ARN はクラスターと同じ AWS アカウントにある必要があります。タイプが `STANDARD` の場合、ARN はクラスターが属するアカウントと同じ、または異なる AWS アカウントでもかまいません。
+ アクセスエントリの作成後に IAM プリンシパルを変更することはできません。
+ この ARN を含む IAM プリンシパルを削除しても、アクセスエントリは自動的に削除されません。削除する IAM プリンシパルの ARN を含むアクセスエントリを削除することをお勧めします。アクセスエントリを削除せず、IAM プリンシパルを再作成すると、同じ ARN があっても、アクセスエントリは機能しません。これは再作成された IAM プリンシパルの ARN は同じですが、再作成された IAM プリンシパルの `roleID` または `userID` (`aws sts get-caller-identity` AWS CLI コマンドで確認できます) は元の IAM プリンシパルの ARN とは異なるためです。アクセスエントリの IAM プリンシパルの `roleID` または `userID` が表示されない場合でも、Amazon EKS はそれをアクセスエントリとともに保存します。
+ 各アクセスエントリには*タイプ*があります。アクセスエントリの種類は関連付けられているリソースの種類によって異なり、アクセス許可を定義しません。タイプを指定しない場合、Amazon EKS は自動的にタイプを `STANDARD` に設定します。
+ `EC2_LINUX` - Linux または Bottlerocket セルフマネージド型ノードで使用される IAM ロール用
+ `EC2_WINDOWS` - Windows セルフマネージドノードで使用される IAM ロール用
+ `FARGATE_LINUX` - AWS Fargate (Fargate) で使用される IAM ロール用
+ `HYBRID_LINUX` - ハイブリッドノードで使用される IAM ロール用
+ `STANDARD` - 指定しない場合のデフォルトタイプ
+ `EC2` - EKS Auto Mode カスタムノードクラス用。詳細については、「[ノードクラスのアクセスエントリを作成する](create-node-class.md#auto-node-access-entry)」を参照してください。
+ アクセスエントリの作成後にタイプを変更することはできません。
+ マネージドノードグループまたは Fargate プロファイルに使用される IAM ロールのアクセスエントリを作成する必要はありません。EKS はアクセス エントリを作成するか (有効な場合)、認証構成マップを更新します (アクセス エントリが利用できない場合)。
+ アクセスエントリのタイプが `STANDARD` の場合、アクセスエントリのユーザー名を指定できます。ユーザー名の値を指定しない場合、Amazon EKS はアクセスエントリのタイプと、指定した IAM プリンシパルが IAM ロールか IAM ユーザーかに応じて、以下のいずれかの値を設定します。独自のユーザー名を指定する特別な理由がない限り、ユーザー名を指定せず、Amazon EKS に自動生成させることをお勧めします。独自のユーザー名を指定する場合:
+ `system:`、`eks:`、`aws:`、`amazon:`、または `iam:` で始めることはできません。
+ ユーザー名が IAM ロール用の場合は、ユーザー名の末尾に `{{SessionName}}` または `{{SessionNameRaw}}` を追加することをお勧めします。ユーザー名に `{{SessionName}}` または `{{SessionNameRaw}}` を追加する場合、ユーザー名の \$1\$1SessionName\$1\$1 の*前*にコロンを含める必要があります。このロールを引き受けると、ロールを引き受けるときに指定された AWS STS セッションの名前が自動的にクラスターに渡され、CloudTrail ログに表示されます。例えば、`john{{SessionName}}` というユーザー名にはできません。ユーザー名は `:john{{SessionName}}` または `jo:hn{{SessionName}}` でなければなりません。コロンは `{{SessionName}}` の前になければいけません。次の表の Amazon EKS によって生成されたユーザー名には ARN が含まれています。ARN にはコロンが含まれているため、この要件を満たしています。ユーザー名に `{{SessionName}}` を含めなければ、コロンは不要です。`{{SessionName}}` の場合、セッション名の特殊文字「@」は「-」に置き換えられます。`{{SessionNameRaw}}` の場合、セッション名の特殊文字はすべて保持されます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/creating-access-entries.html)
アクセスエントリの作成後にユーザー名を変更することができます。
+ アクセスエントリのタイプが `STANDARD` で、Kubernetes RBAC 認可を使用する場合はアクセスエントリに 1 つ以上の*グループ名*を追加できます。アクセスエントリを作成したら、グループ名を追加および削除できます。IAM プリンシパルがクラスター上の Kubernetes オブジェクトにアクセスできるようにするには Kubernetes ロールベース認可 (RBAC) オブジェクトを作成して管理する必要があります。クラスター上で Kubernetes `RoleBinding` または `ClusterRoleBinding` オブジェクトを作成し、`kind: Group` の `subject` としてグループ名を指定します。Kubernetes は、Kubernetes `Role` で指定したクラスターオブジェクト、またはバインディングの `roleRef` でも指定した `ClusterRole` オブジェクトへの IAM プリンシパルアクセスを許可します。グループ名を指定する場合は、Kubernetes ロールベース認可 (RBAC) オブジェクトについて理解しておくことをお勧めします。詳細についてはKubernetes ドキュメントの「[RBAC 認可を使用する](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)」を参照してください。
**重要**
Amazon EKS はクラスターに存在する Kubernetes RBAC オブジェクトに、指定したグループ名が含まれていることを確認しません。例えば、現時点で存在しないグループのアクセス エントリを作成すると、EKS はエラーを返す代わりにグループを作成します。
クラスター上の Kubernetes オブジェクトに IAM プリンシパルがアクセスするのを許可する Kubernetes の代わりに、またはそれに加えて、Amazon EKS *アクセスポリシー*をアクセスエントリに関連付けることができます。Amazon EKS はIAM プリンシパルがアクセスポリシーのアクセス許可を使用してクラスター上の Kubernetes オブジェクトにアクセスすることを許可します。アクセスポリシーのアクセス許可の範囲は指定した Kubernetes 名前空間に限定できます。アクセスポリシーを使用する場合、Kubernetes RBAC オブジェクトを管理する必要はありません。詳細については、「[アクセスポリシーをアクセスエントリに関連付ける](access-policies.md)」を参照してください。
+ タイプが `EC2_LINUX` または `EC2_Windows` のアクセスエントリを作成する場合、アクセスエントリを作成する IAM プリンシパルには `iam:PassRole` アクセス許可が必要です。詳細については「*IAM ユーザーガイド*」の「[AWS サービスにロールを渡す許可をユーザーに付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html)」を参照してください。
+ 標準的な [IAM 動作](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency)と同様に、アクセスエントリの作成と更新は最終的には一貫性があり、最初の API コールが正常に戻ってから有効になるまでに数秒かかる場合があります。発生する可能性のあるこれらの遅延を考慮して、アプリケーションを設計する必要があります。アプリケーションの重要で高可用性のコードパスにはアクセスエントリの作成や更新を含めないことをお勧めします。代わりに、実行頻度が低い別の初期化またはセットアップルーチンに の変更を加えます。また、本番稼働ワークフローが依存する前に、変更が伝達済みであることを確認します。
+ アクセスエントリは[サービスリンクロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html)をサポートしていません。プリンシパル ARN がサービスリンクロールである場合、アクセスエントリを作成することはできません。サービスリンクロールは` arn:aws:iam::*:role/aws-service-role/*` 形式の ARN によって識別できます。
AWS マネジメントコンソール または AWS CLI を使用してアクセスエントリを作成できます。
## AWS マネジメントコンソール
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. アクセスエントリを作成するクラスターの名前を選択してください。
1. **[リモートアクセス]** タブを選択してください。
1. **[アクセスエントリの作成]** を選択してください。
1. **IAM プリンシパル**には既存の IAM ロールまたはユーザーを選択してください。IAM のベストプラクティスでは長期認証情報を持つ IAM ユーザーではなく、短期認証情報を持つ IAM ロールを使用してクラスターにアクセスすることを推奨しています。詳細は「*IAM ユーザーガイド*」の「[人間のユーザーが一時的な認証情報を使用して AWS にアクセスするにはID プロバイダーとのフェデレーションの使用が必要です](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。
1. **[タイプ]** で、アクセスエントリがセルフマネージド型の Amazon EC2 ノードに使用されるノードロール用のものである場合は**[EC2 Linux]** または **[EC2 Windows]** を選択してください。それ以外の場合はデフォルト (**標準**) をそのまま使用します。
1. 選択した **タイプ**が**標準**で、**ユーザー名**を指定する場合はユーザー名を入力します。
1. 選択した**タイプ**が**標準**で、IAM プリンシパルに Kubernetes RBAC 認可を使用したい場合は**グループ**に 1 つ以上の名前を指定します。グループ名を指定せず、Amazon EKS 認可を使用する場合は後のステップで、またはアクセスエントリの作成後にアクセスポリシーを関連付けることができます。
1. (オプション) **[タグ]** ではアクセスエントリにラベルを割り当てます。例えば、同じタグを持つすべてのリソースを検索しやすくするためです。
1. [**次へ**] を選択します。
1. **[アクセスポリシーを追加]** ページで、選択したタイプが**標準**で、Amazon EKS が IAM プリンシパルにクラスター上の Kubernetes オブジェクトへのアクセス許可を与えることを許可する場合は次のステップを実行してください。それ以外の場合は**[次へ]** を選択してください。
1. **[ポリシー名]** にはアクセスポリシーを選択してください。アクセスポリシーのアクセス許可は表示できませんが、Kubernetes ユーザー向け `ClusterRole` オブジェクトと同様のアクセス許可が含まれています。詳細については、Kubernetes ドキュメントの「[ユーザー向け Role](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)」を参照してください。
1. 以下のオプションのいずれかを選択してください：
+ **クラスター** — Amazon EKS が IAM プリンシパルに、クラスター上のすべての Kubernetes オブジェクトのアクセスポリシー内のアクセス許可があるように承認する場合はこのオプションを選択してください。
+ **Kubernetes 名前空間** — Amazon EKS が IAM プリンシパルに、クラスター上の特定の Kubernetes 名前空間のすべての Kubernetes オブジェクトのアクセスポリシー内のアクセス許可があるように承認する場合はこのオプションを選択してください。**[名前空間]** にはクラスター上の Kubernetes 名前空間の名前を入力します。名前空間をさらに追加する場合は**[新しい名前空間を追加する]** を選択し、名前空間名を入力します。
1. ポリシーを追加するには**[ポリシーを追加]** を選択してください。ポリシーごとに異なる範囲を設定できますが、各ポリシーは 1 回しか追加できません。
1. [** 次へ**] を選択してください。
1. アクセスエントリの設定を確認してください。何かが正しくないと思われる場合は**[戻る]** を選択してステップに戻り、エラーを修正します。設定が正しければ、**[作成]** を選択してください。
## AWS CLI
1. AWS コマンドラインインターフェイスユーザーガイドの「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」の説明に従って、AWS CLI をインストールします。
1. アクセスエントリを作成するには以下のいずれかの例を使用してアクセスエントリを作成できます：
+ セルフマネージド型 Amazon EC2 Linux ノードグループのアクセスエントリを作成します。*マイクラスター* はクラスターの名前、*111122223333* は自分の AWS アカウント ID に、*EKS-マイクラスター-self-managed-ng-1* は[ノード IAM ロール](create-node-role.md)の名前に置き換えます。ノードグループが Windows ノードグループの場合は *EC2\$1LINUX* を `EC2_Windows` に置き換えてください。
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 --type EC2_LINUX
```
`STANDARD` 以外のタイプを指定する場合、`--kubernetes-groups` オプションは使用できません。タイプが `STANDARD` 以外の値であるため、このアクセスエントリにアクセスポリシーを関連付けることはできません。
+ Amazon EC2 セルフマネージド型ノードグループには使用されていない IAM ロールを許可するアクセスエントリを作成し、Kubernetes にクラスターへのアクセスを許可してもらいます。*マイクラスター* をクラスターの名前に、*111122223333* を AWS アカウント ID に、*my-role* を IAM ロールの名前に置き換えます。*Viewers* はクラスター上の Kubernetes `RoleBinding` または `ClusterRoleBinding` オブジェクトで指定したグループの名前に置き換えます。
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role --type STANDARD --user Viewers --kubernetes-groups Viewers
```
+ IAM ユーザーがクラスターに対して認証できるようにするアクセスエントリを作成します。これも可能であるためこの例が示されていますが、IAM のベストプラクティスでは長期認証情報を持つ IAM ユーザーではなく、短期認証情報を持つ IAM ロールを使用してクラスターにアクセスすることを推奨しています。詳細は「*IAM ユーザーガイド*」の「[人間のユーザーが一時的な認証情報を使用して AWS にアクセスするにはID プロバイダーとのフェデレーションの使用が必要です](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:user/my-user --type STANDARD --username my-user
```
このユーザーに Kubernetes API ディスカバリーロールのアクセス許可よりも多くのクラスターへのアクセスを許可したい場合は `--kubernetes-groups` オプションが使用されていないため、アクセスエントリにアクセスポリシーを関連付ける必要があります。詳細については、「[アクセスポリシーをアクセスエントリに関連付ける](access-policies.md)」と Kubernetes ドキュメントの「[APIディスカバリーロール](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#discovery-roles)」を参照してください。
# アクセスエントリを更新する
AWS マネジメントコンソール または AWS を使用してアクセスエントリを更新できます。
## AWS マネジメントコンソール
1. [アマゾン EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. アクセスエントリを作成するクラスターの名前を選択してください。
1. **[リモートアクセス]** タブを選択してください。
1. 更新するアクセスエントリを選択します。
1. [**編集**] を選択します。
1. **[ユーザー名]** では、既存の値を変更できます。
1. **[グループ]**では、既存のグループ名を削除したり、新しいグループ名を追加したりできます。**system:nodes** または **system bootstrappers** というグループ名が存在する場合は、削除しないでください。これらのグループを削除すると、クラスターが正しく機能しなくなる可能性があります。グループ名を指定せず、Amazon EKS 認可を使用する場合は、後のステップで、 [アクセスポリシー](access-policies.md)を関連付けます。
1. **[タグ]** では、アクセスエントリにラベルを割り当てます。例えば、同じタグを持つすべてのリソースを検索しやすくするためです。また、既存のタグを削除することもできます。
1. [**Save changes**] (変更の保存) をクリックします。
1. アクセスポリシーをエントリに関連付ける場合は、[アクセスポリシーをアクセスエントリに関連付ける](access-policies.md) を参照してください。
## AWS CLI
1. AWS コマンドラインインターフェイスユーザーガイドの「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」の説明に従って、AWS CLI をインストールします。
1. アクセスエントリを更新するには、*my-cluster* はクラスターの名前、*111122223333* は AWS アカウント ID に、*EKS-my-cluster-my-namespace-Viewers* は IAM ロールの名前に置き換えます。
```
aws eks update-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers --kubernetes-groups Viewers
```
アクセスエントリのタイプが `STANDARD` 以外の値の場合、`--kubernetes-groups` オプションは使用できません。また、アクセスポリシーを `STANDARD` 以外のタイプのアクセスエントリに関連付けることもできません。
# アクセスエントリを削除する
アクセスエントリを誤って削除したことが判明した場合は、いつでも再作成できます。削除するアクセスエントリがアクセスポリシーに関連付けられている場合、その関連付けは自動的に削除されます。アクセスエントリを削除する前に、アクセスポリシーとアクセスエントリの関連付けを解除する必要はありません。
AWS マネジメントコンソール または AWS CLI を使用してアクセスエントリを削除できます。
## AWS マネジメントコンソール
1. [アマゾン EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. アクセスエントリを削除するクラスターの名前を選択します。
1. **[リモートアクセス]** タブを選択してください。
1. **[アクセスエントリ]** リストで、削除するアクセスエントリを選択します。
1. [Delete] を選択します。
1. 確認ダイアログボックスで、[**削除**] を選択します。
## AWS CLI
1. AWS コマンドラインインターフェイスユーザーガイドの「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」の説明に従って、AWS CLI をインストールします。
1. アクセスエントリを削除するには、*my-cluster* をクラスターの名前、*111122223333* を AWS アカウント ID に、*my-role* をクラスターにアクセスさせたくない IAM ロールの名前に置き換えます。
```
aws eks delete-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role
```
# EKS アクセスエントリ用のカスタムユーザー名を設定する
Amazon EKS 用のアクセスエントリを作成するときに、自動生成されたユーザー名を使用することも、カスタムユーザー名を指定することもできます。このページでは、両方のオプションについて説明し、カスタムユーザー名を設定する手順を示します。
## 概要:
アクセスエントリにユーザー名を使用すると、Kubernetes のログと監査証跡で IAM プリンシパルを識別できます。デフォルトでは、Amazon EKS は IAM ID の ARN に基づいてユーザー名を生成しますが、必要に応じてカスタムユーザー名を指定することもできます。
## デフォルトのユーザー名の生成
ユーザー名の値を指定しないと、Amazon EKS は IAM ID に基づいてユーザー名を自動的に生成します。
+ **IAM ユーザーの場合**:
+ EKS は、Kubernetes ユーザー名を IAM ユーザーの ARN に設定します。
+ 例:
```
{arn-aws}iam::<111122223333>:user/
```
+ **IAM ロールの場合:**
+ EKS は、IAM ロールの ARN に基づいて Kubernetes ユーザー名を設定します。
+ 想定されるロールの STS ARN。Amazon EKS では`{{SessionName}}` がロールに追加されます。指定したロールの ARN にパスが含まれている場合、Amazon EKS は生成されたユーザー名からそのパスを削除してください。
+ 例:
```
{arn-aws}sts::<111122223333>:assumed-role//{{SessionName}}
```
独自のユーザー名を指定する特別な理由がない限り、ユーザー名を指定せず、Amazon EKS に自動生成させることをお勧めします。
## カスタムユーザー名の設定
アクセスエントリを作成するときは、`--username` パラメータを使用して、カスタムユーザー名を指定できます。
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD --username
```
### カスタムユーザー名の要件
カスタムユーザー名を指定する場合:
+ ユーザー名を `system:`、`eks:`、`aws:`、`amazon:`、または `iam:` で始めることはできません。
+ ユーザー名が IAM ロール用の場合は、ユーザー名の末尾に `{{SessionName}}` または `{{SessionNameRaw}}` を追加することをお勧めします。
+ ユーザー名に `{{SessionName}}` または `{{SessionNameRaw}}` を追加する場合、ユーザー名の \$1\$1SessionName\$1\$1 の*前*にコロンを含める必要があります。
# アクセスポリシーと AWS CLI を使用して IAM ロールまたは IAM ユーザーのアクセスエントリを作成する
Amazon EKS アクセスエントリを作成すると、AWS マネージド EKS アクセスポリシーを使用して、Kubernetes クラスターにアクセスおよび管理するための標準化されたアクセス許可を IAM ID に付与できるようになります。
## 概要
Amazon EKS のアクセスエントリでは、IAM ID (ユーザーとロール) が Kubernetes クラスターにアクセスしてやり取りする方法を定義します。EKS アクセスポリシーを使用してアクセスエントリを作成することで、次のことができます。
+ EKS クラスターへのアクセス許可を特定の IAM ユーザーまたは IAM ロールに付与する
+ AWS マネージド EKS アクセスポリシーでアクセス許可セットを標準化および事前定義してアクセス許可を制御する
+ アクセス許可のスコープを特定の名前空間またはクラスター全体に指定する
+ `aws-auth` ConfigMap の変更も Kubernetes RBAC リソースの作成も不要にして、アクセス管理を簡素化する
+ AWS 統合アプローチを使用した Kubernetes アクセスコントロールにより、よくあるユースケースに対応すると共に、セキュリティベストプラクティスを維持する
AWS マネージドの標準化されたアクセス許可を実現し、Kubernetes RBAC を手動で設定する必要がないため、ほとんどのユースケースにお勧めのアプローチです。EKS アクセスポリシーにより、Kubernetes RBAC リソースを手動で設定する必要がなくなり、よくあるユースケースに対応したアクセス許可セットを事前定義できます。
## 前提条件
+ *アクセスエントリ*を有効にするようにクラスターの*認証モード*を設定する必要があります。詳細については、「[アクセスエントリを使用するように認証モードを変更する](setting-up-access-entries.md)」を参照してください。
+ AWS コマンドラインインターフェイスユーザーガイドの「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」の説明に従って、AWS CLI をインストールして設定します。
## ステップ 1: アクセスエントリを定義する
1. アクセス許可を付与する IAM ID (ユーザーやロールなど) の ARN を確認します。
+ IAM ID ごとに EKS アクセスエントリを 1 つのみ含めることができます。
1. Amazon EKS アクセスポリシーアクセス許可を特定の Kubernetes 名前空間にのみ適用するか、クラスター全体に適用するかを決定します。
+ アクセス許可を特定の名前空間に制限する場合は、その名前空間の名前を書き留めます。
1. IAM ID に使用する EKS アクセスポリシーを選択します。このポリシーでは、クラスター内アクセス許可を付与します。ポリシーの ARN を書き留めます。
+ ポリシーのリストについては、「[available access policies](access-policy-permissions.md)」を参照してください。
1. 自動生成したユーザー名がアクセスエントリに適しているかどうかや、ユーザー名を手動で指定する必要があるかどうかを判断します。
+ AWS は、IAM ID に基づいてこの値を自動生成します。カスタムのユーザー名を設定できます。この名前が Kubernetes ログに表示されます。
+ 詳細については、「[EKS アクセスエントリ用のカスタムユーザー名を設定する](set-custom-username.md)」を参照してください。
## ステップ 2: アクセスエントリを作成する
アクセスエントリを作成する準備を整えたら、AWS CLI を使用して作成します。
以下に、よくあるユースケースの例を示します。[すべての設定オプションについて CLI リファレンスを表示します](https://docs.aws.amazon.com/cli/latest/reference/eks/create-access-entry.html)。
次のステップでアクセスポリシーをアタッチします。
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD
```
## ステップ 3: アクセスポリシーを関連付ける
使用するコマンドは、ポリシーを指定の Kubernetes 名前空間に制限するかどうかによって異なります。
アクセスポリシーの ARN が必要になります。[利用可能なアクセスポリシー](access-policy-permissions.md)をレビューします。
### 名前空間スコープを指定せずにポリシーを作成する
```
aws eks associate-access-policy --cluster-name --principal-arn --policy-arn
```
### 名前空間スコープを指定してポリシーを作成する
```
aws eks associate-access-policy --cluster-name --principal-arn \
--access-scope type=namespace,namespaces=my-namespace1,my-namespace2 --policy-arn
```
## 次のステップ
+ [kubectl を IAM ID と共に使用できるように kubeconfig を作成する](create-kubeconfig.md)
# AWS CLI で Kubernetes グループを使用してアクセスエントリを作成する
作成する Amazon EKS アクセスエントリは、認可に Kubernetes グループを使用し、RBAC を手動で設定する必要があるものとします。
**注記**
通常は、このページで説明している Kubernetes グループによるアプローチではなく、EKS アクセスポリシーを使用する方法をお勧めします。EKS アクセスポリシーでは、AWS との統合を進めたシンプルな方法でアクセスを管理するため、RBAC を手動で設定する必要がありません。Kubernetes グループによるアプローチを使用するのは、EKS アクセスポリシーよりもさらにきめ細かく制御する必要がある場合だけにしてください。
## 概要
アクセスエントリでは、IAM ID (ユーザーとロール) が Kubernetes クラスターにアクセスする方法を定義します。Kubernetes グループによるアプローチでは、標準の Kubernetes RBAC グループを介して EKS クラスターにアクセスするためのアクセス許可を IAM ユーザーまたは IAM ロールに付与します。この方法では、Kubernetes RBAC リソース (Roles、RoleBindings、ClusterRoles、ClusterRoleBindings) を作成および管理する必要があります。高度にカスタマイズされたアクセス許可セットが必要なときや複雑な認可要件が必要なとき、あるいはハイブリッド Kubernetes 環境全体にわたって一貫したアクセスコントロールパターンを維持するときに、お勧めの方法です。
このトピックでは、Amazon EC2 インスタンスが EKS クラスターに参加する際に使用する IAM ID 用のアクセスエントリの作成については取り上げません。
## 前提条件
+ *アクセスエントリ*を有効にするようにクラスターの*認証モード*を設定する必要があります。詳細については、「[アクセスエントリを使用するように認証モードを変更する](setting-up-access-entries.md)」を参照してください。
+ AWS コマンドラインインターフェイスユーザーガイドの「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」の説明に従って、AWS CLI をインストールして設定します。
+ Kubernetes RBAC をよく理解しておくことをお勧めします。詳細についてはKubernetes ドキュメントの「[RBAC 認可を使用する](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)」を参照してください。
## ステップ 1: アクセスエントリを定義する
1. アクセス許可を付与する IAM ID (ユーザーやロールなど) の ARN を確認します。
+ IAM ID ごとに EKS アクセスエントリを 1 つのみ含めることができます。
1. この IAM ID に関連付ける Kubernetes グループを決定します。
+ そのグループを参照する Kubernetes `Role`/`ClusterRole` と `RoleBinding`/`ClusterRoleBinding` リソースを作成するか、既存のものを使用する必要があります。
1. 自動生成したユーザー名がアクセスエントリに適しているかどうかや、ユーザー名を手動で指定する必要があるかどうかを判断します。
+ AWS は、IAM ID に基づいてこの値を自動生成します。カスタムのユーザー名を設定できます。この名前が Kubernetes ログに表示されます。
+ 詳細については、「[EKS アクセスエントリ用のカスタムユーザー名を設定する](set-custom-username.md)」を参照してください。
## ステップ2: Kubernetes グループと共にアクセスエントリを作成する
アクセスエントリを作成する準備を整えたら、AWS CLI を使用して適切な Kubernetes グループと共に作成します。
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD --kubernetes-groups
```
置換:
+ `` を EKS クラスター名に置き換えます。
+ `` を IAM ユーザーまたはロールの ARN に置き換えます。
+ `` を Kubernetes グループのカンマ区切りリスト (例えば「system:developers,system:readers」)に置き換えます。
[すべての設定オプションについて CLI リファレンスを表示します](https://docs.aws.amazon.com/cli/latest/reference/eks/create-access-entry.html)。
## ステップ 3: Kubernetes RBAC を設定する
IAM プリンシパルがクラスター上の Kubernetes オブジェクトにアクセスできるようにするには、Kubernetes ロールベースアクセスコントロール (RBAC) オブジェクトを作成して管理する必要があります。
1. アクセス許可を定義する Kubernetes オブジェクト `Role` または `ClusterRole` を作成します。
1. クラスター上で Kubernetes `RoleBinding` または `ClusterRoleBinding` オブジェクトを作成し、`kind: Group` の `subject` としてグループ名を指定します。
Kubernetes でグループとアクセス許可を設定する方法の詳細については、Kubernetes のドキュメントの「[Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)」を参照してください。
## 次のステップ
+ [kubectl を IAM ID と共に使用できるように kubeconfig を作成する](create-kubeconfig.md)
# ConfigMap を使用して IAM ユーザーに Kubernetes へのアクセスを許可する
**重要**
`aws-auth ConfigMap` は非推奨になりました。Kubernetes API へのアクセスを管理する推奨手段については、「[EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する](access-entries.md)」を参照してください。
[IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)を使用してクラスターにアクセスします。プリンシパルは、Amazon EKS コントロールプレーンで実行される [AWS IAM Authenticator for Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme) によって有効になります。オーセンティケーターは、その設定情報を `aws-auth` `ConfigMap` から取得します。すべての `aws-auth` `ConfigMap` 設定については、GitHub の [Full Configuration Format](https://github.com/kubernetes-sigs/aws-iam-authenticator#full-configuration-format) を参照してください。
## Amazon EKS クラスターに IAM プリンシパルを追加する
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` を作成します。
**注記**
Kubernetes のロールベースアクセスコントロール (RBAC) 設定の詳細については、Kubernetes ドキュメントの「[RBAC 認可を使用する](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)」を参照してください。
1. クラスターへのアクセスに `kubectl` が使用している認証情報を判別します。使用中のコンピュータ上で、次のコマンドを使用して、`kubectl` が使用する認証情報を判別できます。デフォルトのパスを使用しない場合は、*\$1/.kube/config* を `kubeconfig` ファイルへのパスに置き換えます。
```
cat ~/.kube/config
```
出力例は次のとおりです。
```
[...]
contexts:
- context:
cluster: my-cluster.region-code.eksctl.io
user: admin@my-cluster.region-code.eksctl.io
name: admin@my-cluster.region-code.eksctl.io
current-context: admin@my-cluster.region-code.eksctl.io
[...]
```
前述の出力例では、*admin* という名前のユーザーの認証情報が *my-cluster* という名前のクラスター用に設定されています。このユーザーがクラスターを作成したユーザーである場合は、すでにそのクラスターにアクセスできます。クラスターを作成したユーザーでない場合は、以降の手順を実行して、他の IAM プリンシパルのクラスターへのアクセスを有効にする必要があります。[IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)では、ユーザーではなくロールに許可を付与することが推奨されています。次のコマンドを使用すると、現在クラスターへのアクセスが可能な、他のプリンシパルを確認できます。
```
kubectl describe -n kube-system configmap/aws-auth
```
出力例は次のとおりです。
```
Name: aws-auth
Namespace: kube-system
Labels:
Annotations:
Data
====
mapRoles:
----
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam::111122223333:role/my-node-role
username: system:node:{{EC2PrivateDNSName}}
BinaryData
====
Events:
```
前の例は、デフォルトの `aws-auth` `ConfigMap` です。ノードインスタンスのロールだけがクラスターにアクセスできます。
1. IAM プリンシパルをマッピングできる既存の Kubernetes `roles` と `rolebindings` または `clusterroles` と `clusterrolebindings` があることを確認してください。これらのリソースの詳細については、Kubernetes ドキュメントの「[RBAC 認可を使用する](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)」を参照してください。
1. 既存の Kubernetes の `roles` または `clusterroles` を表示します。`Roles` は `namespace` スコープされ、`clusterroles` はクラスターにスコープされます。
```
kubectl get roles -A
```
```
kubectl get clusterroles
```
1. 前の出力で返された `role` または `clusterrole` の詳細を表示します。クラスター内で IAM プリンシパルに必要となる許可 (`rules`) があることを確認します。
前のコマンド出力で返された *role-name* を、`role` の名前に置き換えます。*kube-system* を、`role` の名前空間に置き換えます。
```
kubectl describe role role-name -n kube-system
```
*cluster-role-name* を、前のコマンドの出力で返された `clusterrole` 名に置き換えます。
```
kubectl describe clusterrole cluster-role-name
```
1. 既存の Kubernetes の `rolebindings` または `clusterrolebindings` を表示します。`Rolebindings` は `namespace` スコープされ、`clusterrolebindings` はクラスターにスコープされます。
```
kubectl get rolebindings -A
```
```
kubectl get clusterrolebindings
```
1. `rolebinding` または `clusterrolebinding` の詳細を表示して、前のステップで `roleRef` としてリストされた `role` または `clusterrole`、そして `subjects` にリストされたグループ名があることを確認します。
*role-binding-name* を、前のコマンドの出力で返された `rolebinding` の名前に置き換えます。*kube-system* は、`rolebinding` の `namespace` で置き換えます。
```
kubectl describe rolebinding role-binding-name -n kube-system
```
出力例は次のとおりです。
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: eks-console-dashboard-restricted-access-role-binding
namespace: default
subjects:
- kind: Group
name: eks-console-dashboard-restricted-access-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: eks-console-dashboard-restricted-access-role
apiGroup: rbac.authorization.k8s.io
```
*cluster-role-binding-name* は、前のコマンドの出力で返された `clusterrolebinding` の名前で置き換えます。
```
kubectl describe clusterrolebinding cluster-role-binding-name
```
出力例は次のとおりです。
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: eks-console-dashboard-full-access-binding
subjects:
- kind: Group
name: eks-console-dashboard-full-access-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: eks-console-dashboard-full-access-clusterrole
apiGroup: rbac.authorization.k8s.io
```
1. `aws-auth` `ConfigMap` を編集します。`eksctl` のようなツールにより `ConfigMap` を更新することができます。あるいは、手動で編集しての更新も可能です。
**重要**
`ConfigMap` の編集には、`eksctl` や、その他のツールを使用することをお勧めします。使用できる他のツールについては、Amazon EKS ベストプラクティスガイドの「[ツールを使用して aws-authConfigMap を変更する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#use-tools-to-make-changes-to-the-aws-auth-configmap)」を参照してください。`aws-auth` `ConfigMap` の形式が不適切な場合、クラスターへのアクセスが失われる場合があります。
+ [eksctl で configmap を編集する](#configmap-eksctl)ステップを表示します。
+ [configmap を手動で編集する](#configmap-manual)ステップを表示します。
### Eksctl で Configmap を編集する
1. デバイスまたは AWS CloudShell にインストールされている `eksctl` コマンドラインツールのバージョン `0.215.0` 以降が必要です。`eksctl` をインストールまたはアップグレードするには`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。
1. `ConfigMap` に現在のマッピングを表示します。*マイクラスター* の部分は自分のクラスター名に置き換えます。*region-code* を、クラスターのある AWS リージョンに置き換えます。
```
eksctl get iamidentitymapping --cluster my-cluster --region=region-code
```
出力例は次のとおりです。
```
ARN USERNAME GROUPS ACCOUNT
arn:aws:iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
```
1. ロールのマッピングを追加します。*my-role* を実際のロールの名前に置き換えます。*eks-console-dashboard-full-access-group* を、Kubernetes の `RoleBinding` または `ClusterRoleBinding` オブジェクトで指定されたグループの名前に置き換えます。*111122223333* は、ご自分のアカウント ID に置き換えます。*管理者*を任意の名前に置き換えることができます。
```
eksctl create iamidentitymapping --cluster my-cluster --region=region-code \
--arn arn:aws:iam::111122223333:role/my-role --username admin --group eks-console-dashboard-full-access-group \
--no-duplicate-arns
```
**重要**
ロールの ARN には、`role/my-team/developers/my-role` などのパスを含めることはできません。ロールの ARN は、` arn:aws:iam::111122223333:role/my-role ` のような形式にする必要があります。この例では、`my-team/developers/` を削除する必要があります。
出力例は次のとおりです。
```
[...]
2022-05-09 14:51:20 [ℹ] adding identity "{arn-aws}iam::111122223333:role/my-role" to auth ConfigMap
```
1. ユーザーのマッピングを追加します。[IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)では、ユーザーではなくロールに許可を付与することが推奨されています。*my-user* を、ご自身のユーザー名に置き換えます。*eks-console-dashboard-restricted-access-group* を、Kubernetes `RoleBinding` または `ClusterRoleBinding` オブジェクトで指定されたグループの名前に置き換えます。*111122223333* は、ご自分のアカウント ID に置き換えます。*my-user* を任意の名前に置き換えることができます。
```
eksctl create iamidentitymapping --cluster my-cluster --region=region-code \
--arn arn:aws:iam::111122223333:user/my-user --username my-user --group eks-console-dashboard-restricted-access-group \
--no-duplicate-arns
```
出力例は次のとおりです。
```
[...]
2022-05-09 14:53:48 [ℹ] adding identity "arn:aws:iam::111122223333:user/my-user" to auth ConfigMap
```
1. `ConfigMap` のマッピングを再度表示します。
```
eksctl get iamidentitymapping --cluster my-cluster --region=region-code
```
出力例は次のとおりです。
```
ARN USERNAME GROUPS ACCOUNT
arn:aws:iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
arn:aws:iam::111122223333:role/admin my-role eks-console-dashboard-full-access-group
arn:aws:iam::111122223333:user/my-user my-user eks-console-dashboard-restricted-access-group
```
### Configmap を手動で編集する
1. 編集する `ConfigMap` を開きます。
```
kubectl edit -n kube-system configmap/aws-auth
```
**注記**
「`Error from server (NotFound): configmaps "aws-auth" not found`」というエラーが表示された場合は、「[aws-auth ConfigMap をクラスターに適用する](#aws-auth-configmap)」の手順を使用して、ストック `ConfigMap` を適用します。
1. IAM プリンシパルを `ConfigMap` に追加します。IAM グループは IAM プリンシパルではないため、`ConfigMap` に追加できません。
+ **IAM ロールを (たとえば、[フェデレーティッドユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)に) 追加するには**、`ConfigMap` の `mapRoles` セクションの `data` の下にロールの詳細を追加します。ファイルに存在しない場合は、このセクションを追加します。各エントリは、次のパラメータをサポートしています。
+ **rolearn**: 追加する IAM ロールの ARN。この値にパスを含めることはできません。例えば、` arn:aws:iam::111122223333:role/my-team/developers/role-name ` のような ARN を指定することはできません。ARN は、` arn:aws:iam::111122223333:role/role-name ` のようにする必要があります。
+ **username**: IAM ロールにマッピングする Kubernetes 内のユーザー名。
+ **groups**: ロールをマップする Kubernetes グループのグループまたはリスト。グループには、デフォルトグループか、`clusterrolebinding` または `rolebinding` で指定されたグループを使用します。詳細については、Kubernetes ドキュメントの「[デフォルト Role と ClusterRoleBinding](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings)」を参照してください。
+ **IAM ユーザーを追加するには:** [IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)では、ユーザーではなくロールに許可を付与することが推奨されています。`ConfigMap` の `mapUsers` セクション (`data` の下) にユーザーの詳細を追加します。ファイルに存在しない場合は、このセクションを追加します。各エントリは、次のパラメータをサポートしています。
+ **userarn**: 追加する IAM ユーザーの ARN。
+ **username**: IAM ユーザーにマッピングする Kubernetes 内のユーザー名。
+ **groups**: ユーザーをマップする Kubernetes グループのグループまたはリスト。グループには、デフォルトグループか、`clusterrolebinding` または `rolebinding` で指定されたグループを使用します。詳細については、Kubernetes ドキュメントの「[デフォルト Role と ClusterRoleBinding](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings)」を参照してください。
1. 例えば、次の YAML ブロックには次が含まれます。
+ ノードがそれ自体をクラスターに登録できるように、`my-console-viewer-role` IAM ノードインスタンスを Kubnetes グループにマッピングしている `mapRoles` セクション。および、すべてのクラスターですべての Kubernetes リソースを表示することが可能な、Kubernetes グループにマッピングされた IAM ロール。`my-console-viewer-role` IAM ロールに必要な IAM と Kubernetes グループのアクセス許可のリストについては、「[必要なアクセス許可](view-kubernetes-resources.md#view-kubernetes-resources-permissions)」を参照してください。
+ デフォルトの AWS アカウントからの `admin` IAM ユーザーを `system:masters` Kubernetes グループにマッピングする `mapUsers` セクション。および、特定の名前空間で Kubernetes リソースを表示することが可能な、Kubernetes グループにマッピングされた、他の AWS アカウントからの `my-user` ユーザー。`my-user` IAM ユーザーに必要な IAM と Kubernetes グループのアクセス許可のリストについては、「[必要なアクセス許可](view-kubernetes-resources.md#view-kubernetes-resources-permissions)」を参照してください。
必要に応じて行を追加または削除し、すべての値の例を、実際の値で置き換えます。
```
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam::111122223333:role/my-role
username: system:node:{{EC2PrivateDNSName}}
- groups:
- eks-console-dashboard-full-access-group
rolearn: arn:aws:iam::111122223333:role/my-console-viewer-role
username: my-console-viewer-role
mapUsers: |
- groups:
- system:masters
userarn: arn:aws:iam::111122223333:user/admin
username: admin
- groups:
- eks-console-dashboard-restricted-access-group
userarn: arn:aws:iam::444455556666:user/my-user
username: my-user
```
1. ファイルを保存し、テキストエディタを終了します。
## `aws-auth` `ConfigMap` をクラスターに適用する
マネージド型ノードグループを作成するとき、または `aws-auth` を使用してノードグループを作成するときに、`ConfigMap` `eksctl` が自動的に作成され、クラスターに適用されます。これはノードをクラスターに追加するために当初作成されたものですが、この `ConfigMap` を使用して、ロールベースアクセスコントロール (RBAC) アクセスを IAM プリンシパルに追加することもできます。セルフマネージド型ノードが起動済みで、クラスターに `aws-auth` `ConfigMap` を適用していない場合は、次の手順に従って適用できます。
1. `aws-auth` `ConfigMap` が適用済みであるかどうかを確認します。
```
kubectl describe configmap -n kube-system aws-auth
```
「`Error from server (NotFound): configmaps "aws-auth" not found`」というエラーが表示された場合は、以下のステップを実行してストック `ConfigMap` を適用します。
1. AWS オーセンティケーター設定マップをダウンロード、編集、適用します。
1. 設定マップをダウンロードします。
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml
```
1. `aws-auth-cm.yaml` ファイルで、ノードに関連付けられている IAM ロールの Amazon リソースネーム (ARN) に `rolearn` を設定します。これを行うには、テキストエディタを使用するか、*my-node-instance-role* を置き換えて次のコマンドを実行します。
```
sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml
```
このファイルの他の行は変更しないでください。
**重要**
ロールの ARN には、`role/my-team/developers/my-role` などのパスを含めることはできません。ロールの ARN は、` arn:aws:iam::111122223333:role/my-role ` のような形式にする必要があります。この例では、`my-team/developers/` を削除する必要があります。
ノードグループの AWS CloudFormation スタック出力を検査し、次の値を探すことができます。
+ **InstanceRoleARN** – `eksctl` で作成されたノードグループ用
+ **NodeInstanceRole** – AWS マネジメントコンソール で、Amazon EKS で発行された AWS CloudFormation テンプレートで作成されたノードグループ用
1. 設定を適用します。このコマンドが完了するまで数分かかることがあります。
```
kubectl apply -f aws-auth-cm.yaml
```
**注記**
認可またはリソースタイプのエラーが発生した場合はトラブルシューティングトピックの「[許可されていないか、アクセスが拒否されました (`kubectl`)](troubleshooting.md#unauthorized)」を参照してください。
1. ノードのステータスを監視し、`Ready` ステータスになるまで待機します。
```
kubectl get nodes --watch
```
`Ctrl`\$1`C` を入力して、シェルプロンプトに戻ります。
# 外部 OIDC プロバイダーを使用して Kubernetes へのアクセスをユーザーに許可する
Amazon EKS では、クラスターに対してユーザーを認証する方法として OpenID Connect (OIDC) ID プロバイダーがサポートされます。OIDC ID プロバイダーはAWS アイデンティティとアクセス管理 (IAM) と併用、または代替として使用できます。IAM の使用の詳細については、「[IAM ユーザーおよびロールに Kubernetes API へのアクセスを付与する](grant-k8s-access.md)」を参照してください。クラスターに認証を設定した後は、Kubernetes `roles` および `clusterroles` を作成しロールにアクセス許可を割り当て、さらに、このロールを Kubernetes `rolebindings` および`clusterrolebindings` を使用する ID にバインドできます。詳細についてはKubernetes ドキュメントの「[RBAC 認可を使用する](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)」を参照してください。
+ クラスターには OIDC ID プロバイダーを 1 つ関連付けることができます。
+ Kubernetes は OIDC ID プロバイダーを提供しません。既存のパブリック OIDC ID プロバイダーを使用することも、独自の ID プロバイダーを実行することもできます。認定プロバイダーのリストについては、OpenID サイトの「[OpenID Certification](https://openid.net/certification/)」(OpenID 認定) を参照してください。
+ Amazon EKS が署名キーを検出できるように、OIDC ID プロバイダーの発行者 URL は公的にアクセス可能である必要があります。Amazon EKS は、自己署名証明書を持つ OIDC ID プロバイダーをサポートしていません。
+ ノードをクラスターに結合する時に必要なため、クラスターへの IAM 認証を無効にすることはできません。
+ Amazon EKS クラスターは、OIDC ID プロバイダーユーザーではなく、AWS [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)が作成する必要があります。これは、クラスター作成者が Kubernetes API ではなく Amazon EKS API と対話するためです。
+ コントロールプレーンで CloudWatch ログが有効になっている場合、OIDC ID プロバイダー認証ユーザーは、クラスターの監査ログに一覧表示されます。詳細については、「[コントロールプレーンログを有効または無効にする](control-plane-logs.md#enabling-control-plane-log-export)」を参照してください。
+ OIDC プロバイダーのアカウントで AWS マネジメントコンソールにサインインすることはできません。AWS アイデンティティとアクセス管理 アカウントで AWS マネジメントコンソールにサインインした場合にのみ、[AWS マネジメントコンソール に Kubernetes リソースを表示する](view-kubernetes-resources.md) が可能となります。
## OIDC ID プロバイダーを関連付ける
OIDC ID プロバイダーをクラスターに関連付けるには、プロバイダーから以下の情報が必要です。
**発行者 URL**
API サーバーがトークン検証のために公開署名キーを検出できるようにする OIDC ID プロバイダーの URL。URL は `https://` で始まり、プロバイダーの OIDC ID トークンで `iss` クレームに対応している必要があります。OIDC 標準に従って、パスコンポーネントは許可されますが、クエリパラメータは許可されません。通常 URL は `https://server.example.org` または `https://example.com` のように、ホスト名のみで構成されます。この URL は以下 `.well-known/openid-configuration` のレベルを指し、インターネット経由で公的にアクセス可能である必要があります。
**クライアント ID (オーディエンスとも呼ばれる)**
OIDC ID プロバイダーに認証リクエストを行うクライアントアプリケーションの ID。
`eksctl` または AWS マネジメントコンソール を使用して、ID プロバイダーを関連付けることができます。
### eksctl を使用して ID プロバイダーを関連付ける
1. 次の内容で、`associate-identity-provider.yaml` という名前のファイルを作成します。値の例 は実際に使用する値に置き換えます。`identityProviders` セクションの値は、OIDC ID プロバイダーから取得します。値は`identityProviders` での `name`、`type`、`issuerUrl`、および `clientId` の設定のみで必要です。
```
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: your-region-code
identityProviders:
- name: my-provider
type: oidc
issuerUrl: https://example.com
clientId: kubernetes
usernameClaim: email
usernamePrefix: my-username-prefix
groupsClaim: my-claim
groupsPrefix: my-groups-prefix
requiredClaims:
string: string
tags:
env: dev
```
**重要**
`groupsPrefix` または `usernamePrefix` に対しては`system:` またはその文字列の一部でも指定しないでください。
1. プロバイダーを作成します。
```
eksctl associate identityprovider -f associate-identity-provider.yaml
```
1. `kubectl` を使用してクラスターと OIDC ID プロバイダーを操作する方法については、Kubernetes ドキュメントの「[kubectl の使用](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl)」を参照してください。
### AWS コンソールを使用して ID プロバイダーを関連付ける
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. クラスターを選択し、**[アクセス]** タブを選択してください。
1. **[OIDC ID プロバイダー]** セクションで、[ID プロバイダーを関連付け] を選択します。
1. **[Associate OIDC Identity Provider]** (OIDC ID プロバイダーの関連付け) ページで、以下のオプションを入力または選択した上で、**[Associate]** (関連付け) を選択します。
+ **[Name]** (名前) に、プロバイダーの一意の名前を入力します。
+ **[Issuer URL]** (発行者 URL） に、プロバイダーの URL を入力してください。この URL はインターネットからアクセス可能である必要があります。
+ **[クライアント ID]** に、OIDC ID プロバイダーのクライアント ID (別名、**対象者**) を入力します。
+ **[Username claim]** (ユーザー名のクレーム） に、ユーザー名として使用するクレームを入力してください。
+ **[Groups claim]** (グループクレーム) に、ユーザーのグループとして使用するクレームを入力します。
+ (オプション） **[Advanced options]** (詳細オプション） で、以下の情報を入力または選択してください。
+ **[Username prefix]** (ユーザー名のプレフィックス）– ユーザー名クレームの前に付加するプレフィックスを入力してください。プレフィックスは既存の名前との衝突を防ぐために、ユーザー名クレームの前に付加されます。値を入力せず、ユーザーネームが `email` 以外の場合、プレフィックスはデフォルトで **[Issuer URL]** (発行者 URL） の値になります。値に ` -` を使用すると、すべてのプレフィックスを無効にできます `system:` またはその文字列の一部でも指定しないでください。
+ **[Groups prefix]** (グループプレフィックス） – グループクレームの前に付加するプレフィックスを入力してください。プレフィックスは` system: groups` など既存の名前との衝突を防ぐために、グループクレームの前に付加されます。例えば、値 `oidc:` は`oidc:engineering` および `oidc:infra` などのグループ名を作成します。`system:` またはその文字列の一部でも指定しないでください。
+ **[Required claims]** (必要なクレーム） – **[Add claim]** (クレームを追加） 選択し、クライアント ID トークンに必要なクレームを記述する、キーと値のペアを 1 つ以上入力してください。ペアはID トークンで必要なクレームを記述します。設定されている場合、各クレームは一致する値を持つ ID トークンに存在することが検証されます。
1. `kubectl` を使用してクラスターと OIDC ID プロバイダーを操作する方法については、Kubernetes ドキュメントの「[kubectl の使用](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl)」を参照してください。
## IAM ポリシーの例
OIDC ID プロバイダーとクラスターの関連付けを防ぐには、以下の IAM ポリシーを作成して、Amazon EKS 管理者の IAM アカウントに関連付けます。詳細については、「*IAM ユーザーガイド*」の「[IAM ポリシーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」と「[IAM ID アクセス許可の追加](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console)」、および「サービス認証リファレンス」の「[Actions](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerserviceforkubernetes.html)」に関するページを参照してください。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "denyOIDC",
"Effect": "Deny",
"Action": [
"eks:AssociateIdentityProviderConfig"
],
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/*"
},
{
"Sid": "eksAdmin",
"Effect": "Allow",
"Action": [
"eks:*"
],
"Resource": "*"
}
]
}
```
以下のポリシーの例では、`clientID` が `kubernetes` で、`issuerUrl` が `https://cognito-idp.us-west-2amazonaws.com/*` の場合、OIDC ID プロバイダーの関連付けを許可します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCognitoOnly",
"Effect": "Deny",
"Action": "eks:AssociateIdentityProviderConfig",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-instance",
"Condition": {
"StringNotLikeIfExists": {
"eks:issuerUrl": "https://cognito-idp.us-west-2.amazonaws.com/*"
}
}
},
{
"Sid": "DenyOtherClients",
"Effect": "Deny",
"Action": "eks:AssociateIdentityProviderConfig",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-instance",
"Condition": {
"StringNotEquals": {
"eks:clientId": "kubernetes"
}
}
},
{
"Sid": "AllowOthers",
"Effect": "Allow",
"Action": "eks:*",
"Resource": "*"
}
]
}
```
# OIDC ID プロバイダーとクラスターの関連付けを解除します。
OIDC ID プロバイダーとクラスターの関連付けを解除する場合、プロバイダーに含まれるユーザーはクラスターにアクセスできなくなります。ただし、[IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)を使用して、クラスターへ引き続きアクセスすることは可能です。
1. [アマゾン EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. **[OIDC Identity Providers]** (OIDC ID プロバイダー) セクションで、**[Disassociate]** (関連付けの解除) を選択しID プロバイダー名を入力した上で、[`Disassociate`] を選択します。
# AWS マネジメントコンソール に Kubernetes リソースを表示する
クラスターにデプロイされた Kubernetes リソースを AWS マネジメントコンソール で表示できます。Kubernetes リソースは、AWS CLIまたは [eksctl](https://eksctl.io/) で表示することはできません。コマンドラインツールを使用して Kubernetes リソースを表示するには、[kubectl](install-kubectl.md) を使用します。
**注記**
AWS マネジメントコンソール の **[リソース]** タブと **[コンピューティング]** タブの **[ノード]** セクションを表示するには、使用している [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)に特定の IAM と Kubernetes 許可が必要です。詳細については、「[必要なアクセス許可](#view-kubernetes-resources-permissions)」を参照してください。
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. **[Clusters]** (クラスター) のリストで、表示したい Kubernetes リソースを含んでいるクラスターを選択します。
1. **[リソース]** タブを選択します。
1. リソースを表示したい **[リソースタイプ]** グループを選択します。例えば、**[ワークロード]** などです。そのグループ内のリソースタイプのリストが表示されます。
1. リソースタイプを選択します。例えば、**[Workloads]** (ワークロード) グループ内の **[Deployments]** (デプロイメント) などです。リソースタイプの簡単な説明、リソースタイプの詳細な説明が参照できる Kubernetes ドキュメントへのリンク、およびクラスターにデプロイされていてそのタイプに分類されるリソースのリストが表示されます。リストが空の場合、そのタイプのリソースはクラスターにデプロイされていません。
1. 詳細情報を表示するには、そのリソースを選択します。次の例を試してください。
+ **[ワークロード]** グループを選択し、**[デプロイメント]** のリソースタイプを選択し、次に **[CoreDNS]** リソースを選択します。リソースを選択すると、デフォルトで **[構造化ビュー]** が表示されます。リソースタイプによっては、**[構造化ビュー]** に **[ポッド]** セクションが表示されます。このセクションでは、ワークロードによって管理される Pod が一覧表示されます。一覧表示されている任意の Pod を選択し、Pod の情報を表示できます。すべてのリソースタイプについて、**[Structured View]** (構造化ビュー) で情報が表示されるわけではありません。リソース表示画面で右上隅にある **[Raw view]** (raw ビュー) を選択すると、そのリソースについて Kubernetes API からの完全な JSON レスポンスが表示されます。
+ **[Cluster]** (クラスター) グループを選択してから、**[Nodes]** (ノード) リソースタイプを選択します。クラスター内のすべてのノードのリストが表示されます。ノードは、任意の [Amazon EKS ノードタイプ](eks-compute.md)となります。これはクラスターの **[コンピューティング]** () タブを選択したときに **[ノード]** セクションに表示されるのと同じリストです。リストからノードリソースを選択します。**[構造化ビュー]** では、**[ポッド]** セクションも表示されます。このセクションでは、ノード上で実行中のすべての Pod が表示されます。
## 必要なアクセス許可
AWS マネジメントコンソール の **[リソース]** タブと **[コンピューティング]** タブの **[ノード]** セクションを表示するには、使用している [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)に特定の最小限の IAM と Kubernetes 許可が必要です。IAM と Kubernetes の両方の RBAC アクセス許可を正しく設定する必要があります。次のステップを実行して、IAM プリンシパルに必要な許可を割り当てます。
1. `eks:AccessKubernetesApi`、および Kubernete リソースを表示するために必要なその他の IAM アクセス許可が、使用している IAM プリンシパルに割り当てられていることを確認してください。IAM プリンシパルの許可を編集する方法の詳細については、「IAM ユーザーガイド」の「[プリンシパルへのアクセスの制御](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html#access_controlling-principals)」を参照してください。ロールのアクセス許可を編集する方法の詳細については、IAM ユーザーガイドの「[ロールのアクセス許可ポリシーの変更 (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html#roles-modify_permissions-policy)」を参照してください。
次のポリシーの例には、アカウント内のすべてのクラスター内にある Kubernetes リソースを表示するために必要な、プリンシパルへの許可が含まれています。*111122223333* を自分の AWS アカウント ID に置き換えます。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:ListFargateProfiles",
"eks:DescribeNodegroup",
"eks:ListNodegroups",
"eks:ListUpdates",
"eks:AccessKubernetesApi",
"eks:ListAddons",
"eks:DescribeCluster",
"eks:DescribeAddonVersions",
"eks:ListClusters",
"eks:ListIdentityProviderConfigs",
"iam:ListRoles"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ssm:GetParameter",
"Resource": "arn:aws:ssm:*:111122223333:parameter/*"
}
]
}
```
[接続されたクラスター](eks-connector.md)内のノードを表示するには、[Amazon EKS コネクタの IAM ロール](connector-iam-role.md)がクラスター内のプリンシパルを偽装できる必要があります。これにより、[Amazon EKS Connector](eks-connector.md) はプリンシパルを Kubernetes ユーザーにマッピングできます。
1. EKS アクセスエントリを使用して Kubernetes RBAC アクセス許可を設定します。
**EKS アクセスエントリとは**
EKS アクセスエントリは、IAM プリンシパル (ユーザーとロール) に Kubernetes クラスターへのアクセス許可を付与する効率的な方法です。アクセスエントリを使用することで、Kubernetes RBAC リソースや `aws-auth` ConfigMap を手動で管理する代わりに、AWS が提供するマネージドポリシーを使用して IAM と Kubernetes アクセス許可間のマッピングを自動的に処理することができます。アクセスエントリの詳細情報については「[EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する](access-entries.md)」を参照してください。利用可能なアクセスポリシーとそのアクセス許可の詳細については、「[アクセスポリシーアクセス許可を確認する](https://docs.aws.amazon.com/eks/latest/userguide/access-policy-permissions.html)」を参照してください。
Kubernetes アクセス許可をアタッチして、次の 2 つの方法でエントリにアクセスできます：
+ **アクセスポリシーを使用する:** アクセスポリシーは、AWS によって管理される事前定義された Kubernetes アクセス許可テンプレートです。これらは、一般的なユースケース用の標準化されたアクセス許可セットを提供します。
+ **Kubernetes グループを参照する:** IAM アイデンティティを Kubernetes グループに関連付けると、グループのアクセス許可を付与する Kubernetes リソースを作成できます。詳細についてはKubernetes ドキュメントの「[RBAC 認可を使用する](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)」を参照してください。
1. AWS CLI を使用して IAM プリンシパルのアクセスエントリを作成します。*マイクラスター* の部分は自分のクラスター名に置き換えます。*111122223333* は、ご自分のアカウント ID に置き換えます。
```
aws eks create-access-entry \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role
```
出力例は次のとおりです。
```
{
"accessEntry": {
"clusterName": "my-cluster",
"principalArn": "arn:aws:iam::111122223333:role/my-console-viewer-role",
"kubernetesGroups": [],
"accessEntryArn": "arn:aws:eks:region-code:111122223333:access-entry/my-cluster/role/111122223333/my-console-viewer-role/abc12345-1234-1234-1234-123456789012",
"createdAt": "2024-03-15T10:30:45.123000-07:00",
"modifiedAt": "2024-03-15T10:30:45.123000-07:00",
"tags": {},
"username": "arn:aws:iam::111122223333:role/my-console-viewer-role",
"type": "STANDARD"
}
}
```
1. ポリシーをアクセスエントリに関連付けます。Kubernetes リソースを表示するには、`AmazonEKSViewPolicy` を使用します。
```
aws eks associate-access-policy \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
--access-scope type=cluster
```
出力例は次のとおりです。
```
{
"clusterName": "my-cluster",
"principalArn": "arn:aws:iam::111122223333:role/my-console-viewer-role",
"associatedAt": "2024-03-15T10:31:15.456000-07:00"
}
```
名前空間固有のアクセスでは、ポリシー範囲を特定の名前空間に限定できます。
```
aws eks associate-access-policy \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
--access-scope type=namespace,namespaces=default,kube-system
```
1. アクセスエントリが正常に作成されたことを確認します。
```
aws eks describe-access-entry \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role
```
1. 関連付けられたポリシーを一覧表示して、ポリシーの関連付けを確認します。
```
aws eks list-associated-access-policies \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role
```
出力例は次のとおりです。
```
{
"associatedAccessPolicies": [
{
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
"accessScope": {
"type": "cluster"
},
"associatedAt": "2024-03-15T10:31:15.456000-07:00",
"modifiedAt": "2024-03-15T10:31:15.456000-07:00"
}
]
}
```
## CloudTrail の可視性
Kubernetes リソースを表示すると、CloudTrail ログに次のオペレーション名が表示されます。
+ `AccessKubernetesApi` – リソースの読み取りまたは表示時
この CloudTrail イベントは、Kubernetes リソースへの読み取りアクセスの監査証跡を提供します。
**注記**
このオペレーション名は、監査目的でのみ CloudTrail ログに表示されます。これは IAM アクションではなく、IAM ポリシーステートメントでは使用できません。IAM ポリシーを使用して Kubernetes リソースへの読み取りアクセスを制御するには、「[必要なアクセス許可](#view-kubernetes-resources-permissions)」セクションに示すように `eks:AccessKubernetesApi` アクセス許可を使用します。
# Kubernetes API への書き込みアクセスを AWS サービスに付与する
## 必要なアクセス許可
AWS サービスが Amazon EKS クラスター内の Kubernetes リソースに対して書き込みオペレーションを実行できるようにするには、`eks:AccessKubernetesApi` と `eks:MutateViaKubernetesApi` の両方の IAM アクセス許可を付与する必要があります。
例えば、Amazon SageMaker HyperPod はこれらのアクセス許可を使用して、SageMaker AI Studio からのモデルデプロイを有効にします。詳細については、Amazon SageMaker AI デベロッパーガイドの「[Set up optional JavaScript SDK permissions](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-model-deployment-setup.html#sagemaker-hyperpod-model-deployment-setup-optional-js)」を参照してください。
**重要**
作成、更新、削除などの書き込みオペレーションには両方のアクセス許可が必要です。いずれかのアクセス許可がない場合、書き込みオペレーションは失敗します。
## CloudTrail の可視性
Kubernetes リソースに対して書き込みオペレーションを実行すると、CloudTrail ログに特定のオペレーション名が表示されます。
+ `createKubernetesObject` – 新しいリソースを作成する場合
+ `updateKubernetesObject` – 既存のリソースを変更する場合
+ `deleteKubernetesObject` – リソースを削除する場合
これらの CloudTrail イベントは、Kubernetes リソースに加えられたすべての変更の詳細な監査証跡を提供します。
**注記**
これらのオペレーション名は、監査目的でのみ CloudTrail ログに表示されます。これらは IAM アクションではなく、IAM ポリシーステートメントでは使用できません。IAM ポリシーを使用して Kubernetes リソースへの書き込みアクセスを制御するには、「[必要なアクセス許可](#mutate-kubernetes-resources-permissions)」セクションに示すように `eks:MutateViaKubernetesApi` アクセス許可を使用します。
# kubeconfig ファイルを作成して kubectl を EKS クラスターに接続する
**ヒント**
今後開催予定の Amazon EKS ワークショップに[登録](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)してください。
このトピックでは、クラスター用の `kubeconfig` ファイルを作成します (または既存のファイルを更新します)。
`kubectl` コマンドラインツールは、`kubeconfig` ファイルの設定情報を使用して、クラスターの API サーバーと通信します。詳細については、Kubernetes ドキュメントの「[kubeconfig ファイルを使用してクラスターアクセスを組織する](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)」を参照してください。
Amazon EKS はクラスター認証に `kubectl` で `aws eks get-token` コマンドを使用します。デフォルトでは、AWS CLI は次のコマンドで返されるものと同じ認証情報を使用します。
```
aws sts get-caller-identity
```
+ 既存の Amazon EKS クラスター。デプロイするには「[Amazon EKS の使用を開始する](getting-started.md)」を参照してください。
+ デバイスまたは AWS クラウドシェル に、`kubectl` コマンドラインツールがインストールされていること。バージョンはご使用のクラスターの Kubernetes バージョンと同じか、1 つ前のマイナーバージョン以前、あるいはそれより新しいバージョンが使用できます。例えば、クラスターのバージョンが `1.29` である場合、`kubectl` のバージョン `1.28`、`1.29`、または `1.30` が使用できます。`kubectl` をインストールまたはアップグレードする方法については「[`kubectl` および `eksctl` のセットアップ](install-kubectl.md)」を参照してください。
+ ご使用のデバイスまたは AWS クラウドシェル で、バージョン `2.12.3` 以降、または AWS コマンドラインインターフェイス (AWS CLI のバージョン `1.27.160` 以降がインストールおよび設定されていること。現在のバージョンを確認するには「`aws --version | cut -d / -f2 | cut -d ' ' -f1`」を参照してください。`yum`、`apt-get`、macOS 用の Homebrew などのパッケージマネージャーは、多くの場合 AWS CLI の最新バージョンより数バージョン古くなっています。最新バージョンをインストールするには「*AWS コマンドラインインターフェイスユーザーガイド*」の「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」および「[aws configure を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。AWS クラウドシェル にインストールされている AWS CLI バージョンも最新バージョンより数バージョン遅れることがあります。更新するには、*「AWS CloudShell ユーザーガイド*」の「[ホームディレクトリへの AWS CLI のインストール](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)」を参照してください。
+ 指定したクラスターに対して `eks:DescribeCluster` API アクションを使用するアクセス許可を持つ IAM ユーザーまたはロール。詳細については、「[Amazon EKS でのアイデンティティベースのポリシーの例](security-iam-id-based-policy-examples.md)」を参照してください。独自の OpenID Connect プロバイダーの ID を使用してクラスターにアクセスする場合は、Kubernetes ドキュメントの「[kubectl の使用](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl)」を参照して、`kube config` ファイルを作成または更新してください。
## `kubeconfig` ファイルを自動で作成する
+ ご使用のデバイスまたは AWS CloudShell で、バージョン `2.12.3` 以降、または AWS コマンドラインインターフェイス (AWS CLI) のバージョン `1.27.160` 以降がインストールおよび設定されていること。現在のバージョンを確認するには「`aws --version | cut -d / -f2 | cut -d ' ' -f1`」を参照してください。`yum`、`apt-get`、macOS 用の Homebrew などのパッケージマネージャーは、多くの場合 AWS CLI の最新バージョンより数バージョン古くなっています。最新バージョンをインストールするには「*AWS コマンドラインインターフェイスユーザーガイド*」の「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」および「[aws configure を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。AWS クラウドシェル にインストールされている AWS CLI バージョンも最新バージョンより数バージョン遅れることがあります。更新するには、*「AWS CloudShell ユーザーガイド*」の「[ホームディレクトリへの AWS CLI のインストール](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)」を参照してください。
+ 指定したクラスターに対して `eks:DescribeCluster` API アクションを使用するアクセス許可。詳細については、「[Amazon EKS でのアイデンティティベースのポリシーの例](security-iam-id-based-policy-examples.md)」を参照してください。
1. クラスター用の `kubeconfig` ファイルを作成もしくは更新します。*region-code* はクラスターがある AWS リージョンに、*my-cluster* はクラスターの名前に置き換えます。
```
aws eks update-kubeconfig --region region-code --name my-cluster
```
デフォルトでは、最終的な設定ファイルは、ホームディレクトリのデフォルト `kubeconfig` パス (`.kube`) に作成されるか、その場所で既存 `config` ファイルとマージされます。別のパスは `--kubeconfig` オプションを使用して指定できます。
`kubectl` コマンドを発行する場合、認証に使用する `--role-arn` オプションで IAM ロール ARN を指定できます。それ以外の場合は、デフォルトの AWS CLI または SDK の認証情報チェーンの中の [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)が使用されます。デフォルトの AWS CLI または SDK の ID を表示するには、 `aws sts get-caller-identity` コマンドを実行します。
使用可能なすべてのオプションについては、`aws eks update-kubeconfig help` コマンドを実行するか、*「AWS CLI コマンドリファレンス*」の「[update-kubeconfig](https://docs.aws.amazon.com/cli/latest/reference/eks/update-kubeconfig.html)」を参照してください。
1. 設定をテストします。
```
kubectl get svc
```
出力例は次のとおりです。
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc/kubernetes ClusterIP 10.100.0.1 443/TCP 1m
```
認可またはリソースタイプのエラーが発生した場合はトラブルシューティングトピックの「[許可されていないか、アクセスが拒否されました (`kubectl`)](troubleshooting.md#unauthorized)」を参照してください。
# Kubernetes ワークロードに Kubernetes サービスアカウントを使用して AWS へのアクセスを許可する
[サービスアカウントの管理](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin)[サービスアカウントの IAM ロール](iam-roles-for-service-accounts.md)[EKS Pod Identity が Pod に AWS サービスへのアクセス権を付与する仕組みを学ぶ](pod-identities.md)
## サービスアカウントトークン
[BoundServiceAccountTokenVolume](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume) 機能は、Kubernetes バージョンでデフォルトで有効になっています。この機能により、Kubernetes で実行されているワークロードは、対象者、時間、および鍵に紐付けされた JSON ウェブトークンをリクエストできるようになり、サービスアカウントトークンのセキュリティが向上します。サービスアカウントトークンの有効期限は 1 時間です。Kubernetes の以前のバージョンでは、トークンに有効期限はありませんでした。つまり、これらのトークンに依存するクライアントは 1 時間以内にトークンを更新する必要があります。以下の [Kubernetes クライアント SDK](https://kubernetes.io/docs/reference/using-api/client-libraries/) は、必要な期間内にトークンを自動的に更新します。
+ Go バージョン `0.15.7` 以降
+ Python バージョン `12.0.0` 以降
+ Java バージョン `9.0.0` 以降
+ JavaScript バージョン `0.10.3` 以降
+ Ruby `master` ブランチ
+ Haskell バージョン`0.3.0.0`
+ C\$1 バージョン `7.0.5` 以降
ワークロードで古いバージョンのクライアントを使用している場合は、更新する必要があります。有効期限付きの新しいサービスアカウントトークンにクライアントがスムーズに移行できるようにするため、Kubernetes ではデフォルトの 1 時間を超えてサービスアカウントトークンの有効期限が延長されます。Amazon EKS クラスターの場合、延長できる有効期限は 90 日です。Amazon EKS クラスターの Kubernetes API サーバーでは、90 日を超えるトークンのリクエストは拒否されます。アプリケーションとその依存関係を確認し、Kubernetes クライアント SDK が前記のバージョンと同じかそれ以降であることを確認することをお勧めします。
API サーバーが 1 時間を超える古いトークンによるリクエストを受信すると、API 監査ログイベントに `annotations.authentication.k8s.io/stale-token` で注釈を付けます。注釈の値は次の例のようになります。
```
subject: system:serviceaccount:common:fluent-bit, seconds after warning threshold: 4185802.
```
クラスターで[コントロールプレーンのログ記録](control-plane-logs.md)が有効になっている場合、注釈は監査ログに記録されます。以下の [CloudWatch Log Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) クエリを使用すると、Amazon EKS クラスター内で古いトークンを使っているすべての Pod を特定できます。
```
fields @timestamp
|filter @logStream like /kube-apiserver-audit/
|filter @message like /seconds after warning threshold/
|parse @message "subject: *, seconds after warning threshold:*\"" as subject, elapsedtime
```
`subject` は、Pod が使用したサービスアカウントを示します。`elapsedtime` は、最新のトークンを読み込んでからの経過時間 (秒単位) を示します。`elapsedtime` が 90 日 (7,776,000 秒間) を超えると、API サーバーへのリクエストは拒否されます。トークンの自動更新を行う前記のバージョンのいずれかを使用するよう、アプリケーションの Kubernetes クライアント SDK をプロアクティブに更新する必要があります。使用しているサービスアカウントトークンが 90 日に近く、トークンの有効期限が切れるまでクライアント SDK のバージョンを更新するのに十分な時間がない場合、既存の Pod を終了して新しい Pod を作成できます。サービスアカウントトークンが再フェッチされるので、クライアントバージョン SDK を更新するのに 90 日が追加されたことになります。
Pod がデプロイの一部である場合、高可用性を維持しながら Pod を終了する方法として、次のコマンドによるロールアウトの実行をお勧めします。*my-deployment* をデプロイの名前で置き換えます。
```
kubectl rollout restart deployment/my-deployment
```
## クラスターアドオン
以下のクラスターアドオンが更新され、サービスアカウントトークンを自動的に再フェッチする Kubernetes クライアント SDK が使用できるようになりました。リストされているバージョン、またはそれ以降のバージョンを、 クラスターにインストールすることをお勧めします。
+ Amazon VPC CNI Plugin for Kubernetes およびメトリクスヘルパーのプラグインのバージョン `1.8.0` 以降。現在のバージョンを確認したり、更新したりするには、「[Amazon VPC CNI を使用して Pod に IP を割り当てる](managing-vpc-cni.md)」および「[cni-metrics-helper](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/cmd/cni-metrics-helper/README.md)」を参照してください。
+ CoreDNS のバージョン `1.8.4` 以降。現在のバージョンを確認したり、更新したりするには、「[Amazon EKS クラスターで DNS の CoreDNS を管理する](managing-coredns.md)」を参照してください。
+ AWS Load Balancer Controller のバージョン `2.0.0` 以降。現在のバージョンを確認したり、更新したりするには、「[AWS Load Balancer Controller を使用してインターネットトラフィックをルーティングする](aws-load-balancer-controller.md)」を参照してください。
+ 現在の `kube-proxy` バージョン 現在のバージョンを確認したり、更新したりするには、「[Amazon EKS クラスターで `kube-proxy` を管理する](managing-kube-proxy.md)」を参照してください。
+ AWS for Fluent Bit バージョン `2.25.0` 以降。現在のバージョンを更新するには、GitHub で「[Releases](https://github.com/aws/aws-for-fluent-bit/releases)」(リリース) を参照してください。
+ Fluentd イメージバージョン [1.14.6-1.2](https://hub.docker.com/r/fluent/fluentd/tags?page=1&name=v1.14.6-1.2) 以降、および Kubernetes メタデータバージョン [2.11.1](https://rubygems.org/gems/fluent-plugin-kubernetes_metadata_filter/versions/2.11.1) 以降用の Fluentd フィルタープラグイン。
## Amazon Elastic Kubernetes Service クラスター上のワークロードへの AWS Identity and Access Management 許可の付与
Amazon EKS には、Amazon EKS クラスターで実行されるワークロードに AWS Identity and Access Management 許可を付与する方法が 2 つあります。サービスアカウント用の IAM ロールと EKS Pod Identity です。
**サービスアカウントの IAM ロール**
サービスアカウント用の IAM ロール (IRSA) は、Amazon S3 バケットや Amazon DynamoDB テーブルなど、他の様々な AWS リソースにアクセスするためのきめ細かい IAM アクセス許可で AWS 上で動作する Kubernetes アプリケーションを構成します。同じ Amazon EKS クラスター内で複数のアプリケーションを同時に実行し、各アプリケーションに必要な最小限のアクセス権限のみを持たせることができます。IRSA は、Amazon EKS、Amazon EKS Anywhere、AWS での Red Hat OpenShift サービス、Amazon EC2 インスタンスでのセルフマネージド型 Kubernetes クラスターなどの、AWS でサポートされるさまざまな Kubernetes デプロイオプションをサポートするように構築されました。そのため、IRSA は IAM のような基本的な AWS サービスを使用して構築されており、Amazon EKS サービスや EKS API に直接依存することはありませんでした。詳細については、「[サービスアカウントの IAM ロール](iam-roles-for-service-accounts.md)」を参照してください。
**EKS Pod Identity**
EKS Pod Identity は、Amazon S3 バケット、Amazon DynamoDB テーブルなどのさまざまな AWS リソースにアクセスするためのアプリケーションを認証するためのシンプルなワークフローをクラスター管理者に提供します。EKS Pod Identity は EKS 専用であるため、クラスター管理者が Kubernetes アプリケーションを設定して IAM アクセス許可を取得する方法が簡単になります。これらの権限は、AWS マネジメントコンソール、EKS API、および AWS CLI から直接行う、より少ない手順で簡単に設定できるようになり、クラスター内のどの Kubernetes オブジェクトに対しても実行する必要がありません。クラスター管理者は EKS サービスと IAM サービスを切り替えたり、特権的な IAM オペレーションを使用してアプリケーションに必要な権限を設定したりする必要がありません。新しいクラスターを作成するときにロールの信頼ポリシーを更新しなくても、IAM ロールを複数のクラスターで使用できるようになりました。EKS Pod Identity が提供する IAM 認証情報には、クラスター名、名前空間、サービスアカウント名などの属性を含むロールセッションタグが含まれます。ロールセッションタグを使用すると、管理者は一致するタグに基づいて AWS リソースへのアクセスを許可することで、複数のサービスアカウントで機能する単一のロールを作成できます。詳細については、「[EKS Pod Identity が Pod に AWS サービスへのアクセス権を付与する仕組みを学ぶ](pod-identities.md)」を参照してください。
### EKS Pod Identity と IRSA の比較
大まかに言うと、EKS Pod Identity と IRSA はどちらも、Kubernetes クラスター上で実行されているアプリケーションに IAM アクセス許可を付与できるようにします。ただし、設定方法、サポートされる制限、有効になる機能は根本的に異なります。以下では、両ソリューションの重要な側面をいくつか比較します。
**注記**
AWS では、可能な限り EKS Pod Identity を使用して AWS リソースへのアクセスをポッドに許可することをお勧めします。詳細については、「[EKS Pod Identity が Pod に AWS サービスへのアクセス権を付与する仕組みを学ぶ](pod-identities.md)」を参照してください。
| 属性 | EKS Pod Identity | IRSA |
| --- | --- | --- |
| ロール拡張性 | 新しく導入された Amazon EKS サービスプリンシパル `pods.eks.amazonaws.com` との信頼を確立するには、各ロールを一度設定する必要があります。この 1 回限りのステップを済ませると、そのロールを新しいクラスターで使用するたびにそのロールの信頼ポリシーを更新する必要がなくなります。 | 新しいクラスターでロールを使用するたびに、IAM ロールの信頼ポリシーを新しい EKS クラスター OIDC プロバイダーエンドポイントで更新する必要があります。 |
| クラスタのスケーラビリティ | EKS Pod Identity では、ユーザーが IAM OIDC プロバイダーをセットアップする必要がないため、この制限は適用されません。 | 各 EKS クラスターには、OpenID Connect (OIDC) 発行者の URL が関連付けられています。IRSA を使用するには、IAM の EKS クラスターごとに固有の OpenID Connect プロバイダーを作成する必要があります。IAM のデフォルトのグローバル制限は、AWS アカウントにつき 100 の OIDC プロバイダーです。IRSA で AWS アカウントにつき 100 を超える EKS クラスターを使用する予定の場合は、IAM OIDC プロバイダーの制限に達します。 |
| ロールのスケーラビリティ | EKS Pod Identity では、ユーザーが信頼ポリシーで IAM ロールとサービスアカウント間の信頼関係を定義する必要がないため、この制限は適用されません。 | IRSA では、IAM ロールとサービスアカウント間の信頼関係を、ロールの信頼ポリシーで定義します。デフォルトでは、信頼ポリシーの長さは `2048` です。つまり、通常、1 つの信頼ポリシーで 4 つの信頼関係を定義できます。信頼ポリシーの長さの上限を増やすことはできますが、通常、1 つの信頼ポリシー内で作成できる信頼関係は最大 8 つに制限されます。 |
| STS API クォータの使用 | EKS Pod Identity は、ポッドへの AWS 認証情報の配信を簡素化し、AWS Security Token Service (STS) でコードを直接呼び出す必要はありません。EKS サービスはロールの引き受けを処理し、ポッドが AWS STS と通信したり STS API Quota を使用したりすることなく、ポッド内の AWS SDK を使用して記述されたアプリケーションに認証情報を配信します。 | IRSA では、ポッドの AWS SDK を使用して記述されたアプリケーションは、トークンを使用して AWS Security Token Service (STS) で `AssumeRoleWithWebIdentity` API を呼び出します。AWS SDK 上のコードのロジックによっては、コードが AWS STS への不必要な呼び出しを行い、スロットリングエラーを受信する可能性があります。 |
| ロールの再利用性 | EKS Pod Identity によって提供される一時的な AWS STS 認証情報には、クラスター名、名前空間、サービスアカウント名などのロールセッションタグが含まれます。ロールセッションタグを使用すると、管理者は、アタッチされたタグに基づいて AWS リソースへのアクセスを許可することで、複数のサービスアカウントで使用できる単一の IAM ロールを作成し、そのロールを有効な権限を変えることができます。これは、属性ベースのアクセス制御 (ABAC) とも呼ばれます。詳細については、「[タグに基づいてポッドに AWS リソースへのアクセス権を付与する](pod-id-abac.md)」を参照してください。 | AWS STS セッションタグはサポートされていません。ロールはクラスタ間で再利用できますが、すべてのポッドにそのロールのすべての権限が付与されます。 |
| サポートされている環境 | EKS Pod Identity は Amazon EKS でのみ使用できます。 | IRSA は、Amazon EKS、Amazon EKS Anywhere、AWS での Red Hat OpenShift サービス、Amazon EC2 インスタンスでのセルフマネージド型 Kubernetes クラスターなどに使用できます。 |
| サポートされている EKS バージョン | サポート対象のすべての EKS クラスターバージョン。特定のバージョンについては、「[EKS Pod Identity クラスターバージョン](pod-identities.md#pod-id-cluster-versions)」を参照してください。 | サポート対象のすべての EKS クラスターバージョン。 |
# サービスアカウントの IAM ロール
**ヒント**
今後開催予定の Amazon EKS ワークショップに[登録](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)してください。
ポッドのコンテナ内のアプリケーションは AWS SDK または AWS CLI で、AWS Identity and Access Management (IAM) アクセス許可を使用した AWS サービスへの API リクエストを行うことができます。アプリケーションは AWS 認証情報で AWS API リクエストに署名する必要があります。**サービスアカウントの IAM ロール (IRSA)** には、Amazon EC2 インスタンスプロファイルから Amazon EC2 インスタンスに認証情報を提供する場合と同じような方法で、アプリケーションの認証情報を管理する機能があります。AWS 認証情報を作成してコンテナに配布したり、Amazon EC2 インスタンスのロールを使用したりする必要はありません。IAM ロールを Kubernetes サービスアカウントと関連付けて、サービスアカウントを使用するように Pod を設定できます。[AWS Outposts の Amazon EKS 用ローカルクラスター](eks-outposts-local-cluster-overview.md)で、サービスアカウントに IAM ロールを使用することはできません。
サービスアカウントの IAM ロールには、次の利点があります。
+ **最小特権** – IAM アクセス許可の範囲をサービスアカウントに設定すると、そのサービスアカウントを使用する Pod にのみそのアクセス許可を付与できます。また、この機能により、`kiam` や `kube2iam` などのサードパーティーのソリューションが不要になります。
+ **認証情報の分離** – [Amazon EC2 インスタンスメタデータサービス (IMDS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) へのアクセスが制限されている場合、ポッド内のコンテナは、そのコンテナが使用するサービスアカウントに関連付けられている IAM ロールの認証情報のみを取得できます。コンテナは、他の Pod 内のコンテナで使われている認証情報にアクセスすることはできません。IMDS が制限されていない場合、ポッドのコンテナは「[Amazon EKS ノード IAM ロール](create-node-role.md)」にもアクセスでき、コンテナは同じノード上にある他のポッドの IAM ロールの認証情報にアクセスできる可能性があります。詳細については「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html#_identities_and_credentials_for_eks_pods_recommendations)」を参照してください。
**注記**
`hostNetwork: true` で設定されたポッドは常に IMDS アクセスできますが、AWS SDK および CLI は有効にすると IRSA 認証情報が使用されます。
+ **監査性** – AWS CloudTrail にアクセスしイベントのログ記録を利用することで、遡及的な監査を確実に行えます。
**重要**
コンテナはセキュリティ境界ではなく、サービスアカウントに IAM ロールを使用してもこの点は変更されません。同じノードに割り当てられたポッドはカーネルを共有し、ポッド設定によっては他のリソースも共有される可能性があります。別々のノードで実行されているポッドはコンピューティングレイヤーで分離されますが、Kubernetes API に対し個別のインスタンスの範囲を超えて追加のアクセス許可を持つノードアプリケーションがあります。例としては `kubelet`、`kube-proxy`、CSI ストレージドライバー、ユーザー独自の Kubernetes アプリケーションなどがあります。
以下の手順を実行してサービスアカウントの IAM ロールを有効にします。
1. [クラスターの IAM OIDC プロバイダーを作成する](enable-iam-roles-for-service-accounts.md) – この手順は、クラスターごとに 1 回だけ実行する必要があります。
**注記**
EKS VPC エンドポイントを有効にすると、その VPC 内から EKS OIDC サービスエンドポイントにアクセスできなくなります。そのため、VPC で `eksctl` を使用して OIDC プロバイダーを作成するなどの操作は機能せず、`https://oidc.eks.region.amazonaws.com` をリクエストしようとするとタイムアウトになります。エラーメッセージの例は次のとおりです。
```
server cant find oidc.eks.region.amazonaws.com: NXDOMAIN
```
このステップを完了するには、VPC の外部、たとえばインターネットに接続された AWS CloudShell 内またはコンピューター上でコマンドを実行します。または、Route 53 Resolver などのスプリットホライズン条件付きリゾルバーを VPC に作成して、OIDC 発行者 URL のために別のリゾルバーを使用し、VPC DNS は使用しないようにすることもできます。CoreDNS での条件付き転送の例については、GitHub の「[Amazon EKS feature request](https://github.com/aws/containers-roadmap/issues/2038)」を参照してください。
1. [Kubernetes サービスアカウントに IAM ロールを割り当てる](associate-service-account-role.md) - この手順は、アプリケーションに付与する固有のアクセス許可のセットごとに実行します。
1. [Kubernetes サービスアカウントを使用するように Pod を設定する](pod-configuration.md) – この手順は、AWS サービスへのアクセスを必要とする Pod ごとに実行します。
1. [AWS SDK で IRSA を使用する](iam-roles-for-service-accounts-minimum-sdk.md) – ワークロードがサポートされているバージョンの AWS SDK を使用していること、およびワークロードがデフォルトの認証情報チェーンを使用していることを確認します。
## IAM、Kubernetes、OpenID Connect (OIDC) の背景情報
2014 年に、OpenID Connect (OIDC) を使用したフェデレーティッドアイデンティティのサポートが、AWS Identity and Access Management に追加されました。この機能により、サポートされている ID プロバイダーで AWS API コールを認証し、有効な OIDC JSON ウェブトークン (JWT) を受け取ることができます。このトークンを AWS STS の `AssumeRoleWithWebIdentity` API オペレーションに渡し、一時的な IAM ロールの認証情報を受け取ることができます。これらの認証情報を使用して、Amazon S3 や DynamoDB などの任意の AWS サービスとやり取りできます。
各 JWT トークンは署名キーペアによって署名されます。キーは Amazon EKS が管理する OIDC プロバイダーで提供され、プライベートキーは 7 日ごとにローテーションされます。Amazon EKS はパブリックキーの有効期限が切れるまで保持します。外部 OIDC クライアントに接続する場合は、パブリックキーが期限切れになる前に、キーを更新する必要があることに注意してください。[署名キーを取得して OIDC トークンを検証する](irsa-fetch-keys.md)方法について説明します。
Kubernetes は、独自の内部 ID システムとして長い間、サービスアカウントを使用してきました。ポッドは、Kubernetes API サーバーのみが検証できる自動マウントトークン（OIDC JWT ではない）を使用して Kubernetes API サーバーで認証できます。これらのレガシーサービスアカウントトークンは期限切れにならず、署名キーの更新は難しいプロセスです。Kubernetes バージョン `1.12` では、新しい `ProjectedServiceAccountToken` 機能のサポートが追加されました。この機能は、サービスアカウントアイデンティティを含む OIDC JSON ウェブトークンで、設定可能なオーディエンスをサポートします。
Amazon EKS は、`ProjectedServiceAccountToken` JSON ウェブトークンの署名キーを含むクラスターごとにパブリック OIDC 検出エンドポイントをホストするため、IAM などの外部システムで、Kubernetes によって発行された OIDC トークンを検証して受け入れることができます。
# クラスターの IAM OIDC プロバイダーを作成するには
クラスターには、[OpenID Connect](https://openid.net/connect/) (OIDC) 発行者の URL が関連付けられています。サービスアカウントで AWS Identity and Access Management (IAM) ロールを使用するには、クラスターの OIDC 発行者 URL に対して IAM OIDC プロバイダーが存在している必要があります。
## 前提条件
+ 既存の Amazon EKS クラスター。デプロイするには「[Amazon EKS の使用を開始する](getting-started.md)」を参照してください。
+ ご使用のデバイスまたは AWS CloudShell で、バージョン `2.12.3` 以降、または AWS コマンドラインインターフェイス (AWS CLI) のバージョン `1.27.160` 以降がインストールおよび設定されていること。現在のバージョンを確認するには「`aws --version | cut -d / -f2 | cut -d ' ' -f1`」を参照してください。`yum`、`apt-get`、macOS 用の Homebrew などのパッケージマネージャーは、多くの場合 AWS CLI の最新バージョンより数バージョン古くなっています。最新バージョンをインストールするには「*AWS コマンドラインインターフェイスユーザーガイド*」の「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」および「[aws configure を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。AWS クラウドシェル にインストールされている AWS CLI バージョンも最新バージョンより数バージョン遅れることがあります。更新するには、「*AWS CloudShell ユーザーガイド*」の「[ホームディレクトリへの AWS CLI のインストール](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)」を参照してください。
+ デバイスまたは AWS クラウドシェル に、`kubectl` コマンドラインツールがインストールされていること。バージョンはご使用のクラスターの Kubernetes バージョンと同じか、1 つ前のマイナーバージョン以前、あるいはそれより新しいバージョンが使用できます。例えば、クラスターのバージョンが `1.29` である場合、`kubectl` のバージョン `1.28`、`1.29`、または `1.30` が使用できます。`kubectl` をインストールまたはアップグレードする方法については「[`kubectl` および `eksctl` のセットアップ](install-kubectl.md)」を参照してください。
+ クラスター構成を含む既存の `kubectl` `config` ファイル。`kubectl` `config` ファイルの作成については、「[kubeconfig ファイルを作成して kubectl を EKS クラスターに接続する](create-kubeconfig.md)」を参照してください。
`eksctl` または AWS マネジメントコンソール を使用して、クラスターの IAM OIDC プロバイダーを作成できます。
## OIDC プロバイダーの作成 (eksctl)
1. デバイスまたは AWS CloudShell にインストールされている `eksctl` コマンドラインツールのバージョン `0.215.0` 以降。`eksctl` をインストールまたはアップグレードするには`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。
1. クラスターの OIDC 発行者 ID を決定します。
クラスターの OIDC 発行者 ID を取得し、変数に格納します。`` を独自の値に置き換えます。
```
cluster_name=
oidc_id=$(aws eks describe-cluster --name $cluster_name --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5)
echo $oidc_id
```
1. クラスターの発行者 ID を持つ IAM OIDC プロバイダーが既にアカウントにあるかどうかを確認します。
```
aws iam list-open-id-connect-providers | grep $oidc_id | cut -d "/" -f4
```
出力が返された場合は、既にクラスター用の IAM OIDC プロバイダーが存在するため、次の手順をスキップできます。出力が返されない場合はクラスター用の IAM OIDC プロバイダーを作成する必要があります。
1. 次のコマンドを使用して、クラスターの IAM OIDC ID プロバイダーを作成します。
```
eksctl utils associate-iam-oidc-provider --cluster $cluster_name --approve
```
**注記**
EKS VPC エンドポイントを有効にすると、その VPC 内から EKS OIDC サービスエンドポイントにアクセスできなくなります。そのため、VPC で `eksctl` を使用して OIDC プロバイダーを作成するなどの操作は機能せず、タイムアウトします。エラーメッセージの例は次のとおりです。
```
** server cant find oidc.eks..amazonaws.com: NXDOMAIN
```
このステップを完了するには、VPC の外部、たとえばインターネットに接続された AWS CloudShell 内またはコンピューター上でコマンドを実行します。または、Route 53 Resolver などのスプリットホライズン条件付きリゾルバーを VPC に作成して、OIDC 発行者 URL のために別のリゾルバーを使用し、VPC DNS は使用しないようにすることもできます。CoreDNS での条件付き転送の例については、GitHub の「[Amazon EKS feature request](https://github.com/aws/containers-roadmap/issues/2038)」を参照してください。
## OIDC プロバイダーの作成 (AWS コンソール)
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左側ペインで、**[クラスター]** を選択し、**[クラスター]** ページでご自身のクラスターの名前を選択します。
1. **[概要]** タブの **[詳細]** セクションで、**[OpenID Connect プロバイダーの URL]** の値を書き留めます。
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインの **[アクセス管理]** で **[ID プロバイダー]** を選択します。[**プロバイダー**] がクラスターの URL と一致するリストに表示されている場合は、クラスターのプロバイダーがすでに存在します。クラスターの URL に一致するプロバイダーがリストにない場合、プロバイダーを作成する必要があります。
1. プロバイダーを作成するには、**[プロバイダーを追加]** を選択します。
1. **[プロバイダータイプ]** に、**[OpenID Connect]** を選択します。
1. **[プロバイダー URL]** に、クラスター用の OIDC プロバイダー URL 入力します。
1. **[対象者]** には `sts.amazonaws.com` を入力します。
1. （オプション) 任意のタグ、例えば、このプロバイダーのクラスターを特定するためのタグを追加します。
1. **[プロバイダーを追加]** をクリックします。
次のステップ: [IAM ロールを Kubernetes サービスアカウントに割り当てる](associate-service-account-role.md)
# IAM ロールを Kubernetes サービスアカウントに割り当てる
このトピックでは、AWS Identity and Access Management (IAM) ロール を引き受けるように Kubernetes サービスアカウントを設定する方法について説明します。任意の Pod はサービスアカウントを使用するように設定すると、ロールにアクセス許可がある AWS サービスすべてにアクセスできます。
## 前提条件
+ 既存のクラスター。まだ所有していない場合は、[Amazon EKS の使用を開始する](getting-started.md) でのガイドのいずれかに従って作成できます。
+ クラスターの既存 IAM OpenID Connect (OIDC) プロバイダー 既に所有中かどうかの確認、または作成方法については「[クラスターの IAM OIDC プロバイダーを作成するには](enable-iam-roles-for-service-accounts.md)」を参照してください。
+ ご使用のデバイスまたは AWS CloudShell で、バージョン `2.12.3` 以降、または AWS コマンドラインインターフェイス (AWS CLI) のバージョン `1.27.160` 以降がインストールおよび設定されていること。現在のバージョンを確認するには「`aws --version | cut -d / -f2 | cut -d ' ' -f1`」を参照してください。`yum`、`apt-get`、macOS 用の Homebrew などのパッケージマネージャーは、多くの場合 AWS CLI の最新バージョンより数バージョン古くなっています。最新バージョンをインストールするには「*AWS コマンドラインインターフェイスユーザーガイド*」の「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」および「[aws configure を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。AWS クラウドシェル にインストールされている AWS CLI バージョンも最新バージョンより数バージョン遅れることがあります。更新するには、「*AWS CloudShell ユーザーガイド*」の「[ホームディレクトリへの AWS CLI のインストール](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)」を参照してください。
+ デバイスまたは AWS クラウドシェル に、`kubectl` コマンドラインツールがインストールされていること。バージョンはご使用のクラスターの Kubernetes バージョンと同じか、1 つ前のマイナーバージョン以前、あるいはそれより新しいバージョンが使用できます。例えば、クラスターのバージョンが `1.29` である場合、`kubectl` のバージョン `1.28`、`1.29`、または `1.30` が使用できます。`kubectl` をインストールまたはアップグレードする方法については「[`kubectl` および `eksctl` のセットアップ](install-kubectl.md)」を参照してください。
+ クラスター構成を含む既存の `kubectl` `config` ファイル。`kubectl` `config` ファイルの作成については、「[kubeconfig ファイルを作成して kubectl を EKS クラスターに接続する](create-kubeconfig.md)」を参照してください。
## ステップ 1: IAM ポリシーの作成
既存の IAM ポリシーを IAM ロールに関連付ける場合は、次のステップにスキップします。
1. IAM ポリシーを作成します。ポリシーを自作することも、必要となるアクセス権限のいくつかが既に付与されている AWS 管理ポリシーをコピーし、特定の要件に応じてカスタマイズすることもできます。詳細については、「*IAM ユーザーガイド*」の「[IAM ポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。
1. Pod にアクセスさせる AWS サービスの権限を含むファイルを作成します。すべての AWS サービスに対するアクションの全リストについては、「[サービス認可リファレンス](https://docs.aws.amazon.com/service-authorization/latest/reference/)」を参照してください。
次のコマンドを実行して、Amazon S3 バケットへの読み取り専用アクセスを許可するサンプルポリシーファイルを作成できます。必要に応じて、このバケットに設定情報またはブートストラップスクリプトを格納すると、Pod 内のコンテナがバケットからファイルを読み取り、アプリケーションにロードできます。このサンプルポリシーを作成する場合は、次のコンテンツをデバイスにコピーします。*my-pod-secrets-bucket* をバケット名に置き換え、コマンドを実行します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
1. IAM ポリシーを作成します。
```
aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json
```
## ステップ 2: IAM ロールを作成して関連付ける
IAM ロールを作成し、Kubernetes サービスアカウントに関連付けます。`eksctl` または AWS CLI を使用できます。
### ロールの作成と関連付け (eksctl)
この `eksctl` コマンドは指定された名前空間に Kubernetes サービスアカウントを作成し、指定された名前で (存在しない場合は) IAM ロールを作成し、既存の IAM ポリシー ARN をロールにアタッチし、サービスアカウントに IAM ロール ARN を注釈付けします。このコマンドのサンプルプレースホルダー値は、必ず特定の値に置き換えてください。`eksctl` をインストールまたはアップグレードするには`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。
```
eksctl create iamserviceaccount --name my-service-account --namespace default --cluster my-cluster --role-name my-role \
--attach-policy-arn arn:aws:iam::111122223333:policy/my-policy --approve
```
**重要**
ロールまたはサービスアカウントが既に存在する場合、前のコマンドは失敗する可能性があります。`eksctl` には、そのような状況で使用できるさまざまなオプションがあります。詳細については、`eksctl create iamserviceaccount --help` を実行してください。
### ロールの作成と関連付け (AWS CLI)
IAM ロールを引き受ける既存の Kubernetes サービスアカウントがある場合は、この手順を省略できます。
1. Kubernetes サービスアカウントを作成します。次のコンテンツをデバイスにコピーします。*my-service-account* を目的の名前に置き換え、必要に応じて *default* を別の名前空間に置き換えます。*default* を変更する場合、名前空間は既に存在している必要があります。
```
cat >my-service-account.yaml <
1. IAM ロールの信頼ポリシーが正しく設定されていることを確認します。
```
aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
```
出力例は次のとおりです。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account",
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
}
}
}
]
}
```
1. 前の手順でロールにアタッチしたポリシーが、そのロールにアタッチされていることを確認します。
```
aws iam list-attached-role-policies --role-name my-role --query "AttachedPolicies[].PolicyArn" --output text
```
出力例は次のとおりです。
```
arn:aws:iam::111122223333:policy/my-policy
```
1. 使用するポリシーの Amazon リソースネーム (ARN) を保存する変数を設定します。*my-policy* を、アクセス許可を確認するポリシーの名前に置き換えます。
```
export policy_arn=arn:aws:iam::111122223333:policy/my-policy
```
1. ポリシーのデフォルトバージョンを確認します。
```
aws iam get-policy --policy-arn $policy_arn
```
出力例は次のとおりです。
```
{
"Policy": {
"PolicyName": "my-policy",
"PolicyId": "EXAMPLEBIOWGLDEXAMPLE",
"Arn": "arn:aws:iam::111122223333:policy/my-policy",
"Path": "/",
"DefaultVersionId": "v1",
[...]
}
}
```
1. ポリシーの内容を表示して、Pod で必要な権限がすべて含まれていることを確認します。必要であれば、次のコマンドの *1* を、前の出力で返されたバージョンに置き換えます。
```
aws iam get-policy-version --policy-arn $policy_arn --version-id v1
```
出力例は次のとおりです。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
前の手順でサンプルポリシーを作成した場合、出力は同じになります。別のポリシーを作成した場合、*サンプル*の内容は異なります。
1. Kubernetes サービスアカウントにロールが注釈されていることを確認します。
```
kubectl describe serviceaccount my-service-account -n default
```
出力例は次のとおりです。
```
Name: my-service-account
Namespace: default
Annotations: eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-role
Image pull secrets:
Mountable secrets: my-service-account-token-qqjfl
Tokens: my-service-account-token-qqjfl
[...]
```
## 次のステップ
+ [Kubernetes サービスアカウントを使用するように Pod を設定するには](pod-configuration.md)
# Kubernetes サービスアカウントを使用するように Pod を設定するには
Pod が AWS サービスにアクセスする必要がある場合は、Kubernetes サービスアカウントを使用するように設定する必要があります。サービスアカウントは、AWS サービスにアクセスする権限がある AWS Identity and Access Management (IAM) ロールに関連付ける必要があります。
+ 既存のクラスター。まだ所有していない場合は、[Amazon EKS の使用を開始する](getting-started.md) でのガイドのいずれかを参照しながら作成できます。
+ クラスターの既存 IAM OpenID Connect (OIDC) プロバイダー 既に所有中かどうかの確認、または作成方法については「[クラスターの IAM OIDC プロバイダーを作成するには](enable-iam-roles-for-service-accounts.md)」を参照してください。
+ IAM ロールに関連付けられている既存の Kubernetes サービスアカウント。サービスアカウントには、IAM ロールの Amazon リソースネーム (ARN) の注釈を付ける必要があります。ロールには、Pod が AWS サービスを使用するアクセス許可を含む IAM ポリシーが関連付けられている必要があります。サービスアカウントとロールの作成および設定方法については、「[IAM ロールを Kubernetes サービスアカウントに割り当てる](associate-service-account-role.md)」を参照してください。
+ ご使用のデバイスまたは AWS CloudShell で、バージョン `2.12.3` 以降、または AWS コマンドラインインターフェイス (AWS CLI) のバージョン `1.27.160` 以降がインストールおよび設定されていること。現在のバージョンを確認するには「`aws --version | cut -d / -f2 | cut -d ' ' -f1`」を参照してください。`yum`、`apt-get`、macOS 用の Homebrew などのパッケージマネージャーは、多くの場合 AWS CLI の最新バージョンより数バージョン古くなっています。最新バージョンをインストールするには「*AWS コマンドラインインターフェイスユーザーガイド*」の「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」および「[aws configure を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。AWS クラウドシェル にインストールされている AWS CLI バージョンも最新バージョンより数バージョン遅れることがあります。更新するには、「*AWS CloudShell ユーザーガイド*」の「[ホームディレクトリへの AWS CLI のインストール](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)」を参照してください。
+ デバイスまたは AWS クラウドシェル に、`kubectl` コマンドラインツールがインストールされていること。バージョンはご使用のクラスターの Kubernetes バージョンと同じか、1 つ前のマイナーバージョン以前、あるいはそれより新しいバージョンが使用できます。例えば、クラスターのバージョンが `1.29` である場合、`kubectl` のバージョン `1.28`、`1.29`、または `1.30` が使用できます。`kubectl` をインストールまたはアップグレードする方法については「[`kubectl` および `eksctl` のセットアップ](install-kubectl.md)」を参照してください。
+ クラスター構成を含む既存の `kubectl` `config` ファイル。`kubectl` `config` ファイルの作成については、「[kubeconfig ファイルを作成して kubectl を EKS クラスターに接続する](create-kubeconfig.md)」を参照してください。
1. 次コマンドを使用して、Pod をデプロイして設定を確認できるデプロイマニフェストを作成します。example の値は独自の値に置き換えます。
```
cat >my-deployment.yaml <
Kubernetes サービスアカウントを[サービスアカウント用の IAM ロール](iam-roles-for-service-accounts.md)と共に使用している場合、そのサービスアカウントで使用される AWS Security Token Service エンドポイントのタイプを設定できます。
AWS では、グローバルエンドポイントの代わりに地域の AWS STS エンドポイントを使用することを推奨しています。これにより、レイテンシーが減少し、組み込みの冗長性が提供され、セッショントークンの有効性が向上します。Pod が実行中の AWS リージョンで、AWS Security Token Service がアクティブであること。さらに、AWS リージョン内のサービスに障害が発生した場合に別の AWS リージョンを使用できるよう、アプリケーションに冗長性が組み込まれている必要があります。詳細については、IAM ユーザーガイドの「[AWS リージョンでの AWS STS の管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html)」を参照してください。
+ 既存のクラスター。まだ所有していない場合は、[Amazon EKS の使用を開始する](getting-started.md) でのガイドのいずれかを参照しながら作成できます。
+ クラスター用の既存の IAM OIDC プロバイダー。詳細については、「[クラスターの IAM OIDC プロバイダーを作成するには](enable-iam-roles-for-service-accounts.md)」を参照してください。
+ [サービスアカウント用の Amazon EKS IAM](iam-roles-for-service-accounts.md) 機能を使用するように設定された、既存の Kubernetes サービスアカウント。
次の例ではすべて、[Amazon VPC CNI プラグイン](cni-iam-role.md)で使用される aws-node Kubernetes サービスアカウントを使用しています。*example values* は、ご自身のサービスアカウント、ポッド、名前空間、その他のリソースに置き換えることができます。
1. エンドポイントを変更したいサービスアカウントを使用する Pod を選択します。Pod を実行する AWS リージョンを決定します。*aws-node-6mfgv* を Pod 名に置き換え、*kube-system* をポッドの名前空間に置き換えます。
```
kubectl describe pod aws-node-6mfgv -n kube-system |grep Node:
```
出力例は次のとおりです。
```
ip-192-168-79-166.us-west-2/192.168.79.166
```
前の出力では、Pod は us-west-2 AWS リージョンのノードで実行されています。
1. Pod のサービスアカウントが使用しているエンドポイントタイプを確認します。
```
kubectl describe pod aws-node-6mfgv -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
```
出力例は次のとおりです。
```
AWS_STS_REGIONAL_ENDPOINTS: regional
```
現在のエンドポイントがグローバルの場合、この出力には `global` が返されます。出力が返されない場合、デフォルトのエンドポイントタイプが、上書きされないまま使用されています。
1. クラスターまたはプラットフォームのバージョンが表に示されているバージョンと同じかそれ以降の場合は、次のコマンドのいずれかを使用して、サービスアカウントで使用されるエンドポイントタイプをデフォルトタイプから別のタイプに変更できます。*aws-node* は、サービスアカウントの名前に置き換え、*kube-system* は、サービスアカウントの名前空間に置き換えます。
+ デフォルトまたは現在のエンドポイントタイプがグローバルであり、それをリージョン別に変更する場合は、以下の手順を実行します。
```
kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=true
```
Pod のコンテナで実行されているアプリケーションで、事前署名された S3 URL を生成するために[サービスアカウントの IAM ロール](iam-roles-for-service-accounts.md)を使用している場合、リージョン別エンドポイントの URL の形式は、次の例のようになります。
```
https://bucket.s3.us-west-2.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
```
+ デフォルトまたは現在のエンドポイントタイプがリージョン別であり、それをグローバルに変更する場合は、次の手順を実行します。
```
kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=false
```
アプリケーションが、AWS STS のグローバルエンドポイントに対し明示的にリクエストを行っており、Amazon EKS クラスターにおいて、リージョン別エンドポイントを使用する際のデフォルトの動作がオーバーライドされていない場合は、リクエストが失敗しエラーが返されます。詳細については、「[ポッドコンテナは次のエラーを受け取ります: `An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region`](security-iam-troubleshoot.md#security-iam-troubleshoot-wrong-sts-endpoint)」を参照してください。
Pod のコンテナで実行されているアプリケーションで、事前署名された S3 URL を生成するために[サービスアカウントの IAM ロール](iam-roles-for-service-accounts.md)を使用している場合、グローバルエンドポイントの URL の形式は、次の例のようになります。
```
https://bucket.s3.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
```
使用している自動化処理で、事前署名付き URL に特定の形式を想定している場合、または事前署名付き URL を使用するアプリケーションやダウンストリームの依存関係に、ターゲットとして想定する AWS リージョンがある場合、適切な AWS STS エンドポイントを使用するために必要な変更を加えます。
1. 認証情報環境変数を適用するために、サービスアカウントに関連付けられている既存の Pod を削除して再作成します。変更するウェブフックは、既に実行されている Pod には適用されません *Pod*、*kube-system*、および *-l k8s-app=aws-node* を、アノテーションを設定する Pod の情報に置き換えることができます。
```
kubectl delete Pods -n kube-system -l k8s-app=aws-node
```
1. Pod がすべて再起動したことを確認します。
```
kubectl get Pods -n kube-system -l k8s-app=aws-node
```
1. Pod のいずれかの環境変数を表示します。`AWS_STS_REGIONAL_ENDPOINTS` の値が、以前のステップで設定した値であることを確認します。
```
kubectl describe pod aws-node-kzbtr -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
```
出力例は次のとおりです。
```
AWS_STS_REGIONAL_ENDPOINTS=regional
```
# IRSA で別のアカウントに対して認証する
別のアカウントのクラスターから ID プロバイダーを作成するか、連鎖した `AssumeRole` オペレーションを使用することで、クロスアカウントの IAM アクセス許可を設定できます。次の例では、*アカウント A* は、サービスアカウントの IAM ロールをサポートする Amazon EKS クラスターを所有しています。そのクラスターで実行されている Pod は、*アカウント B* の IAM アクセス許可を引き受ける必要があります。
+ **オプション 1** の方がシンプルですが、アカウント B でアカウント A のクラスターの OIDC ID プロバイダーを作成および管理する必要があります。
+ **オプション 2** は、OIDC が常にアカウント A で管理されますが、`AssumeRole` を 2 つ呼び出してロールチェイニングを行う必要があります。
## オプション 1: 別のアカウントのクラスターから ID プロバイダーを作成する
この例では、アカウント A はアカウント B にクラスターからの OpenID Connect (OIDC) 発行者 URL を提供します。アカウント B は、アカウント A のクラスターからの OIDC 発行者 URL を使用して、「[クラスターの IAM OIDC プロバイダーを作成する](enable-iam-roles-for-service-accounts.md)」および「[IAM ロールを Kubernetes サービスアカウントに割り当てる](associate-service-account-role.md)」の手順に従います。次に、クラスター管理者は、アカウント A のクラスターのサービスアカウントに、アカウント B (*444455556666*) のロールを使用するように注釈を付けます。
```
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::444455556666:role/account-b-role
```
## オプション 2: 連鎖された `AssumeRole` オペレーションを使用する
このアプローチでは、アカウントごとに IAM ロールが作成されます。アカウント B のロールは、アカウント A を信頼します。アカウント A のロールは、OIDC フェデレーションを使用して、クラスターから認証情報を取得します。ポッドは、AWS CLI プロファイルを使用して、2 つのロールを連鎖させます。
### ステップ 1: アカウント B にターゲットロールを作成する
アカウント B (*444455556666*) は、アカウント A のクラスター内のポッドで必要になるアクセス許可と共に IAM ロールを作成します。アカウント B は、このロールに目的のアクセス許可ポリシーをアタッチし、次の信頼ポリシーを追加します。
**アカウント B のロール用の信頼ポリシー** — アカウント A の特定の IRSA ロールがこのロールを引き受けることを許可します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
```
**重要**
最小特権の場合、アカウントルート (`arn:aws:iam::111122223333:root`) を使用するのではなく、`Principal` ARN をアカウント A の特定のロール ARN に置き換えます。アカウントルートを使用すると、アカウント A の*いずれの* IAM プリンシパルもこのロールを引き受けることができます。
### ステップ 2: アカウント A に IRSA ロールを作成する
アカウント A (*111122223333*) では信頼ポリシーを定義したロールを作成し、その信頼ポリシーではクラスターの OIDC 発行者アドレスで作成された ID プロバイダーから認証情報を取得することを許可します。
**アカウント A のロール (OIDC フェデレーション) 用の信頼ポリシー** — EKS クラスターの OIDC プロバイダーがこのロールの認証情報を発行することを許可します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
}
}
}
]
}
```
**重要**
最小特権の場合、`sub` クレームの `StringEquals` 条件を追加して、このロールを特定の Kubernetes サービスアカウントに制限します。`sub` 条件がない場合、クラスター内のいずれのサービスアカウントもこのロールを引き受けることができます。`sub` 値では、`system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME ` という形式を使用します。例えば、`default` 名前空間で `my-service-account` という名前のサービスアカウントに制限するには、次のようにします。
```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account"
```
### ステップ 3: アカウント A のロールに AssumeRole アクセス許可をアタッチする
アカウント A は、ステップ 2 で作成されたロールにアクセス許可ポリシーをアタッチします。このポリシーにより、ロールがアカウント B のロールを引き受けることが許可されます。
**アカウント A のロール用のアクセス許可ポリシー** — アカウント B のターゲットロールに `sts:AssumeRole` を付与します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::444455556666:role/account-b-role"
}
]
}
```
### ステップ 4: ロールを連鎖するようにポッドを設定する
アカウント B のロールを引き受ける Pod のアプリケーションコードは、`account_b_role` と `account_a_role` の 2 つのプロファイルを使用します。`account_b_role` プロファイルでは、ソースとして `account_a_role` プロファイルを使用します。AWS CLI では、`~/.aws/config` ファイルは以下のようになります。
```
[profile account_b_role]
source_profile = account_a_role
role_arn=arn:aws:iam::444455556666:role/account-b-role
[profile account_a_role]
web_identity_token_file = /var/run/secrets/eks.amazonaws.com/serviceaccount/token
role_arn=arn:aws:iam::111122223333:role/account-a-role
```
他の AWS SDK の連鎖されたプロファイルを指定するには、使用する SDK のドキュメントを参照してください。詳細については、「[AWS で構築するツール](https://aws.amazon.com/developer/tools/)」を参照してください。
# AWS SDK で IRSA を使用する
**認証情報の使用**
サービスアカウントの IAM ロール (IRSA) の認証情報を使用するために、コードで任意の AWS SDK を使用して SDK を含む AWS サービスのクライアントを作成できます。デフォルトでは、SDK は使用する AWS Identity and Access Management 認証情報を一連の場所で検索します。クライアントの作成時や SDK の初期化時に認証情報プロバイダーを指定しなかった場合は、サービスアカウントの認証情報用の IAM ロールが使用されます。
これがうまくいくのは、サービスアカウント用の IAM ロールがデフォルトの認証情報チェーンのステップとして追加されたからです。現在、ワークロードが認証情報チェーンの前にある認証情報を使用している場合は、同じワークロードのサービスアカウントに IAM ロールを設定しても、その認証情報は引き続き使用されます。
SDK は、`AssumeRoleWithWebIdentity` アクションを使用してサービスアカウント OIDC トークンを AWS Security Token Service からの一時的な認証情報と自動的に交換します。Amazon EKS とこの SDK アクションは、有効期限が切れる前に一時認証情報を更新することで、引き続きローテーションを行います。
[サービスアカウントの IAM ロール](iam-roles-for-service-accounts.md)を使用すると、Pod 内のコンテナは、OpenID Connect ウェブ ID トークンファイルを介した IAM ロールの引き受けをサポートする AWS SDK バージョンを使用する必要があります。お使いの AWS SDK には、必ず次のバージョン以降を使用してください。
+ Java (バージョン 2) – [2.10.11](https://github.com/aws/aws-sdk-java-v2/releases/tag/2.10.11)
+ Java – [1.12.782](https://github.com/aws/aws-sdk-java/releases/tag/1.12.782)
+ AWS SDK for Go v1 – [1.23.13](https://github.com/aws/aws-sdk-go/releases/tag/v1.23.13)
+ AWS SDK for Go v2 – すべてのバージョンがサポートされています
+ Python (Boto3) – [1.9.220](https://github.com/boto/boto3/releases/tag/1.9.220)
+ Python (botocore) – [1.12.200](https://github.com/boto/botocore/releases/tag/1.12.200)
+ AWS CLI – [1.16.232](https://github.com/aws/aws-cli/releases/tag/1.16.232)
+ ノード - [2.525.0](https://github.com/aws/aws-sdk-js/releases/tag/v2.525.0) と [3.27.0](https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.27.0)
+ Ruby – [3.58.0](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md#3580-2019-07-01)
+ C\$1\$1 – [1.7.174](https://github.com/aws/aws-sdk-cpp/releases/tag/1.7.174)
+ .NET - [3.3.659.1](https://github.com/aws/aws-sdk-net/releases/tag/3.3.659.1) - `AWSSDK.SecurityToken` も含めることを確認します。
+ PHP – [3.110.7](https://github.com/aws/aws-sdk-php/releases/tag/3.110.7)
[Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)、[AWS Load Balancer Controller を使用してインターネットトラフィックをルーティングする](aws-load-balancer-controller.md)、[Amazon VPC CNI plugin for Kubernetes](cni-iam-role.md) など、一般的な Kubernetes アドオンの多くは、サービスアカウントの IAM ロールをサポートしています。
サポートされている SDK を使用していることを確認するには、コンテナを構築する際に、「[AWS での構築ツール](https://aws.amazon.com/tools/)」で、希望する SDK のインストール手順に従ってください。
## 考慮事項
### Java
Java を使用する場合は、クラスパスに `sts` を含める*必要があります*。詳細については、Java SDK ドキュメントの「[WebIdentityTokenFileCredentialsProvider](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/WebIdentityTokenFileCredentialsProvider.html)」を参照してください。
# OIDC トークンを検証するための署名キーを取得する
Kubernetes は、`ProjectedServiceAccountToken` を各 Kubernetes サービスアカウントに発行します。このトークンは OIDC トークンであり、さらに JSON ウェブトークン (JWT) の一種でもあります。Amazon EKS は、外部システムでトークンを検証できるように、トークンの署名キーを含むクラスターごとにパブリック OIDC エンドポイントをホストします。
`ProjectedServiceAccountToken` を検証するには、JSON ウェブキーセット (JWKS) とも呼ばれる OIDC パブリック署名キーを取得する必要があります。アプリケーションでこれらのキーを使用してトークンを検証します。例えば、[PyJWT Python ライブラリ](https://pyjwt.readthedocs.io/en/latest/)を使用して、これらのキーを使用してトークンを検証できます。`ProjectedServiceAccountToken` の詳細については、「[IAM、Kubernetes、OpenID Connect (OIDC) の背景情報](iam-roles-for-service-accounts.md#irsa-oidc-background)」を参照してください。
## 前提条件
+ クラスターの既存の AWS Identity and Access Management (IAM) OpenID Connect (OIDC) プロバイダー。既に存在しているかどうかを確認する、または作成するには「[クラスターの IAM OIDC プロバイダーを作成するには](enable-iam-roles-for-service-accounts.md)」を参照してください。
+ **AWS CLI** – Amazon EKS など AWS のサービスを操作するためのコマンドラインツールです。詳細については、AWS コマンドラインインターフェイスユーザーガイドの「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」を参照してください。AWS CLI のインストール後は設定も行っておくことをお勧めします。詳細については、AWS コマンドラインインターフェイスユーザーガイドの「[aws configure を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。
## 手順
1. AWS CLI を使用して、Amazon EKS クラスターの OIDC URL を取得します。
```
$ aws eks describe-cluster --name my-cluster --query 'cluster.identity.oidc.issuer'
"https://oidc.eks.us-west-2.amazonaws.com/id/8EBDXXXX00BAE"
```
1. curl または同様のツールを使用して、パブリック署名キーを取得します。結果は [JSON ウェブキーセット (JWKS)](https://www.rfc-editor.org/rfc/rfc7517#section-5) です。
**重要**
Amazon EKS は、OIDC エンドポイントへの呼び出しをスロットリングします。パブリック署名キーをキャッシュする必要があります。レスポンスに含まれる `cache-control` ヘッダーを考慮します。
**重要**
Amazon EKS は、OIDC 署名キーを 7 日ごとにローテーションします。
```
$ curl https://oidc.eks.us-west-2.amazonaws.com/id/8EBDXXXX00BAE/keys
{"keys":[{"kty":"RSA","kid":"2284XXXX4a40","use":"sig","alg":"RS256","n":"wklbXXXXMVfQ","e":"AQAB"}]}
```
# EKS Pod Identity が Pod に AWS サービスへのアクセス権を付与する仕組みを学ぶ
ポッドのコンテナ内のアプリケーションは AWS SDK または AWS CLI で、AWS Identity and Access Management (IAM) アクセス許可を使用した AWS サービスへの API リクエストを行うことができます。アプリケーションは AWS 認証情報で AWS API リクエストに署名する必要があります。
EKS Pod Identity は、Amazon EC2 インスタンスプロファイルから Amazon EC2 インスタンスに認証情報を提供する場合と同じような方法で、アプリケーションの認証情報を管理する機能があります。AWS 認証情報を作成してコンテナに配布したり、Amazon EC2 インスタンスのロールを使用したりする必要はありません。IAM ロールを Kubernetes サービスアカウントと関連付けて、サービスアカウントを使用するように Pod を設定できます。
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/aUjJSorBE70?rel=0)
各 EKS Pod Identity の関連付けは、指定されたクラスター内のネームスペース内のサービスアカウントにロールをマップします。複数のクラスターに同じアプリケーションがある場合、ロールの信頼ポリシーを変更することなく、各クラスターで同一の関連付けを行うことができます。
ポッドが関連付けられたサービスアカウントを使用する場合、Amazon EKS はポッドのコンテナに環境変数を設定します。環境変数は、AWS CLI を含む AWS SDK が EKS Pod Identity の認証情報を使用するように設定します。
## EKS Pod Identity の利点
EKS Pod Identity には次の利点があります。
+ **最小特権** – IAM アクセス許可の範囲をサービスアカウントに設定すると、そのサービスアカウントを使用する Pod にのみそのアクセス許可を付与できます。また、この機能により、`kiam` や `kube2iam` などのサードパーティーのソリューションが不要になります。
+ **認証情報の分離** – [Amazon EC2 インスタンスメタデータサービス (IMDS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) へのアクセスが制限されている場合、ポッド内のコンテナは、そのコンテナが使用するサービスアカウントに関連付けられている IAM ロールの認証情報のみを取得できます。コンテナは、他の Pod 内のコンテナで使われている認証情報にアクセスすることはできません。IMDS が制限されていない場合、ポッドのコンテナは「[Amazon EKS ノード IAM ロール](create-node-role.md)」にもアクセスでき、コンテナは同じノード上にある他のポッドの IAM ロールの認証情報にアクセスできる可能性があります。詳細については「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html#_identities_and_credentials_for_eks_pods_recommendations)」を参照してください。
**注記**
`hostNetwork: true` で設定されたポッドは常に IMDS にアクセスできますが、AWS SDK および CLI は、有効である場合は Pod Identity 認証情報を使用します。
+ **監査性** – 遡及的な監査を確実に行うため、AWS CloudTrail を介してアクセスとイベントのロギングを利用できます。
**重要**
コンテナはセキュリティ境界ではなく、Pod Identity を使用してもこの点は変わりません。同じノードに割り当てられたポッドはカーネルを共有し、ポッド設定によっては他のリソースも共有される可能性があります。別々のノードで実行されているポッドはコンピューティングレイヤーで分離されますが、Kubernetes API に対し個別のインスタンスの範囲を超えて追加のアクセス許可を持つノードアプリケーションがあります。例としては `kubelet`、`kube-proxy`、CSI ストレージドライバー、ユーザー独自の Kubernetes アプリケーションなどがあります。
EKS Pod Identity は、OIDC ID プロバイダーを使用しないため、[サービスアカウントの IAM ロール](iam-roles-for-service-accounts.md) よりも簡単な方法です。EKS Pod Identity には次の機能強化があります。
+ **独立オペレーション** – 多くの組織では、OIDC ID プロバイダーの作成を Kubernetes クラスターの管理とは別のチームが担当しています。EKS Pod Identity には明確な役割分担があり、EKS Pod Identity の関連付けの設定はすべて Amazon EKS で行われ、IAM アクセス許可の設定はすべて IAM で行われます。
+ **再利用性** – EKS Pod Identity は、サービスアカウントの IAM ロールが使用するクラスターごとの個別のプリンシパルの代わりに、単一の IAM プリンシパルを使用します。IAM 管理者は以下のプリンシパルを任意のロールの信頼ポリシーに追加して、EKS Pod Identity で使用できるようにします。
```
"Principal": {
"Service": "pods.eks.amazonaws.com"
}
```
+ **スケーラビリティ** – 一時的な認証情報の各セットは、各 Pod で実行する各 AWS SDK ではなく、EKS Pod Identity 内の EKS Auth サービスによって引き継がれます。次に、各ノードで実行される Amazon EKS Pod Identity エージェントが SDK に認証情報を発行します。そのため、負荷はノードごとに 1 回に減り、各ポッドで重複することはありません。詳細については、「[EKS Pod Identity の仕組みを理解する](pod-id-how-it-works.md)」を参照してください。
この 2 つの選択肢を比較する詳細については、「[Kubernetes ワークロードに Kubernetes サービスアカウントを使用して AWS へのアクセスを許可する](service-accounts.md)」を参照してください。
## EKS Pod Identity のセットアップの概要
以下の手順を実行して EKS Pod Identity を有効にします。
1. [Amazon EKS Pod Identity エージェントのセットアップ](pod-id-agent-setup.md) — この手順は、クラスターごとに 1 回だけ実行します。クラスターで EKS 自動モードが有効になっている場合は、このステップを完了する必要はありません。
1. [IAM ロールを Kubernetes サービスアカウントに割り当てる](pod-id-association.md) — この手順は、アプリケーションに付与する固有の権限セットごとに実行します。
1. [サービスアカウントを使用して AWS サービスにアクセスするように Pod を設定する](pod-id-configure-pods.md) — この手順を AWS サービスへのアクセスが必要な Pod ごとに実行します。
1. [AWS SDK で Pod Identity を使用する](pod-id-minimum-sdk.md) – ワークロードがサポートされているバージョンの AWS SDK を使用していること、およびワークロードがデフォルトの認証情報チェーンを使用していることを確認します。
## 制限
+ IAM ロールを Kubernetes サービスアカウントにマッピングするため、クラスターごとに最大 5,000 個の EKS Pod Identity の関連付けがサポートされています。
## 考慮事項
+ **IAM ロールの関連付け**: クラスター内の各 Kubernetes サービスアカウントは、クラスターと同じ AWS アカウントにある 1 つの IAM ロールに関連付けることができます。ロールを変更するには、EKS Pod Identity の関連付けを編集します。クロスアカウントアクセスの場合、IAM ロールを使用してロールへのアクセスを委任します。詳細については、「*IAM ユーザーガイド*」の「[AWS アカウント間の IAM ロールを使用したアクセスの委任](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)」を参照してください。
+ **EKS Pod Identity エージェント**: EKS Pod Identity を使用するには、Pod Identity エージェントが必要です。このエージェントはクラスターノード上で Kubernetes `DaemonSet` として実行され、同じノード上のポッドにのみ認証情報を提供します。ノードの `hostNetwork` を使用し、リンクローカルアドレス (IPv4 の場合は `169.254.170.23`、IPv6 の場合は `[fd00:ec2::23]`) でポート `80` および `2703` を占有します。クラスターで IPv6 が無効になっている場合は、Pod Identity エージェントの IPv6 を無効にしてください。詳細については、「[EKS Pod Identity エージェントで IPv6 を無効にする](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-config-ipv6.html)」を参照してください。
+ **結果的な整合性**: EKS Pod Identity の関連付けは結果整合性を持ち、API コール後に整合性が確保されるまで数秒の遅延が発生する可能性があります。重要な高可用性コードパスで関連付けを作成または更新することは避けてください。代わりに、そのようなアクションは別々の、より頻度の低い初期化ルーチンまたはセットアップルーチンで実行します。詳細については、「*EKS ベストプラクティスガイド*」の「[Security Groups Per Pod](https://docs.aws.amazon.com/eks/latest/best-practices/sgpp.html)」を参照してください。
+ **プロキシとセキュリティグループの考慮事項**: プロキシを使用するポッドの場合、`169.254.170.23` (IPv4) および `[fd00:ec2::23]` (IPv6) を `no_proxy/NO_PROXY` 環境変数に追加し、EKS Pod Identity エージェントへのリクエストの失敗を防ぎます。AWS VPC CNI でポッドのセキュリティグループを使用する場合、`ENABLE_POD_ENI` フラグを「true」に設定して `POD_SECURITY_GROUP_ENFORCING_MODE` フラグを「standard」に設定します。詳細については、「[セキュリティグループを個別のポッドに割り当てる](https://docs.aws.amazon.com/eks/latest/userguide/security-groups-for-pods.html)」を参照してください。
### EKS Pod Identity クラスターバージョン
EKS Pod Identity を使用するには、クラスターのプラットフォームバージョンが次のテーブルに記載されているバージョン以上であるか、Kubernetes バージョンがテーブルに記載されているよりも新しいバージョンである必要があります。Kubernetes バージョンに対し推奨される Amazon EKS Pod Identity エージェントのバージョンを確認するには、「[Amazon EKS アドオンバージョンのクラスターとの互換性を検証する](addon-compat.md)」を参照してください。
| Kubernetes バージョン | プラットフォームバージョン |
| --- | --- |
| Kubernetes バージョンの記載がない | サポートされるプラットフォームのすべてのバージョン |
| `1.28` | `eks.4` |
### EKS Pod Identity の制限事項
EKS Pod Identity は以下で使用できます。
+ 前のトピック [EKS Pod Identity クラスターバージョン](#pod-id-cluster-versions) に記載されている Amazon EKS クラスターバージョン。
+ Linux Amazon EC2 インスタンスであるクラスターのワーカーノード。
EKS Pod Identity は以下では使用できません。
+ AWS Outposts。
+ Amazon EKS Anywhere
+ Amazon EC2 で作成して実行する Kubernetes クラスター。EKS Pod Identity コンポーネントは Amazon EKS でのみ使用できます。
EKS Pod Identity は以下では使用できません。
+ Linux Amazon EC2 インスタンス以外の場所で実行されるポッド。AWS Fargate (Fargate) 上で実行される Linux ポッドと Windows ポッドはサポートされていません。Windows Amazon EC2 インスタンスで実行されるポッドはサポートされていません。
# EKS Pod Identity の仕組みを理解する
Amazon EKS Pod Identity の関連付けは、Amazon EC2 インスタンスプロファイルから Amazon EC2 インスタンスに認証情報を提供する場合と同じような方法で、アプリケーションの認証情報を管理する機能があります。
Amazon EKS Pod Identity は、追加の EKS Auth API と各ノードで実行されるエージェントポッドを使用して、ワークロードに認証情報を提供します。
Amazon EKS アドオン、自己管理型コントローラ、オペレータ、その他のアドオンなどのアドオンでは、作成者は最新の AWS SDK を使用するようにソフトウェアを更新する必要があります。EKS Pod Identity と Amazon EKS によって作成されたアドオンとの互換性のリストについては、前の [EKS Pod Identity の制限事項](pod-identities.md#pod-id-restrictions) セクションを参照してください。
## EKS Pod Identity をコードで使用する
コードでは、AWS SDK を使用して AWS サービスにアクセスできます。SDK を使用して AWS サービスのクライアントを作成するコードを記述すると、デフォルトで SDK は使用する AWS Identity and Access Management 認証情報を一連の場所で検索します。有効な認証情報が見つかると、検索は停止されます。使用されるデフォルトの場所について詳しくは、「AWS SDK and Tools リファレンスガイド」の「[認証情報プロバイダーチェーン](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain)」を参照してください。
EKS Pod Identity がコンテナ認証情報プロバイダーに追加されました。このプロバイダーはデフォルトの認証情報チェーンのステップで検索されます。現在、ワークロードが認証情報チェーンの前にある認証情報を使用している場合、同じワークロードに EKS Pod Identity の関連付けを設定しても、それらの認証情報は引き続き使用されます。この方法では、古い認証情報を削除する前に、まず関連付けを作成することで、他の種類の認証情報から安全に移行できます。
コンテナ認証情報プロバイダーは、各ノードで実行されるエージェントからの一時的な認証情報を提供します。Amazon EKS では、エージェントは Amazon EKS Pod Identity エージェントであり、Amazon Elastic Container Service ではエージェントは `amazon-ecs-agent` です。SDK は環境変数を使用して接続するエージェントを検索します。
一方、サービスアカウント用の IAM ロールは、AWS SDK が `AssumeRoleWithWebIdentity` を使用して AWS Security Token Service と交換しなければならないウェブ ID トークンを提供します。
## EKS Pod Identity エージェントが Pod とどのように連携するか
1. Amazon EKS が起動した新しい Pod で EKS Pod Identity 関連付けのあるサービスアカウントが使用されている場合、クラスターは次のコンテンツを Pod マニフェストに追加します。
```
env:
- name: AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE
value: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token"
- name: AWS_CONTAINER_CREDENTIALS_FULL_URI
value: "http://169.254.170.23/v1/credentials"
volumeMounts:
- mountPath: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/"
name: eks-pod-identity-token
volumes:
- name: eks-pod-identity-token
projected:
defaultMode: 420
sources:
- serviceAccountToken:
audience: pods.eks.amazonaws.com
expirationSeconds: 86400 # 24 hours
path: eks-pod-identity-token
```
1. Kubernetes は Pod を実行するノードを選択します。次に、ノード上の Amazon EKS Pod Identity エージェントは [AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html) アクションを使用して EKS Auth API から一時的な認証情報を取得します。
1. EKS Pod Identity エージェントは、コンテナ内で実行する AWS SDK でこれらの認証情報を利用できるようにします。
1. デフォルトの認証情報チェーンを使用する認証情報プロバイダーを指定しなくても、アプリケーションで SDK を使用できます。または、コンテナ認証情報プロバイダーを指定します。使用されるデフォルトの場所について詳しくは、「AWS SDK and Tools リファレンスガイド」の「[認証情報プロバイダーチェーン](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain)」を参照してください。
1. SDK は環境変数を使用して EKS Pod Identity エージェントに接続し、認証情報を取得します。
**注記**
ワークロードが現在、認証情報チェーンの早い段階にある認証情報を使用している場合、同じワークロードに EKS Pod Identity の関連付けを設定しても、その認証情報は引き続き使用されます。
# Amazon EKS Pod Identity エージェントのセットアップ
EKS Pod Identity の関連付けは、Amazon EC2 インスタンスプロファイルから Amazon EC2 インスタンスに認証情報を提供する場合と同じような方法で、アプリケーションの認証情報を管理する機能があります。
Amazon EKS Pod Identity は、追加の EKS Auth API と各ノードで実行されるエージェントポッドを使用して、ワークロードに認証情報を提供します。
**ヒント**
EKS Auto Mode クラスターに EKS Pod Identity エージェントをインストールする必要はありません。この機能は EKS Auto Mode に組み込まれています。
## 考慮事項
+ デフォルトでは、EKS Pod Identity Agent は EKS 自動モードクラスターにプリインストールされます。詳細については[EKS Auto Mode を使用してクラスターインフラストラクチャを自動化する](automode.md)を参照してください。
+ EKS Pod Identity エージェントはデフォルトでポッドが認証情報をリクエストするために `IPv4` と `IPv6` のアドレスをリッスンします。エージェントは、`IPv4` のループバック (localhost) IP アドレス `169.254.170.23` と `IPv6` の localhost IP アドレス `[fd00:ec2::23]` を使用します。
+ `IPv6` アドレスを無効にするか、または localhost `IPv6` IP アドレスを禁止すると、エージェントは起動できません。`IPv6` を使用できないノードでエージェントを起動するには、「[EKS Pod Identity エージェントで `IPv6` を無効にする](pod-id-agent-config-ipv6.md)」の手順に従って `IPv6` 設定を無効にします。
## Amazon EKS Pod Identity エージェントの作成
### エージェントの前提条件
+ 既存の Amazon EKS クラスター。デプロイするには「[Amazon EKS の使用を開始する](getting-started.md)」を参照してください。クラスターバージョンとプラットフォームバージョンは、[EKS Pod Identity クラスターバージョン](pod-identities.md#pod-id-cluster-versions)に記載されているバージョン以降である必要があります。
+ ノードロールには、エージェントが EKS Auth API で `AssumeRoleForPodIdentity` アクションを実行する権限があります。[AWS マネージドポリシー: AmazonEKSWorkerNodePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksworkernodepolicy) を使用するか、次のようなカスタムポリシーを追加できます。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks-auth:AssumeRoleForPodIdentity"
],
"Resource": "*"
}
]
}
```
このアクションをタグで制限して、エージェントを使用するポッドが引き受けることができるロールを制限できます。
+ ノードは Amazon ECR にアクセスしてイメージをダウンロードできます。アドオンのコンテナイメージは、「[Amazon EKS アドオンの Amazon コンテナイメージレジストリの表示](add-ons-images.md)」に記載されているレジストリにあります。
なお、イメージの場所を変更して、AWS マネジメントコンソール の **[オプションの設定]** や AWS CLI の `--configuration-values` で EKS アドオンの `imagePullSecrets` を提供することができます。
+ ノードは Amazon EKS Auth API にアクセスできます。プライベートクラスターでは、AWS PrivateLink の `eks-auth` エンドポイントが必要です。
### AWS コンソールでエージェントを設定する
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで、**[クラスター]** を選択し、次にアドオンを設定するEKS Pod Identity エージェントを選択します。
1. **[アドオン]** タブを選択してください。
1. **[その他のアドオンを入手]** を選択してください。
1. EKS Pod Identity のアドオンボックスの右上にあるボックスを選択し、**[次へ]** を選択します。
1. **[選択したアドオン設定を構成する]** ページの **[バージョン]** ドロップダウンリストで任意のバージョンを選択します。
1. (オプション) **[オプションの設定]** を展開して追加の設定を入力します。例えば、代替のコンテナイメージの場所と `ImagePullSecrets` を指定できます。許可されたキーのある JSON スキーマは、**[アドオン設定スキーマ]** に表示されます。
設定キーと値を **[設定値]** に入力します。
1. [**次へ**] を選択します。
1. EKS Pod Identity がクラスター上で実行されていることを確認してください。
```
kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
```
出力例は次のとおりです。
```
eks-pod-identity-agent-gmqp7 1/1 Running 1 (24h ago) 24h
eks-pod-identity-agent-prnsh 1/1 Running 1 (24h ago) 24h
```
これで、クラスターで EKS Pod Identity の関連付けを使用できるようになりました。詳細については、「[IAM ロールを Kubernetes サービスアカウントに割り当てる](pod-id-association.md)」を参照してください。
### AWS CLI でエージェントを設定する
1. 次の AWS CLI コマンドを実行します。`my-cluster` を自分のクラスター名に置き換えます。
```
aws eks create-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent --addon-version v1.0.0-eksbuild.1
```
**注記**
EKS Pod Identity エージェントは、*サービスアカウントの IAM ロール*用の `service-account-role-arn` を使用しません。EKS Pod Identity エージェントにはノードロールの権限を付与する必要があります。
1. EKS Pod Identity がクラスター上で実行されていることを確認してください。
```
kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
```
出力例は次のとおりです。
```
eks-pod-identity-agent-gmqp7 1/1 Running 1 (24h ago) 24h
eks-pod-identity-agent-prnsh 1/1 Running 1 (24h ago) 24h
```
これで、クラスターで EKS Pod Identity の関連付けを使用できるようになりました。詳細については、「[IAM ロールを Kubernetes サービスアカウントに割り当てる](pod-id-association.md)」を参照してください。
# IAM ロールを Kubernetes サービスアカウントに割り当てる
このトピックでは、EKS Pod Identity に関連付けられている AWS Identity and Access Management (IAM) ロールを引き受けるように Kubernetes サービスアカウントを設定する方法について説明します。任意の Pod はサービスアカウントを使用するように設定すると、ロールにアクセス許可がある AWS サービスすべてにアクセスできます。
EKS Pod Identity の関連付けを作成するには、1 つの手順しかありません。AWS マネジメントコンソール、AWS CLI、AWS SDK、AWS CCloudFormation などのツールを使用して EKS で関連付けを作成します。クラスター内の関連付けに関するデータやメタデータはどの Kubernetes オブジェクトにもなく、サービスアカウントに注釈を追加することもありません。
**前提条件**
+ 既存のクラスター。まだ所有していない場合は、[Amazon EKS の使用を開始する](getting-started.md) でのガイドのいずれかに従って作成できます。
+ 関連付けを作成している IAM プリンシパルには `iam:PassRole` が必要です。
+ ご使用のデバイスまたは AWS CloCloudShell に最新バージョンの AWS CLI がインストールおよび設定されていること。現在のバージョンは`aws --version | cut -d / -f2 | cut -d ' ' -f1` で確認できます。`yum`、`apt-get`、macOS 用の Homebrew などのパッケージマネージャーは、多くの場合 AWS CLI の最新バージョンより数バージョン古くなっています。最新バージョンをインストールするには、「AWS コマンドラインインターフェイスユーザーガイド」の「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」および「[aws configure を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。AWS CloudShell にインストールされている AWS CLI バージョンは、最新バージョンより数バージョン遅れている可能性もあります。更新するには、「AWS CloudShell ユーザーガイド」の「[ホームディレクトリへの AWS CLI のインストール](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)」を参照してください。
+ デバイスまたは AWS クラウドシェル に、`kubectl` コマンドラインツールがインストールされていること。バージョンはご使用のクラスターの Kubernetes バージョンと同じか、1 つ前のマイナーバージョン以前、あるいはそれより新しいバージョンが使用できます。例えば、クラスターのバージョンが `1.29` である場合、`kubectl` のバージョン `1.28`、`1.29`、または `1.30` が使用できます。`kubectl` をインストールまたはアップグレードする方法については「[`kubectl` および `eksctl` のセットアップ](install-kubectl.md)」を参照してください。
+ クラスター構成を含む既存の `kubectl` `config` ファイル。`kubectl` `config` ファイルの作成については、「[kubeconfig ファイルを作成して kubectl を EKS クラスターに接続する](create-kubeconfig.md)」を参照してください。
## Pod Identity の関連付けを作成する (AWS コンソール)
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで、**[クラスター]** を選択し、次にアドオンを設定するEKS Pod Identity エージェントを選択します。
1. **[アクセス]** タブを選択します。
1. **[Pod Identity の関連付け]** で **[作成]** を選択します。
1. **[IAM ロール]** には、ワークロードに付与する権限を持つ IAM ロールを選択します。
**注記**
リストには、EKS Pod Identity による使用を許可する以下の信頼ポリシーを持つロールのみが含まれています。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
`sts:AssumeRole` - EKS Pod Identity は一時的な認証情報をポッドに渡す前に、`AssumeRole` を使用して IAM ロールを引き継ぎます。
`sts:TagSession` - EKS Pod Identity は、AWS STS へのリクエストに*セッションタグ*を含めるために `TagSession` を使用します。
これらのタグを信頼ポリシーの*条件キー*で使用して、このロールを使用できるサービスアカウント、名前空間、およびクラスターを制限できます。
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)」を参照してください。
1. **[Kubernetes 名前空間]** では、サービスアカウントとワークロードが含まれている Kubernetes 名前空間を選択します。オプションで、クラスターに存在しない名前で名前空間名で指定できます。
1. **Kubernetes サービスアカウント**では、使用する Kubernetes サービスアカウントを選択します。Kubernetes ワークロードのマニフェストには、このサービスアカウントを指定する必要があります。オプションで、クラスターに存在しないサービスアカウントを名前で指定できます。
1. (オプション) **[セッションタグを無効にする]** を選択することで、Pod Identity がロールを引き受けるときに自動的に追加するデフォルトのセッションタグを無効にできます。
1. (オプション) **[セッションポリシーの設定]** を切り替えることで、IAM ロールにアタッチされた IAM ポリシーで定義されているアクセス許可以外の追加制限を、この Pod Identity 関連付けに適用するように IAM ポリシーを設定できます。
**注記**
セッションポリシーは、**[セッションタグを無効にする]** の設定がチェックされている場合にのみ適用できます。
1. (オプション) **[タグ]** で **[タグを追加]** を選択し、キーと値のペアにメタデータを追加します。これらのタグは関連付けに適用され、IAM ポリシーで使用できます。
このステップでは、複数のリージョンを追加できます。
1. **[作成]** を選択します。
## Pod Identity の関連付けを作成する (AWS CLI)
1. 既存の IAM ポリシーを IAM ロールに関連付ける場合は、次のステップにスキップします。
IAM ポリシーを作成します。ポリシーを自作することも、必要となるアクセス権限のいくつかが既に付与されている AWS 管理ポリシーをコピーし、特定の要件に応じてカスタマイズすることもできます。詳細については、「*IAM ユーザーガイド*」の「[IAM ポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。
1. Pod にアクセスさせる AWS サービスの権限を含むファイルを作成します。すべての AWS サービスに対するアクションの全リストについては、「[サービス認可リファレンス](https://docs.aws.amazon.com/service-authorization/latest/reference/)」を参照してください。
次のコマンドを実行して、Amazon S3 バケットへの読み取り専用アクセスを許可するサンプルポリシーファイルを作成できます。必要に応じて、このバケットに設定情報またはブートストラップスクリプトを格納すると、Pod 内のコンテナがバケットからファイルを読み取り、アプリケーションにロードできます。このサンプルポリシーを作成する場合は、次のコンテンツをデバイスにコピーします。*my-pod-secrets-bucket* をバケット名に置き換え、コマンドを実行します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
1. IAM ポリシーを作成します。
```
aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json
```
1. IAM ロールを作成し、Kubernetes サービスアカウントに関連付けます。
1. IAM ロールを引き受ける既存の Kubernetes サービスアカウントがある場合は、この手順を省略できます。
Kubernetes サービスアカウントを作成します。次のコンテンツをデバイスにコピーします。*my-service-account* を目的の名前に置き換え、必要に応じて *default* を別の名前空間に置き換えます。*default* を変更する場合、名前空間は既に存在している必要があります。
```
cat >my-service-account.yaml <
1. IAM ロールの信頼ポリシーが正しく設定されていることを確認します。
```
aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
```
出力例は次のとおりです。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Allow EKS Auth service to assume this role for Pod Identities",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
1. 前の手順でロールにアタッチしたポリシーが、そのロールにアタッチされていることを確認します。
```
aws iam list-attached-role-policies --role-name my-role --query 'AttachedPolicies[].PolicyArn' --output text
```
出力例は次のとおりです。
```
arn:aws:iam::111122223333:policy/my-policy
```
1. 使用するポリシーの Amazon リソースネーム (ARN) を保存する変数を設定します。*my-policy* を、アクセス許可を確認するポリシーの名前に置き換えます。
```
export policy_arn=arn:aws:iam::111122223333:policy/my-policy
```
1. ポリシーのデフォルトバージョンを確認します。
```
aws iam get-policy --policy-arn $policy_arn
```
出力例は次のとおりです。
```
{
"Policy": {
"PolicyName": "my-policy",
"PolicyId": "EXAMPLEBIOWGLDEXAMPLE",
"Arn": "arn:aws:iam::111122223333:policy/my-policy",
"Path": "/",
"DefaultVersionId": "v1",
[...]
}
}
```
1. ポリシーの内容を表示して、Pod で必要な権限がすべて含まれていることを確認します。必要であれば、次のコマンドの *1* を、前の出力で返されたバージョンに置き換えます。
```
aws iam get-policy-version --policy-arn $policy_arn --version-id v1
```
出力例は次のとおりです。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
前の手順でサンプルポリシーを作成した場合、出力は同じになります。別のポリシーを作成した場合、*サンプル*の内容は異なります。
## 次のステップ
[サービスアカウントを使用して AWS サービスにアクセスするように Pod を設定する](pod-id-configure-pods.md)
# EKS Pod Identity のターゲット IAM ロールを使用して AWS リソースにアクセスする
Amazon Elastic Kubernetes Service (Amazon EKS) でアプリケーションを実行する場合、異なる AWS アカウントに存在する AWS リソースへのアクセスが必要になることがあります。このガイドでは、EKS Pod Identity を使用してクロスアカウントアクセスを設定する方法を示します。これにより、Kubernetes ポッドからターゲットロールを使用して他の AWS リソースにアクセスできるようになります。
## 前提条件
作業を開始する前に、次の手順が完了していることを確認してください。
+ [Amazon EKS Pod Identity エージェントのセットアップ](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html)
+ [EKS Pod Identity ロールの作成](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)
## 仕組み
Pod Identity を使用すると、EKS クラスター内のアプリケーションから、ロールチェーンと呼ばれるプロセスを通じてアカウント間の AWS リソースにアクセスできます。
Pod Identity の関連付けを作成する際は、EKS クラスターと同じアカウント内にある [EKS Pod Identity ロール](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)と、アクセスしたいユーザーの AWS リソース (S3 バケットや RDS データベースなど) が含まれたアカウントのターゲット IAM ロールという 2 つの IAM ロールを指定できます。[IAM PassRole](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam-passrole-service.html) の要件により、[EKS Pod Identity ロール](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)は EKS クラスターのアカウント内に存在する必要がありますが、ターゲット IAM ロールは任意の AWS アカウントに存在できます。PassRole を使用すると、AWS エンティティはロールの引き受けを別のサービスに委任できます。EKS Pod Identity は PassRole を使用してロールを Kubernetes サービスアカウントに接続し、ロールとそれを渡す ID の両方が EKS クラスターと同じ AWS アカウントに存在する必要があります。アプリケーションポッドから AWS リソースにアクセスする必要がある場合、ポッドで Pod Identity の認証情報が要求されます。次に、Pod Identity は 2 つのロールの引き受けを順番に自動実行します。つまり、最初に [EKS Pod Identity ロール](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)を引き受け、次にその認証情報を使用してターゲット IAM ロールを引き受けます。このプロセスにより、ターゲットロールで定義されたアクセス許可を含む一時的な認証情報がポッドに提供され、他の AWS アカウントのリソースへの安全なアクセスが実現します。
## キャッシュに関する考慮事項
キャッシュメカニズムにより、既存の Pod Identity の関連付けで IAM ロールを更新しても、EKS クラスターで実行されているポッドですぐに有効にならない場合があります。Pod Identity エージェントは、認証情報の取得時に関連付けの設定に基づいて IAM 認証情報をキャッシュします。関連付けに [EKS Pod Identity ロール](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)のみが含まれ、ターゲット IAM ロールが含まれていない場合、キャッシュされた認証情報は 6 時間有効となります。関連付けに [EKS Pod Identity ロール](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) ARN とターゲット IAM ロールの両方が含まれている場合、キャッシュされた認証情報は 59 分間有効です。[EKS Pod Identity ロール](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) ARN の更新やターゲット IAM ロールの追加など、既存の関連付けを変更しても、既存のキャッシュはリセットされません。その結果、エージェントはキャッシュされた認証情報が更新されるまで更新を認識しません。変更をより迅速に適用するには、既存のポッドを再作成できます。再作成しない場合は、キャッシュの有効期限が切れるまで待機する必要があります。
## ステップ 1: ターゲット IAM ロールを作成して関連付ける
このステップでは、ターゲット IAM ロールを作成して設定することで、安全な信頼チェーンを確立します。デモンストレーションでは、2 つの AWS アカウント間で信頼チェーンを確立するための新しいターゲット IAM ロールを作成します。EKS クラスターの AWS アカウント内にある [EKS Pod Identity ロール](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) (例: `eks-pod-identity-primary-role`) で、ターゲットアカウントでターゲット IAM ロール (例：`eks-pod-identity-aws-resources`) を引き受ける権限を取得し、Amazon S3 バケットなどの AWS リソースへのアクセスを有効にします。
### ターゲット IAM ロールを作成する
1. [Amazon IAM コンソール](https://console.aws.amazon.com/iam/home)を開きます。
1. 上部のナビゲーションバーで、ターゲット IAM ロールの AWS リソース (S3 バケットや DynamoDB テーブルなど) を含むアカウントにサインインしていることを確認します。
1. 左のナビゲーションペインで、**[Roles (ロール)]** を選択してください。
1. **[ロールの作成]** ボタンを選択し、「信頼できるエンティティタイプ」の下にある **AWS** アカウントを選択します。
1. **別の AWS アカウント**を選択し、AWS のアカウント番号 ([EKS Pod Identity ロール](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)が存在するアカウント) を入力し、**[次へ]** を選択します。
1. ロールに関連付けるアクセス許可ポリシー (AmazonS3FullAccess など) を追加し、**[次へ]** を選択します。
1. 「`MyCustomIAMTargetRole`」などのロール名を入力し、**[ロールの作成]** を選択します。
### ターゲット IAM ロールの信頼ポリシーを更新する
1. ロールを作成すると、**[ロール]** リストに戻ります。前の手順で作成した新規ロールを検索し、選択します (例: `MyCustomIAMTargetRole`)。
1. **[信頼関係]** タブを選択します。
1. 右側の **[信頼ポリシーを編集]** をクリックします。
1. ポリシーエディタで、デフォルトの JSON を信頼ポリシーに置き換えます。IAM ロール ARN のロール名と `111122223333` のプレースホルダー値を、EKS クラスターをホストする AWS アカウント ID に置き換えます。オプションで、ロール信頼ポリシーの PrincipalTags を使用して、特定のクラスターと名前空間の特定のサービスアカウントのみがターゲットロールを引き受けることを許可することもできます。例えば、次のようになります。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/example-cluster",
"aws:RequestTag/kubernetes-namespace": "ExampleNameSpace",
"aws:RequestTag/kubernetes-service-account": "ExampleServiceAccountName"
},
"ArnEquals": {
"aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
}
}
}
]
}
```
上記のポリシーでは、関連する [EKS Pod Identity セッションタグ](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html)を持つ AWS アカウント 111122223333 のロール `eks-pod-identeity-primary-role` がこのロールを引き受けることを許可します。
EKS Pod Identity で[セッションタグを無効](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html#pod-id-abac-tags)にした場合、EKS Pod Identity は、ターゲットロールを引き受けるときに、ポッドのクラスター、名前空間、およびサービスアカウントに関する情報を `sts:ExternalId` に設定します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "region/111122223333/cluster-name/namespace/service-account-name"
},
"ArnEquals": {
"aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
}
}
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:TagSession"
}
]
}
```
上記のポリシーは、予想されるクラスター、名前空間、サービスアカウントのみがターゲットロールを引き受けることができるようにするのに役立ちます。
### EKS Pod Identity ロールのアクセス許可ポリシーを更新する
このステップでは、ターゲット IAM ロール ARN をリソースとして追加し、Amazon EKS クラスターに関連付けられた [EKS Pod Identity ロール](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)のアクセス許可ポリシーを更新します。
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで **[クラスター]** を選択し、次に EKS クラスターの名前を選択します。
1. **[リモートアクセス]** タブを選択してください。
1. **[Pod Identity の関連付け]** で、[[EKS Pod Identity ロール]](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) を選択します。
1. **[アクセス許可]**、**[許可を追加]** を選択し、次に **[インラインポリシーを作成]** をクリックします。
1. 右側で **[JSON]** を選択します。
1. ポリシーエディタで、デフォルトの JSON をアクセス許可ポリシーに置き換えます。IAM ロール ARN のロール名と `222233334444` のプレースホルダー値をターゲット IAM ロールに置き換えます。例えば、次のようになります。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Resource": "arn:aws:iam::222233334444:role/eks-pod-identity-aws-resources"
}
]
}
```
## ステップ 2: ターゲット IAM ロールを Kubernetes サービスアカウントに関連付ける
このステップでは、ターゲット IAM ロールと EKS クラスター内の Kubernetes サービスアカウントとの関連付けを作成します。
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで **[クラスター]** を選択し、次に関連付けを追加するクラスター名を選択します。
1. **[アクセス]** タブを選択します。
1. **[Pod Identity の関連付け]** で **[作成]** を選択します。
1. ワークロードが引き受ける **IAM ロール**の [EKS Pod Identity ロール](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)を選択します。
1. [EKS Pod Identity ロール](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)が引き受けるターゲット IAM ロールを **[ターゲット IAM ロール]** で選択します。
1. **[Kubernetes 名前空間]** フィールドに、関連付けを作成する名前空間の名前を入力します (例: `my-app-namespace`)。これにより、サービスアカウントが存在する場所が定義されます。
1. **[Kubernetes サービスアカウント]** フィールドに、IAM 認証情報を使用するサービスアカウントの名前 (例: `my-service-account`) を入力します。これにより、IAM ロールがサービスアカウントにリンクされます。
1. (オプション) **[セッションタグを無効にする]** を選択することで、Pod Identity がロールを引き受けるときに自動的に追加するデフォルトのセッションタグを無効にできます。
1. (オプション) **[セッションポリシーの設定]** を切り替えることで、**ターゲット IAM ロール**にアタッチされた IAM ポリシーで定義されているアクセス許可以外の追加制限を、この Pod Identity 関連付けに適用するように IAM ポリシーを設定できます。
**注記**
1. セッションポリシーは、**[セッションタグを無効にする]** の設定がチェックされている場合にのみ適用できます。2. セッションポリシーを指定すると、ポリシーの制限は、この Pod Identity の関連付けに関連付けられた **IAM ロール**ではなく、**ターゲット IAM ロール**のアクセス許可に適用されます。
1. **[作成]** を選択して関連付けを作成します。
# サービスアカウントを使用して AWS サービスにアクセスするように Pod を設定する
Pod が AWS サービスにアクセスする必要がある場合は、Kubernetes サービスアカウントを使用するように設定する必要があります。サービスアカウントは、AWS サービスにアクセスする権限がある AWS Identity and Access Management (IAM) ロールに関連付ける必要があります。
+ 既存のクラスター。まだ所有していない場合は、[Amazon EKS の使用を開始する](getting-started.md) でのガイドのいずれかを参照しながら作成できます。
+ 既存の Kubernetes サービスアカウントと、そのサービスアカウントを IAM ロールに関連付ける EKS Pod Identity 関連付け。ロールには、Pod が AWS サービスを使用するアクセス許可を含む IAM ポリシーが関連付けられている必要があります。サービスアカウントとロールの作成および設定方法については、「[IAM ロールを Kubernetes サービスアカウントに割り当てる](pod-id-association.md)」を参照してください。
+ ご使用のデバイスまたは AWS CloCloudShell に最新バージョンの AWS CLI がインストールおよび設定されていること。現在のバージョンは`aws --version | cut -d / -f2 | cut -d ' ' -f1` で確認できます。`yum`、`apt-get`、macOS 用の Homebrew などのパッケージマネージャーは、多くの場合 AWS CLI の最新バージョンより数バージョン古くなっています。最新バージョンをインストールするには、「AWS コマンドラインインターフェイスユーザーガイド」の「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」および「[aws configure を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。AWS CloudShell にインストールされている AWS CLI バージョンは、最新バージョンより数バージョン遅れている可能性もあります。更新するには、「AWS CloudShell ユーザーガイド」の「[ホームディレクトリへの AWS CLI のインストール](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)」を参照してください。
+ デバイスまたは AWS クラウドシェル に、`kubectl` コマンドラインツールがインストールされていること。バージョンはご使用のクラスターの Kubernetes バージョンと同じか、1 つ前のマイナーバージョン以前、あるいはそれより新しいバージョンが使用できます。例えば、クラスターのバージョンが `1.29` である場合、`kubectl` のバージョン `1.28`、`1.29`、または `1.30` が使用できます。`kubectl` をインストールまたはアップグレードする方法については「[`kubectl` および `eksctl` のセットアップ](install-kubectl.md)」を参照してください。
+ クラスター構成を含む既存の `kubectl` `config` ファイル。`kubectl` `config` ファイルの作成については、「[kubeconfig ファイルを作成して kubectl を EKS クラスターに接続する](create-kubeconfig.md)」を参照してください。
1. 次コマンドを使用して、Pod をデプロイして設定を確認できるデプロイマニフェストを作成します。example の値は独自の値に置き換えます。
```
cat >my-deployment.yaml <
属性ベースのアクセス制御 (ABAC) は、複数の属性をまとめたポリシーを利用して、ユーザーに権限を付与するものです。EKS Pod Identity は、クラスター名、名前空間、サービスアカウント名などの属性が含まれたタグを各 Pod の一時認証情報にアタッチします。これらのロールセッションタグを使用すると、管理者は一致するタグに基づいて AWS リソースへのアクセスを許可することで、複数のサービスアカウントで機能する単一のロールを作成できます。ロールセッションタグのサポートを追加することで、同じ IAM ロールと IAM ポリシーを再利用しながら、クラスター間およびクラスター内のワークロード間のセキュリティ境界を厳しくすることができます。
## タグ付きポリシーの例
以下は、対応するオブジェクトが EKS クラスター名でタグ付けされたときに `s3:GetObject` アクセス許可を付与する IAM ポリシーの例です。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:GetObjectTagging"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"s3:ExistingObjectTag/eks-cluster-name": "${aws:PrincipalTag/eks-cluster-name}"
}
}
}
]
}
```
## セッションタグを有効または無効にする
EKS Pod Identity で、ロールを引き受けるときに事前定義されたセッションタグのセットを追加します。これらのセッションタグを使用すると、管理者は一致するタグに基づいて AWS リソースへのアクセスを許可することで、リソース間で機能する単一のロールを作成できます。
### セッションタグを有効にする
セッションタグは EKS Pod Identity で自動的に有効になります。ユーザー側のアクションは必要ありません。デフォルトでは、EKS Pod Identity によって事前定義されたタグのセットがセッションにアタッチされます。ポリシーでこれらのタグを参照するには、`${aws:PrincipalTag/` 構文の後にタグキーを使用します。例えば、`${aws:PrincipalTag/kubernetes-namespace}`。
+ `eks-cluster-arn`
+ `eks-cluster-name`
+ `kubernetes-namespace`
+ `kubernetes-service-account`
+ `kubernetes-pod-name`
+ `kubernetes-pod-uid`
### セッションタグを無効にする
AWS では、インラインセッションポリシー、管理ポリシー ARN、およびセッションタグが、個別の制限を持つひとまとめのバイナリ形式に圧縮されます。ひとまとめのバイナリ形式がサイズ制限を超過したことを示す `PackedPolicyTooLarge` エラーが表示された場合は、EKS Pod Identity によって追加されたセッションタグを無効にすることでサイズを縮小できます。これらのセッションタグを無効にするには、次の手順に従います。
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで **[クラスター]** を選択し、次に修正するクラスターの名前を選択します。
1. **[リモートアクセス]** タブを選択してください。
1. **[Pod Identity の関連付け]** で、**[関連付け ID]** で変更する関連付け ID を選択し、**[編集]** を選択します。
1. **[セッションタグ]** で、**[セッションタグを無効にする]** を選択します。
1. **[Save changes]** (変更の保存) をクリックします。
## アカウント間のコピー
EKS Pod Identity によって追加されるセッションタグはすべて*推移的*です。タグのキーと値は、ワークロードがロールを別のアカウントに切り替えるために使用するすべての `AssumeRole` アクションに渡されます。これらのタグを他のアカウントのポリシーで使用して、クロスアカウントシナリオでのアクセスを制限できます。詳細については、「*IAM ユーザーガイド*」の「[セッションタグを使用したロールの連鎖](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html#id_session-tags_role-chaining)」を参照してください。
## カスタムタグ
EKS Pod Identity は、実行する `AssumeRole` アクションにカスタムタグを追加できません。ただし、IAM ロールに適用するタグは、常に同じ形式 (`${aws:PrincipalTag/MyCustomTag}` のように、`${aws:PrincipalTag/` の後にキーが続く) で使用できます。
**注記**
`sts:AssumeRole` リクエストによってセッションに追加されたタグは、競合が発生した場合に優先されます。例えば、次のように言います。
EKS が顧客ロールを引き継ぐときに Amazon EKS がセッションにキー `eks-cluster-name` と値 `my-cluster` を追加します。
また、値 `my-own-cluster` を含む IAM ロールに `eks-cluster-name` タグも追加します。
この場合は前者が優先され、`eks-cluster-name` タグの値は `my-cluster` になります。
# AWS SDK で Pod Identity を使用する
## EKS Pod Identity 認証情報の使用
EKS Pod Identity の関連付けからの認証情報を使用するには、コードで任意の AWS SDK を使用して SDK を使用する AWS サービスのクライアントを作成できます。デフォルトでは、SDK は使用する AWS Identity and Access Management 認証情報を一連の場所で検索します。クライアントの作成時や SDK の初期化時に認証情報プロバイダーを指定しなかった場合は、EKS Pod Identity 認証情報が使用されます。
これがうまくいくのは、EKS Pod Identity がデフォルトの認証情報チェーンのステップで検索されるコンテナ認証情報プロバイダーに追加されているからです。現在、ワークロードが認証情報チェーンの前にある認証情報を使用している場合は、同じワークロードに EKS Pod Identity の関連付けを設定しても、その認証情報は引き続き使用されます。
EKS Pod Identity の仕組みの詳細については、「[EKS Pod Identity の仕組みを理解する](pod-id-how-it-works.md)」を参照してください。
「[Learn how EKS Pod Identity grants pods access to AWS services](pod-identities.md)」に従うと、Pod 内のコンテナでは EKS Pod Identity エージェントからの IAM ロールの引き受けをサポートする AWS SDK バージョンを使用する必要があります。お使いの AWS SDK には、必ず次のバージョン以降を使用してください。
+ Java (バージョン 2) – [2.21.30](https://github.com/aws/aws-sdk-java-v2/releases/tag/2.21.30)
+ Java – [1.12.746](https://github.com/aws/aws-sdk-java/releases/tag/1.12.746)
+ [バージョン1に移動 – v1.47.11](https://github.com/aws/aws-sdk-go/releases/tag/v1.47.11)
+ [バージョン 2 に移動 – 2023-11-14 リリース](https://github.com/aws/aws-sdk-go-v2/releases/tag/release-2023-11-14)
+ Python (Boto3) – [1.34.41](https://github.com/boto/boto3/releases/tag/1.34.41)
+ Python (botocore) – [1.34.41](https://github.com/boto/botocore/releases/tag/1.34.41)
+ AWS CLI – [1.30.0](https://github.com/aws/aws-cli/releases/tag/1.30.0)
AWS CLI – [2.15.0](https://github.com/aws/aws-cli/releases/tag/2.15.0)
+ JavaScript v2 – [2.1550.0](https://github.com/aws/aws-sdk-js/releases/tag/v2.1550.0)
+ JavaScript v3 – [v3.458.0](https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.458.0)
+ Kotlin – [v1.0.1](https://github.com/awslabs/aws-sdk-kotlin/releases/tag/v1.0.1)
+ Ruby – [3.188.0](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md#31880-2023-11-22)
+ Rust – [release-2024-03-13](https://github.com/awslabs/aws-sdk-rust/releases/tag/release-2024-03-13)
+ C\$1\$1 – [1.11.263](https://github.com/aws/aws-sdk-cpp/releases/tag/1.11.263)
+ .NET – [3.7.734.0](https://github.com/aws/aws-sdk-net/releases/tag/3.7.734.0)
+ PowerShell – [4.1.502](https://www.powershellgallery.com/packages/AWS.Tools.Common/4.1.502)
+ PHP – [3.289.0](https://github.com/aws/aws-sdk-php/releases/tag/3.287.1)
サポートされている SDK を使用していることを確認するには、コンテナを構築する際に、「[AWS での構築ツール](https://aws.amazon.com/tools/)」で、希望する SDK のインストール手順に従ってください。
EKS Pod Identity をサポートするアドオンのリストについては、「[Pod Identity サポートリファレンス](retreive-iam-info.md#pod-id-add-on-versions)」を参照してください。
# EKS Pod Identity エージェントで `IPv6` を無効にする
## AWS マネジメントコンソール
1. EKS Pod Identity エージェントで `IPv6` を無効にするには、EKS アドオンの **[オプション設定]** に次の設定を追加します。
1. [アマゾン EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで、**[クラスター]** を選択し、次にアドオンを設定するクラスター名を選択してください。
1. **[アドオン]** タブを選択してください。
1. EKS Pod Identity エージェントのアドオンボックスの右上にあるボックスを選択し、**[編集]** を選択します。
1. **EKS Pod Identity エージェントの設定**ページの場合:
1. 使用する **[バージョン]** を選択します。前のステップと同じバージョンを保持し、別のアクションでバージョンと設定を更新することをお勧めします。
1. **[オプションの構成設定]** を展開します。
1. **[設定値]** で JSON キー `"agent":` とにネストした JSON オブジェクトの値に、キー `"additionalArgs":` を指定します。結果のテキストは有効な JSON オブジェクトでなければなりません。このキーと値だけがテキストボックス内のデータである場合はキーと値を中括弧 `{ }` で囲みます。次の例はネットワークポリシーが有効になっていることを示しています：
```
{
"agent": {
"additionalArgs": {
"-b": "169.254.170.23"
}
}
}
```
この設定では、エージェントが使用する唯一のアドレスに `IPv4` アドレスを設定します。
1. EKS Pod Identity エージェントのポッドを置き換えて新しい設定を適用するには、**[変更を保存]** を選択します。
Amazon EKS は、EKS Pod Identity エージェントの Kubernetes `DaemonSet` の*ロールアウト*を使用して EKS アドオンに変更を適用します。ロールアウトのステータスはAWS マネジメントコンソール のアドオン **[更新履歴]** と `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system` で追跡できます。
`kubectl rollout` は以下のコマンドを実行してください：
```
$ kubectl rollout
history -- View rollout history
pause -- Mark the provided resource as paused
restart -- Restart a resource
resume -- Resume a paused resource
status -- Show the status of the rollout
undo -- Undo a previous rollout
```
ロールアウトに時間がかかりすぎる場合、Amazon EKS はロールアウトを取り消し、**[アドオン更新]** のタイプと **[失敗]** のステータスのメッセージがアドオンの **[更新履歴]** に追加されます。問題を調査するには、ロールアウトの履歴から開始し、EKS Pod Identity エージェントのポッドで `kubectl logs` を実行して EKS Pod Identity エージェントのログを確認します。
1. **[更新履歴]** の新しいエントリのステータスが **[成功]** の場合、ロールアウトが完了し、アドオンはすべての EKS Pod Identity エージェントのポッドで新しい設定を使用していることを意味します。
## AWS CLI
1. EKS Pod Identity エージェントで `IPv6` を無効にするには、EKS アドオンの **[オプション設定]** に次の設定を追加します。
次の AWS CLI コマンドを実行します。`my-cluster` をクラスターの名前に置き換え、IAM ロール ARN を使用するロールに置き換えます。
```
aws eks update-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent \
--resolve-conflicts PRESERVE --configuration-values '{"agent":{"additionalArgs": { "-b": "169.254.170.23"}}}'
```
この設定では、エージェントが使用する唯一のアドレスに `IPv4` アドレスを設定します。
Amazon EKS は、EKS Pod Identity エージェントの Kubernetes DaemonSet の*ロールアウト*を使用して EKS アドオンに変更を適用します。ロールアウトのステータスはAWS マネジメントコンソール のアドオン **[更新履歴]** と `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system` で追跡できます。
`kubectl rollout` は以下のコマンドを実行してください：
```
kubectl rollout
history -- View rollout history
pause -- Mark the provided resource as paused
restart -- Restart a resource
resume -- Resume a paused resource
status -- Show the status of the rollout
undo -- Undo a previous rollout
```
ロールアウトに時間がかかりすぎる場合、Amazon EKS はロールアウトを取り消し、**[アドオン更新]** のタイプと **[失敗]** のステータスのメッセージがアドオンの **[更新履歴]** に追加されます。問題を調査するには、ロールアウトの履歴から開始し、EKS Pod Identity エージェントのポッドで `kubectl logs` を実行して EKS Pod Identity エージェントのログを確認します。
# EKS Pod Identity で必須の信頼ポリシーを使用して IAM ロールを作成する
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
** `sts:AssumeRole` **
EKS Pod Identity は一時的な認証情報をポッドに渡す前に、`AssumeRole` を使用して IAM ロールを引き継ぎます。
** `sts:TagSession` **
EKS Pod Identity は、AWS STS へのリクエストにセッションタグを含めるために `TagSession` を使用します。
**条件の設定**
これらのタグを信頼ポリシーの*条件キー*で使用して、このロールを使用できるサービスアカウント、名前空間、およびクラスターを制限できます。Pod Identity が追加するリクエストタグのリストについては、「[セッションタグを有効または無効にする](pod-id-abac.md#pod-id-abac-tags)」を参照してください。
例えば、追加した `Condition` に以下の信頼ポリシーを指定して、Pod Identity IAM ロールを引き受けることができるポッドを特定の `ServiceAccount` および `Namespace` に限定できます。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/kubernetes-namespace": [
"Namespace"
],
"aws:RequestTag/kubernetes-service-account": [
"ServiceAccount"
]
}
}
}
]
}
```
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)」を参照してください。