**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# Amazon EKS のセキュリティ
AWS では、クラウドのセキュリティが最優先事項です。セキュリティを最も重視する組織の要件を満たすために構築された 「AWS」 のデータセンターとネットワークアーキテクチャは、お客様に大きく貢献します。
セキュリティは、「AWS」 と顧客の間の責任共有です。[共有責任モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)では、これをクラウド*の*セキュリティおよびクラウド*内*のセキュリティとして説明しています。
+ **クラウドのセキュリティ** – AWS は、AWS クラウドで AWS のサービスを実行するインフラストラクチャを保護する責任を担います。Amazon EKS において、AWS は Kubernetes コントロールプレーンの責任を分担しており、この範囲にはコントロールプレーンノードと `etcd` データベースが含まれています。[AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)の一環として、サードパーティーの監査が定期的にセキュリティの有効性をテストおよび検証しています。Amazon EKS に適用されるコンプライアンスプログラムについては、「[コンプライアンスプログラムによる対象範囲内の AWS サービス](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。
+ **クラウド内のセキュリティ** – お客様の責任事項には、次の領域が含まれます。
+ データプレーンのセキュリティ設定。これには、Amazon EKS コントロールプレーンからお客様の VPC 内へのトラフィックの通過を許可する、セキュリティグループの設定を含みます。
+ ノードおよびコンテナに対する設定。
+ ノードのオペレーティングシステム (更新やセキュリティパッチを含みます)
+ その他の関連アプリケーションソフトウェア :
+ ファイアウォールのルールなど、ネットワークコントロールの設定および管理。
+ IAM を使用する、またはそれに追加して行う、Identity and Access Managementのプラットフォームレベルの管理。
+ お客様のデータの機密性、企業の要件、該当する法律および規制
Amazon EKS は、規制対象および機密性の高いアプリケーションの複数のコンプライアンスプログラムで認定されています。Amazon EKS は、[SOC](https://aws.amazon.com/compliance/soc-faqs/)、[PCI](https://aws.amazon.com/compliance/pci-dss-level-1-faqs/)、[ISO](https://aws.amazon.com/compliance/iso-certified/)、[FedRAMP-Moderate](https://aws.amazon.com/compliance/fedramp/)、[IRAP](https://aws.amazon.com/compliance/irap/)、[C5](https://aws.amazon.com/compliance/bsi-c5/)、[K-ISMS](https://aws.amazon.com/compliance/k-isms/)、[ENS High](https://aws.amazon.com/compliance/esquema-nacional-de-seguridad/)、[OSPAR](https://aws.amazon.com/compliance/OSPAR/)、[HITRUST CSF](https://aws.amazon.com/compliance/hitrust/) に準拠しており、[HIPAA](https://aws.amazon.com/compliance/hipaa-compliance/) 対象サービスです。詳細については、「[Amazon EKS でのアクセスコントロールの仕組みについて説明します。](cluster-auth.md)」を参照してください。
このドキュメントは、Amazon EKS を使用する際の責任共有モデルの適用について理解するのに役立ちます。以下のトピックで、セキュリティおよびコンプライアンスの目的を満たすように、Amazon EKS を設定する方法について説明します。Amazon EKS リソースのモニタリングやセキュリティ確保に役立つ他の AWS サービスの使用方法についても説明します。
**注記**
Linux コンテナはコントロールグループ (cgroup) と名前空間で構成されています。これらにより、コンテナのアクセスが可能な対象を制限しながら、すべてのコンテナに、ホストの Amazon EC2 インスタンスと同じ Linux カーネルを共有させることができます。コンテナをルートユーザー (UID 0) として実行したり、ホストリソースや (ホストネットワークやホスト PID の) 名前空間へのアクセスをコンテナに許可したりすることは一切お勧めしません。これは、コンテナが提供する分離の有効性を低下させます。
**Topics**
+ [ベストプラクティスによる Amazon EKS クラスターの保護](security-best-practices.md)
+ [Amazon EKS の脆弱性を分析する](configuration-vulnerability-analysis.md)
+ [Amazon EKS クラスターのコンプライアンス検証](compliance.md)
+ [アマゾン エラスティックKubernetesサービス のセキュリティに関する考慮事項](security-eks.md)
+ [Kubernetes のセキュリティに関する考慮事項](security-k8s.md)
+ [Amazon EKS Auto Mode におけるセキュリティに関する考慮事項](auto-security.md)
+ [EKS 機能のセキュリティに関する考慮事項](capabilities-security.md)
+ [Amazon EKS の Identity and Access Management](security-iam.md)
# ベストプラクティスによる Amazon EKS クラスターの保護
Amazon EKS でのセキュリティのベストプラクティスは、「Amazon EKS のベストプラクティスガイド」の「[セキュリティのベストプラクティス](https://docs.aws.amazon.com/eks/latest/best-practices/security.html)」に記載されています。
# Amazon EKS の脆弱性を分析する
セキュリティは、Kubernetes クラスターとアプリケーションの設定や管理を行う際の重要な考慮事項です。以下に、EKS クラスターのセキュリティ設定を分析するためのリソース、脆弱性をチェックするためのリソース、およびその分析を実行できる AWS サービスとの統合を示します。
## Amazon EKS 用 Center for Internet Security (CIS) ベンチマーク
[Center for Internet Security (CIS) Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) では、Amazon EKS のセキュリティ設定に関するガイダンスを提供しています。ベンチマーク:
+ ユーザーが Kubernetes コンポーネントのセキュリティ設定を担当する (マネージド型とセルフマネージド型の両方の) Amazon EC2 ノードに適用されます。
+ Amazon EKS の使用時に Kubernetes クラスターとノードを安全に設定できるように、コミュニティが承認した標準的な方法を提供します。
+ これは、コントロールプレーンでのログ記録の設定、ノードのセキュリティ設定、ポリシー、マネージド型サービスの 4 つのセクションで構成されます。
+ Amazon EKS で現在入手可能なすべての Kubernetes バージョンをサポートし、[kube-bench](https://github.com/aquasecurity/kube-bench) (Kubernetes クラスターで CIS ベンチマークを使用して構成をチェックするための標準的なオープンソースのツール) により実行されます。
詳細については、「[Introducing The CIS Amazon EKS Benchmark (CIS Amazon EKSベンチマークの紹介)](https://aws.amazon.com/blogs/containers/introducing-cis-amazon-eks-benchmark)」を参照してください。
CIS ベンチマークされた AMI でノードグループを更新する自動 `aws-sample` パイプラインについては、「[EKS-Optimized AMI Hardening Pipeline](https://github.com/aws-samples/pipeline-for-hardening-eks-nodes-and-automating-updates)」を参照してください。
## Amazon EKS のプラットフォームバージョン
Amazon EKS *プラットフォームのバージョン*は、クラスターコントロールプレーンの機能を表しています。これには、Kubernetes API サーバーでどのフラグが有効であるかや、現在の Kubernetes パッチバージョンなどの情報が含まれます。新しいクラスターは、最新のプラットフォームバージョンでデプロイされます。詳細については、「[EKS platform-versions](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html)」を参照してください。
[Amazon EKS クラスター](update-cluster.md)を更新し、新しい Kubernetes バージョンにすることができます。新しい Kubernetes バージョンが Amazon EKS で利用可能になったら、利用可能な最新のバージョンが使用できるように、クラスターをタイムリーに更新することをお勧めします。EKS での Kubernetes バージョンの詳細については、「[Amazon EKS supported versions](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)」を参照してください。
## オペレーティングシステムの脆弱性リスト
### AL2023 脆弱性リスト
[Amazon Linux セキュリティセンター](https://alas.aws.amazon.com/alas2023.html)で Amazon Linux 2023 のセキュリティイベントまたはプライバシーイベントを追跡するか、関連する [RSS フィード](https://alas.aws.amazon.com/AL2023/alas.rss)をサブスクライブします。セキュリティおよびプライバシーイベントには、影響を受ける問題の概要、パッケージ、および問題を修正するためにインスタンスを更新する手順などがあります。
### Amazon Linux 2 脆弱性リスト
[Amazon Linux セキュリティセンター](https://alas.aws.amazon.com/alas2.html)で Amazon Linux 2 のセキュリティイベントまたはプライバシーイベントを追跡するか、関連する [RSS フィード](https://alas.aws.amazon.com/AL2/alas.rss)をサブスクライブします。セキュリティおよびプライバシーイベントには、影響を受ける問題の概要、パッケージ、および問題を修正するためにインスタンスを更新する手順などがあります。
## Amazon Inspector によるノード検出
[Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_introduction.html) を使用すると、ノードからネットワークに意図しない接続が可能か、また、それらの Amazon EC2 インスタンスに脆弱性があるかを確認できます。
## Amazon GuardDuty によるクラスターとノードの検出
Amazon GuardDuty は、AWS 環境内のアカウント、コンテナ、ワークロード、データを保護する脅威検知サービスです。GuardDuty には、EKS クラスターに対する潜在的な脅威を検出する EKS Protection とランタイムモニタリングの 2 つの機能があります。
詳細については、「[Amazon GuardDuty で脅威を検出する](integration-guardduty.md)」を参照してください。
# Amazon EKS クラスターのコンプライアンス検証
AWS のサービスが特定のコンプライアンスプログラムの対象であるかどうかを確認するには、「[コンプライアンスプログラムによる対象範囲内の AWS サービス](https://aws.amazon.com/compliance/services-in-scope/)」をご覧いただき、関心のあるコンプライアンスプログラムを選択してください。一般的な情報については、「[AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)」を参照してください。
サードパーティーの監査報告書は、AWS アーティファクトを使用してダウンロードすることができます。詳細については、「[Downloading reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)」を参照してください。
AWS のサービスの使用時におけるユーザーのコンプライアンス責任は、データの機密性、企業のコンプライアンス目的、適用法と規制に応じて異なります。AWS は、コンプライアンスに役立つ以下のリソースを提供しています。
+ [セキュリティのコンプライアンスとガバナンス](https://aws.amazon.com/solutions/security/security-compliance-governance/) – これらのソリューション実装ガイドでは、アーキテクチャ上の考慮事項について説明し、セキュリティとコンプライアンスの機能をデプロイする手順を示します。
+ [HIPAA 対応サービスのリファレンス](https://aws.amazon.com/compliance/hipaa-eligible-services-reference/) – HIPAA 対応サービスの一覧が提供されています。すべての AWS のサービスが HIPAA 対象であるわけではありません。
+ [AWS コンプライアンスのリソース](https://aws.amazon.com/compliance/resources/) - このワークブックとガイドのコレクションは、お客様の業界や所在地に適用される場合があります。
+ [AWS Customer Compliance Guide](https://d1.awsstatic.com/whitepapers/compliance/AWS_Customer_Compliance_Guides.pdf) - コンプライアンスの観点から見た責任共有モデルを理解できます。このガイドは、AWS のサービスを保護するためのベストプラクティスを要約したものであり、複数のフレームワーク (米国標準技術研究所 (NIST)、ペイメントカード業界セキュリティ標準評議会 (PCI)、国際標準化機構 (ISO) など) にわたるセキュリティ統制へのガイダンスがまとめられています。
+ AWS Config デベロッパーガイドの「[ルールでのリソースの評価](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)」 – AWS Config サービスは、リソースの設定が内部規定、業界のガイドライン、規制にどの程度適合しているかを評価します。
+ [AWS セキュリティハブ](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) – この AWS サービスは、AWS 内のセキュリティ状態に関する包括的なビューを提供します。Security Hub では、セキュリティコントロールを使用して AWS リソースを評価し、セキュリティ業界標準とベストプラクティスに対するコンプライアンスをチェックします。サポートされているサービスとコントロールの一覧については、[Security Hub のコントロールリファレンス](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html)を参照してください。
+ [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html) – この AWS サービスは、環境をモニタリングして、疑わしいアクティビティや悪意のあるアクティビティがないか調べることで、AWS アカウント、ワークロード、コンテナ、データに対する潜在的な脅威を検出します。GuardDuty を使用すると、特定のコンプライアンスフレームワークで義務付けられている侵入検知要件を満たすことで、PCI DSS などのさまざまなコンプライアンス要件に対応できます。
+ [AWSAudit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html)– この AWS サービスでは、AWS の使用状況を継続的に監査し、リスクの管理方法と、規制や業界標準へのコンプライアンスの管理方法を簡素化できます。
# アマゾン エラスティックKubernetesサービス のセキュリティに関する考慮事項
以下はアマゾン EKS に影響するため、クラウドのセキュリティに関する考慮事項です。
**Topics**
+ [Amazon EKS でのインフラストラクチャセキュリティ](infrastructure-security.md)
+ [Amazon EKS クラスターの耐障害性の説明](disaster-recovery-resiliency.md)
+ [Amazon EKS におけるサービス間の混乱した代理の防止](cross-service-confused-deputy-prevention.md)
# Amazon EKS でのインフラストラクチャセキュリティ
マネージドサービスの Amazon Elastic Kubernetes Service は、AWS グローバルネットワークセキュリティによって保護されています。AWS セキュリティサービスと AWS がインフラストラクチャを保護する方法については「[AWS クラウドセキュリティ](https://aws.amazon.com/security/)」を参照してください。インフラストラクチャセキュリティのベストプラクティスを使用して AWS 環境を設計するには「*セキュリティの柱 - AWS 適切なアーキテクチャを備えたフレームワーク*」の「[インフラストラクチャの保護](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)」を参照してください。
AWS が公開している API コールを使用し、ネットワーク経由で Amazon EKS にアクセスします。クライアントは以下をサポートする必要があります。
+ Transport Layer Security (TLS)。TLS 1.2 が必須で、TLS 1.3 をお勧めします。
+ DHE (楕円ディフィー・ヘルマン鍵共有) や ECDHE (楕円曲線ディフィー・ヘルマン鍵共有) などの完全前方秘匿性 (PFS) による暗号スイート。これらのモードはJava 7 以降など、ほとんどの最新システムでサポートされています。
また、リクエストにはアクセスキー ID と、IAM プリンシパルに関連付けられているシークレットアクセスキーを使用して署名する必要があります。または、[AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) (AWS STS) で一時的なセキュリティ認証情報を生成して、リクエストに署名することもできます。
Amazon EKS のクラスターの作成時には、使用するクラスターの VPC サブネットを指定します。Amazon EKS には、2 つ以上のアベイラビリティーゾーンにサブネットが必要です。パブリックサブネットとプライベートサブネットを持つ VPC をお勧めします。これにより、Kubernetes がパブリックサブネットにパブリックロードバランサーを作成し、プライベートサブネットにあるノードで実行されている Pod へのトラフィックを負荷分散します。
VPC に関する考慮事項の詳細については、「」を参照してください[VPC とサブネットの Amazon EKS ネットワーキング要件を表示する](network-reqs.md)
チュートリアル「[Amazon EKS の使用を開始する](getting-started.md)」で提供されている AWS CloudFormation テンプレートを使用して VPC およびノードグループを作成した場合、コントロールプレーンとノードのセキュリティグループは推奨設定で構成されます。
セキュリティグループの考慮事項の詳細については、「」を参照してください[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)
新しいクラスターを作成すると、Amazon EKS によってマネージド型の Kubernetes API サーバーのエンドポイントが作成されます。ユーザーはこのエンドポイントを、(`kubectl` などの Kubernetes 管理ツールにより) クラスターとの通信に使用します。デフォルトでは、この API サーバーエンドポイントはインターネットに公開されます。API サーバーへのアクセスの保護には、AWS Identity and Access Management (IAM) と、ネイティブの Kubernetes [ロールベースアクセスコントロール](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) が組み合わせて使用されます。
Kubernetes API サーバーへのプライベートアクセスを有効にすると、ノードと API サーバー間のすべての通信が VPC 内で行われるようになります。インターネットから API サーバーにアクセスできる IP アドレスを制限したり、API サーバーへのインターネットアクセスを完全に無効にしたりできます。
クラスターエンドポイントアクセスの変更の詳細については、「」を参照してください[クラスターエンドポイントのアクセスの変更](cluster-endpoint.md#modify-endpoint-access)
Amazon VPC CNI を使用するか、[Project Calico](https://docs.tigera.io/calico/latest/about/) などのサードパーティーツールを使用して、Kubernetes *ネットワークポリシー*を実装できます。Amazon VPC CNI をネットワークポリシーに使用する方法の詳細については、「[Kubernetes ネットワークポリシーにより Pod トラフィックを制限する](cni-network-policy.md)」を参照してください。Project Calico はサードパーティのオープンソースプロジェクトです。詳細については、[Project Calico のドキュメント](https://docs.tigera.io/calico/latest/getting-started/kubernetes/managed-public-cloud/eks/)を参照してください。
# AWS プライベートリンクを使用して Amazon EKS にアクセスする
AWS プライベートリンク を使用して、VPC と Amazon Elastic Kubernetes Service 間にプライベート接続を作成できます。インターネットゲートウェイ、NAT デバイス、VPN 接続、AWS Direct Connect 接続のいずれかを使用せずに、VPC 内にあるかのように Amazon EKS にアクセスできます。VPC のインスタンスはパブリック IP アドレスがなくても Amazon EKS にアクセスできます。
AWS プライベートリンク が電源を供給するインターフェイスエンドポイントを作成することにより、このプライベート接続を確立します。インターフェイスエンドポイントに対して有効にする各サブネットにエンドポイントネットワークインターフェイスを作成します。これらはAmazon EKS 宛てのトラフィックのエントリポイントとして機能するリクエスタ管理型ネットワークインターフェイスです。
詳細については「AWS プライベートリンク ガイド」の「[AWS プライベートリンク を介した AWS サービスへのアクセス](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)」を参照してください。
## [開始する前に]
始める前に、次のタスクを実行していることを確認してください。
+ 「* AWS PrivateLink ガイド*」の「[インターフェイス VPC エンドポイントを使用した AWS サービスへのアクセス](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints)」を確認する
## 考慮事項
+ **サポートと制限**: Amazon EKS のインターフェイスエンドポイントは、VPC からのすべての Amazon EKS API アクションへの安全なアクセスを可能にしますが、特定の制限があります。Kubernetes API へのアクセスはサポートされません。Kubernetes API は個別のプライベートエンドポイントがあるため、インターフェイスエンドポイントを介してのみアクセスできるように Amazon EKS を設定することはできません。
+ **料金**: Amazon EKS のインターフェイスエンドポイントを使用すると、標準の AWS PrivateLink 料金 (各アベイラビリティーゾーンでプロビジョニングされた各エンドポイントの時間単位の料金と、エンドポイントを経由するトラフィックのデータ処理料金) が発生します。詳細については、「[AWS PrivateLink の料金](https://aws.amazon.com/privatelink/pricing/)」を参照してください。
+ **セキュリティとアクセスコントロール**: セキュリティを強化し、アクセスを制御するために、以下の追加設定を推奨します。VPC エンドポイントポリシーを使用し、インターフェイスエンドポイントを介して Amazon EKS へのアクセスを制御し、エンドポイントネットワークインターフェイスにセキュリティグループを関連付けてトラフィックを管理し、VPC フローログを使用してインターフェイスエンドポイントを行き来する IP トラフィックをキャプチャおよびモニタリングし、ログを Amazon CloudWatch または Amazon S3 に発行できるようにします。詳細については、「[エンドポイントポリシーを使用して VPC エンドポイントへのアクセスを制御する](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)」および「[VPC フローログを使用した IP トラフィックのログ記録](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)」を参照してください。
+ **接続オプション**: インターフェイスエンドポイントは、**オンプレミスアクセス** (AWS Direct Connect または AWS Site-to-Site VPN を使用してインターフェイスエンドポイントを持つ VPC にオンプレミスデータセンターを接続する) の使用または **VPC 間接続** (AWS Transit Gateway または VPC ピアリングを使用して、インターフェイスエンドポイントを持つ VPC に他の VPC を接続し、トラフィックを AWS ネットワーク内に留める) を介して柔軟な接続オプションを実現します。
+ **IP バージョンのサポート**: 2024 年 8 月より前に作成されたエンドポイントは、eks.region.amazonaws.com を使用した IPv4 のみをサポートします。2024 年 8 月以降に作成された新規エンドポイントは、デュアルスタック IPv4 および IPv6 (eks.region.amazonaws.com や eks.region.api.aws など) をサポートしています。
+ **リージョン別可用性**: EKS API の AWS PrivateLink は、アジアパシフィック (マレーシア) (ap-southeast-5)、アジアパシフィック (タイ) (ap-southeast-7)、メキシコ (中部) (mx-central-1)、アジアパシフィック (台北) (ap-east-2) のリージョンでは使用できません。 AWSEKS-auth (EKS Pod Identity) の PrivateLink サポートは、アジアパシフィック (マレーシア) (ap-southeast-5) リージョンで利用できます。
## Amazon EKS 用のインターフェイスエンドポイントを作成します
Amazon VPC コンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用して、Amazon EKS のインターフェイスエンドポイントを作成できます。詳細については『AWS プライベートリンク ガイド』の「[VPC エンドポイントを作成](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws)」を参照してください。
次のサービス名を使用して Amazon EKS のインターフェイスエンドポイントを作成します:
### EKS API
+ com.amazonaws.region-code.eks
+ com.amazonaws.region-code.eks-fips (FIPS 準拠のエンドポイントの場合)
### EKS Auth API (EKS Pod Identity)
+ com.amazonaws.region-code.eks-auth
## Amazon EKS インターフェイスエンドポイントのプライベート DNS 機能
Amazon EKS およびその他の AWS サービスのインターフェイスエンドポイントに対してデフォルトで有効になっているプライベート DNS 機能は、デフォルトのリージョン DNS 名を使用して安全でプライベートな API リクエストを容易にします。この機能により、API コールがプライベート AWS ネットワーク経由でインターフェイスエンドポイントを通じてルーティングされ、セキュリティおよびパフォーマンスが向上します。
Amazon EKS または他の AWS サービスのインターフェイスエンドポイントを作成すると、プライベート DNS 機能は自動的にアクティブ化されます。有効にするには、特定の属性を設定して VPC を正しく設定する必要があります。
+ **enableDnsHostnames**: VPC 内のインスタンスに DNS ホスト名を付けることができます。
+ **enableDnsSupport**: VPC 全体で DNS 解決を有効にします。
これらの設定を確認または変更する手順については、「[VPC の DNS 属性の表示と更新](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating)」を参照してください。
### DNS 名と IP アドレスタイプ
プライベート DNS 機能を有効にすると、特定の DNS 名を使用して Amazon EKS に接続でき、これらのオプションは時間の経過とともに進化します。
+ **eks.region.amazonaws.com**: 2024 年 8 月より前に IPv4 アドレスにのみ解決される従来の DNS 名。デュアルスタックに更新された既存のエンドポイントの場合、この名前は IPv4 アドレスおよび IPv6 アドレスの両方に解決されます。
+ **eks.region.api.aws**: 2024 年 8 月以降に作成された新規エンドポイントに利用できるこのデュアルスタック DNS 名は、IPv4 アドレスおよび IPv6 アドレスの両方に解決されます。
2024 年 8 月以降、新規のインターフェイスエンドポイントには 2 つの DNS 名があり、デュアルスタック IP アドレスタイプを選択できます。既存のエンドポイントの場合、デュアルスタックに更新すると、IPv4 および IPv6 の両方をサポートするように **eks.region.amazonaws.com** が変更されます。
### プライベート DNS 機能の使用
設定が完了したら、プライベート DNS 機能をワークフローに統合して次の機能が実現されます。
+ **API リクエスト**: エンドポイントの設定に基づいて `eks.region.amazonaws.com` または `eks.region.api.aws` のいずれかのデフォルトリージョン DNS 名を使用し、Amazon EKS に API リクエストを行います。
+ **アプリケーションの互換性**: EKS API を呼び出す既存のアプリケーションは、この機能を活用するために変更する必要はありません。
+ **AWS CLI とデュアルスタックの併用**: デュアルスタックエンドポイントを AWS CLI と使用するには、「* AWS SDK とツールリファレンスガイド*」の「[デュアルスタックと FIPS エンドポイント](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html)」の設定を参照してください。
+ **自動ルーティング**: Amazon EKS のデフォルトサービスエンドポイントへの呼び出しはインターフェイスエンドポイントを介して自動的に転送されるため、プライベートで安全な接続が保証されます。
# Amazon EKS クラスターの耐障害性の説明
AWS のグローバルインフラストラクチャは、AWS リージョンとアベイラビリティーゾーンを中心として構築されています。AWSリージョンには、低レイテンシー、高いスループット、そして高度の冗長ネットワークで接続されている複数の物理的に独立し隔離されたアベイラビリティーゾーンがあります。アベイラビリティーゾーンでは、アベイラビリティーゾーン間で中断せずに、自動的にフェイルオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、耐障害性、および拡張性が優れています。
Amazon EKS は、複数の AWS アベイラビリティーゾーンで Kubernetes コントロールプレーンインスタンスを実行およびスケーリングして、高可用性を実現します。Amazon EKS は、負荷に基づいてコントロールプレーンインスタンスを自動的にスケーリングします。また、異常なコントロールプレーンインスタンスを自動的に検出して置換し、そのコントロールプレーンに自動的にパッチを適用します。バージョン更新を開始すると、Amazon EKS によってコントロールプレーンが自動的に更新され、更新中のコントロールプレーンの高可用性が維持されます。
このコントロールプレーンは、少なくとも 2 つの API サーバーインスタンスと、(1 つの AWS リージョンで 3 つのアベイラビリティーゾーンにまたがっている) 3 つの `etcd` インスタンスを含みます。Amazon EKS:
+ コントロールプレーンインスタンスの負荷をアクティブに監視し、高パフォーマンスを確保するために、それらのインスタンスを自動的にスケーリングします。
+ 異常なコントロールプレーンインスタンスを自動的に検出して置換します。それらのコントロールプレーンインスタンスは、必要に応じて AWS リージョン内のアベイラビリティーゾーンで再起動されます。
+ 高可用性を維持するために、AWS リージョンのアーキテクチャを活用します。そのため、Amazon EKS では [API サーバーエンドポイント向けの可用性の SLA](https://aws.amazon.com/eks/sla) をご利用いただけます。
AWS リージョンとアベイラビリティーゾーンの詳細については、「[AWSグローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください。
# Amazon EKS におけるサービス間の混乱した代理の防止
混乱した代理問題とは、あるアクションを実行する許可を持たないエンティティが、より多くの特権を持つエンティティにアクションの実行を強制できることで生じるセキュリティ上の問題です。AWS では、サービス間でのなりすましによって、混乱した代理問題が発生する場合があります。サービス間でのなりすましは、1 つのサービス (呼び出し元サービス) が、別のサービス (呼び出し対象サービス) を呼び出すときに発生する可能性があります。呼び出し元サービスが操作され、それ自身のアクセス許可が使用されて、本来アクセス許可が付与されるべきではない方法により、別の顧客のリソースに影響を与える可能性があります。これを防ぐために、AWS には、アカウント内のリソースへのアクセス権が付与されたサービスプリンシパルですべてのサービスのデータを保護するために役立つツールが用意されています。
リソースポリシー内では [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) および [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) のグローバル条件コンテキストキーを使用して、Amazon Elastic Kubernetes Service (Amazon EKS) が別のサービスに付与する、リソースへのアクセス許可を制限することをお勧めします。
`aws:SourceArn`
1 つのリソースだけをクロスサービスのアクセスに関連付ける場合は、`aws:SourceArn` を使用します。
`aws:SourceAccount`
アカウント内の任意のリソースをクロスサービスの使用に関連付ける場合は、`aws:SourceAccount` を使用します。
混乱した代理問題から保護するための最も効果的な方法は、リソースの完全な ARN を指定して `aws:SourceArn` グローバル条件コンテキストキーを使用することです。リソースの完全な ARN が不明な場合や、複数のリソースを指定する場合には、グローバルコンテキスト条件キー `aws:SourceArn` で、ARN の未知部分を示すためにワイルドカード文字 (\$1) を使用します。例えば、` arn:aws::*:<123456789012>:*`。
`aws:SourceArn` の値に Amazon S3 バケット ARN などのアカウント ID が含まれていない場合は、両方の `aws:SourceAccount` と `aws:SourceArn` を使用して、アクセス許可を制限する必要があります。
## Amazon EKS クラスターロールのクロスサービスにおける混乱した代理を防止する
Amazon EKS クラスター IAM ロールはクラスターごとに必要です。Amazon EKS によって管理される Kubernetes クラスターはこのロールを使用してノードを管理し、[レガシークラウドプロバイダー](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider)はこのロールを使用して Elastic Load Balancing によるロードバランサーをサービス用に作成します。このいずれのクラスターアクションも同じアカウントにのみ影響するため、各クラスターロールをそのクラスターとアカウントに制限することをお勧めします。これは、*最小特権の原則*に従って AWS の推奨事項をアカウントに具体的に適用したものです。
**ソースの ARN 形式**
`aws:SourceArn` の値は、` arn:aws:eks:region:account:cluster/cluster-name ` という形式の EKS クラスターの ARN にする必要があります。例えば、` arn:aws:eks:us-west-2:123456789012:cluster/my-cluster` です。
**EKS クラスターロールの信頼ポリシーの形式**
次の例では、Amazon EKS で `aws:SourceArn` と `aws:SourceAccount` のグローバル条件コンテキストキーを使用して、「混乱した代理」問題を回避する方法を示します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-west-2:123456789012:cluster/my-cluster"
},
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
}
]
}
```
# Kubernetes のセキュリティに関する考慮事項
以下は、Amazon EKS クラスターの Kubernetes に影響する、クラウドのセキュリティに関する考慮事項です。Kubernetes のセキュリティコントロールとプラクティスの詳細については、Kubernetes ドキュメントの「[Cloud Native Security and Kubernetes](https://kubernetes.io/docs/concepts/security/cloud-native-security/)」を参照してください。
**Topics**
+ [Kubernetes 証明書でワークロードを保護する](cert-signing.md)
+ [Amazon EKS 作成の RBAC ロールおよびユーザーの説明](default-roles-users.md)
+ [既存のクラスターで KMS を使用して Kubernetes シークレットを暗号化する](enable-kms.md)
+ [Amazon EKS ポッドで AWS 秘密マネジャー シークレットを使用する](manage-secrets.md)
+ [すべての Kubernetes API データを対象とするデフォルトのエンベロープ暗号化](envelope-encryption.md)
# Kubernetes 証明書でワークロードを保護する
Kubernetes Certificates API により、[X.509](https://www.itu.int/rec/T-REC-X.509) 認証情報のプロビジョニングを自動化します。この API には、Kubernetes API クライアントが [X.509 証明書](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/)を認証機関 (CA) に要求し、取得するためのコマンドラインインターフェイスが備わっています。`CertificateSigningRequest` (CSR) リソースを使用して、示された署名者に証明書への署名を要求できます。要求は、署名前に承認または拒否されます。Kubernetes では、組み込み型の署名者とカスタムの署名者の両方がサポートされており、動作が詳細に定義されています。この構成により、クライアントは自分の CSR に何が起こるかを予測できます。証明書の署名の詳細については、「[signing requests](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/)」(リクエストへの署名) を参照してください。
組み込みの署名者の中には、`kubernetes.io/legacy-unknown` も含まれます。CSR リソースの `v1beta1` API では、この未知のレガシー署名者を拒否していません。ただし、CSR の安定版 `v1` APIでは、`signerName` を `kubernetes.io/legacy-unknown` に設定することはできません。
クラスターでの証明書の生成に Amazon EKS CA を使用する場合は、カスタム署名者を使用する必要があります。CSR `v1` API バージョンを使用して新しい証明書を生成するには、既存のマニフェストと API クライアントを移行する必要があります。古い `v1beta1` API で作成された既存の証明書の有効性は保たれ、その有効期限が切れるまで機能します。これには以下が含まれます。
+ 信頼のディストリビューション: なし Kubernetes クラスターには、この署名者のための標準的な信頼またはディストリビューションはありません。
+ 許可された対象: 任意
+ 許可された x509 拡張機能: subjectAltName とキーの使用の拡張機能を受け入れ、他の拡張機能を破棄します
+ 許可された鍵の使用法: ["key encipherment", "digital signature", "server auth"] (鍵暗号化、デジタル署名、サーバー認証) 以外の使用法を含めないでください。
**注記**
クライアント証明書署名はサポートされていません。
+ 有効期限/証明書のライフタイム: 1 年 (デフォルトかつ最大の値)
+ CA ビットの許可/不許可: 不許可
## signerName を使用した CSR 生成の例
次の手順では、`signerName: beta.eks.amazonaws.com/app-serving` を使用した DNS 名 `myserver.default.svc` の配信用証明書の生成方法を示します。これは、実際の環境を構築するためのガイドとして使用できます。
1. `openssl genrsa -out myserver.key 2048` コマンドを実行して、RSA プライベートキーを生成します。
```
openssl genrsa -out myserver.key 2048
```
1. 次のコマンドを実行して、証明書リクエストを生成します。
```
openssl req -new -key myserver.key -out myserver.csr -subj "/CN=myserver.default.svc"
```
1. CSR リクエストの `base64` 値を生成し、後の手順で使用するために変数に格納します。
```
base_64=$(cat myserver.csr | base64 -w 0 | tr -d "
")
```
1. 次のコマンドを実行して、`mycsr.yaml` という名前のファイルを作成します。次の例では、`beta.eks.amazonaws.com/app-serving` が `signerName` に使用されています。
```
cat >mycsr.yaml < myserver.crt
```
# Amazon EKS 作成の RBAC ロールおよびユーザーの説明
Kubernetes クラスターを作成すると、Kubernetes が正常に機能するようにそのクラスターに複数のデフォルト Kubernetes ID が作成されます。Amazon EKS はデフォルトコンポーネントごとに Kubernetes ID を作成します。ID はクラスターコンポーネントの Kubernetes ロールベースの承認制御 (RBAC) を提供します。詳細についてはKubernetes ドキュメントの「[RBAC 認可を使用する](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)」を参照してください。
オプションの[アドオン](eks-add-ons.md)をクラスターにインストールすると、クラスターに追加の Kubernetes ID が追加されることがあります。このトピックで扱われていない ID の詳細については「アドオンのドキュメント」を参照してください。
AWS マネジメントコンソール または `kubectl` コマンドラインツールを使用して、クラスターで Amazon EKS が作成した Kubernetes ID のリストを表示できます。すべてのユーザー ID はお客様に対して、Amazon CloudWatch を通じて利用可能な `kube` 監査ログに表示されます。
## AWS マネジメントコンソール
### 前提条件
使用する [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)には「[必要なアクセス許可](view-kubernetes-resources.md#view-kubernetes-resources-permissions)」に記載されている許可が必要です。
### AWS マネジメントコンソール を使用して Amazon EKS で作成された ID を表示するには
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. **[Clusters]** (クラスター) のリストで、表示したい ID を含んでいるクラスターを選択してください。
1. **[リソース]** タブを選択してください。
1. **[Resource types]** (リソースタイプ) で **[Authorization]** (承認)を 選択してください。
1. **[クラスター役割]**、**[クラスター役割ビンディング]**、**[役割]** 、または **[バインディング役割]** を選択してください。**[eks]** というプレフィックスが付いたリソースはすべて、Amazon EKS によって作成されます。Amazon EKS で作成される追加の ID リソースは次のとおりです：
+ **[aws-node]** という名前の **[クラスター役割]** と **[クラスター役割バインディング]**。**[aws-node]** リソースは Amazon EKS がすべてのクラスターにインストールする [Amazon VPC CNI plugin for Kubernetes ](managing-vpc-cni.md)をサポートします。
+ **[vpc-resource-controller-role]** という名前の **[クラスター役割]** および **[vpc-resource-controller-rolebinding]** という名前の **[クラスター役割バインディング]**。これらのリソースはAmazon EKS がすべてのクラスターにインストールする「[Amazon VPC resource controller](https://github.com/aws/amazon-vpc-resource-controller-k8s)」(Amazon VPC リソースコントローラー) サポートします。
コンソールに表示されるリソースに加えて、次の特別なユーザー ID がクラスターに存在しますが、クラスターの設定には表示されません：
+ ** `eks:cluster-bootstrap` ** - クラスターブートストラップ中の `kubectl` 操作に使用されます。
+ ** `eks:support-engineer` ** - クラスター管理操作に使用されます。
1. 特定のリソースを選択すると、そのリソースの詳細が表示されます。デフォルトでは情報は **[Structured view]** (構造化ビュー) で表示されます。詳細ページの右上隅で、**[Raw View]** (生のビュー) 選択すると、リソースの情報をすべて表示できます。
## Kubectl
### 前提条件
クラスター上の Kubernetes リソースを一覧表示するために使用するエンティティ (AWS Identity and Access Management (IAM) または OpenID Connect (OIDC)) は IAM または OIDC ID プロバイダーによって認証される必要があります。エンティティにはそのエンティティに使用させたいクラスター上の、`Role`、`ClusterRole`、`RoleBinding`、および `ClusterRoleBinding` リソースに対してKubernetes `get` および `list` 動詞を使用するアクセス許可が付与されている必要があります。IAM エンティティにクラスターへのアクセスを付与する方法の詳細については「[IAM ユーザーおよびロールに Kubernetes API へのアクセスを付与する](grant-k8s-access.md)」を参照してください。独自の OIDC プロバイダーによって認証されたエンティティにクラスターへのアクセスを付与する方法の詳細については「[外部 OIDC プロバイダーを使用して Kubernetes へのアクセスをユーザーに許可する](authenticate-oidc-identity-provider.md)」を参照してください。
### `kubectl` を使用して Amazon EKS で作成された ID を表示するには
表示するリソースのタイプのコマンドを実行します。**[eks]** というプレフィックスが付いたすべての返されるリソースはAmazon EKS によって作成されます。コマンドからの出力で返されるリソースに加えて、次の特別なユーザー ID がクラスターに存在しますが、クラスターの設定には表示されません：
+ ** `eks:cluster-bootstrap` ** - クラスターブートストラップ中の `kubectl` 操作に使用されます。
+ ** `eks:support-engineer` ** - クラスター管理操作に使用されます。
**ClusterRoles** - `ClusterRoles` はクラスターにスコープが設定されているため、ロールに付与されたすべてのアクセス許可はクラスター上の任意の Kubernetes 名前空間内のリソースに適用されます。
次のコマンドは、クラスター上で Amazon EKSによって作成されたすべての Kubernetes `ClusterRoles` を返します。
```
kubectl get clusterroles | grep eks
```
出力で返されるのはプレフィックスが付けられた `ClusterRoles` の他に、次の `ClusterRoles` が存在します。
+ ** `aws-node` ** – この `ClusterRole` はAmazon EKS がすべてのクラスターにインストールする [Amazon VPC CNI plugin for Kubernetes](managing-vpc-cni.md), をサポートします。
+ ** `vpc-resource-controller-role` ** - この `ClusterRole` はAmazon EKS がすべてのクラスターにインストールする「[Amazon VPC resource controller](https://github.com/aws/amazon-vpc-resource-controller-k8s)」(Amazon VPC リソースコントローラー) サポートします。
`ClusterRole` の仕様を確認するには次のコマンドの *eks:k8s-metrics* を前のコマンドの出力で返された `ClusterRole` に置き換えます。次の例では*eks:k8s-metrics* `ClusterRole` の仕様を返します。
```
kubectl describe clusterrole eks:k8s-metrics
```
出力例は次のとおりです。
```
Name: eks:k8s-metrics
Labels:
Annotations:
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
[/metrics] [] [get]
endpoints [] [] [list]
nodes [] [] [list]
pods [] [] [list]
deployments.apps [] [] [list]
```
**クラスター役割Bindings** - `ClusterRoleBindings` はクラスターを対象としています。
次のコマンドは、クラスター上で Amazon EKSによって作成されたすべての Kubernetes `ClusterRoleBindings` を返します。
```
kubectl get clusterrolebindings | grep eks
```
出力で返される `ClusterRoleBindings` 以外に、次の `ClusterRoleBindings` が存在します。
+ ** `aws-node` ** – この `ClusterRoleBinding` はAmazon EKS がすべてのクラスターにインストールする [Amazon VPC CNI plugin for Kubernetes](managing-vpc-cni.md), をサポートします。
+ ** `vpc-resource-controller-rolebinding` ** - この `ClusterRoleBinding` はAmazon EKS がすべてのクラスターにインストールする「[Amazon VPC resource controller](https://github.com/aws/amazon-vpc-resource-controller-k8s)」(Amazon VPC リソースコントローラー) サポートします。
`ClusterRoleBinding` の仕様を確認するには次のコマンドの *eks:k8s-metrics* を前のコマンドの出力で返された `ClusterRoleBinding` に置き換えます。次の例では*eks:k8s-metrics* `ClusterRoleBinding` の仕様を返します。
```
kubectl describe clusterrolebinding eks:k8s-metrics
```
出力例は次のとおりです。
```
Name: eks:k8s-metrics
Labels:
Annotations:
Role:
Kind: ClusterRole
Name: eks:k8s-metrics
Subjects:
Kind Name Namespace
---- ---- ---------
User eks:k8s-metrics
```
**Roles** - `Roles` は Kubernetes 名前空間にスコープされます。`Roles` で作成されたすべての Amazon EKS は`kube-system` 名前空間にスコープされます。
次のコマンドは、クラスター上で Amazon EKSによって作成されたすべての Kubernetes `Roles` を返します。
```
kubectl get roles -n kube-system | grep eks
```
`Role` の仕様を確認するには、次のコマンドの *eks:k8s-metrics* を、前のコマンドの出力で返された `Role` の名前に置き換えます。次の例では*eks:k8s-metrics* `Role` の仕様を返します。
```
kubectl describe role eks:k8s-metrics -n kube-system
```
出力例は次のとおりです。
```
Name: eks:k8s-metrics
Labels:
Annotations:
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
daemonsets.apps [] [aws-node] [get]
deployments.apps [] [vpc-resource-controller] [get]
```
**RoleBindings** - `RoleBindings` は Kubernetes 名前空間にスコープされます。`RoleBindings` で作成されたすべての Amazon EKS は`kube-system` 名前空間にスコープされます。
次のコマンドは、クラスター上で Amazon EKSによって作成されたすべての Kubernetes `RoleBindings` を返します。
```
kubectl get rolebindings -n kube-system | grep eks
```
`RoleBinding` の仕様を確認するには次のコマンドの *eks:k8s-metrics* を前のコマンドの出力で返された `RoleBinding` に置き換えます。次の例では*eks:k8s-metrics* `RoleBinding` の仕様を返します。
```
kubectl describe rolebinding eks:k8s-metrics -n kube-system
```
出力例は次のとおりです。
```
Name: eks:k8s-metrics
Labels:
Annotations:
Role:
Kind: Role
Name: eks:k8s-metrics
Subjects:
Kind Name Namespace
---- ---- ---------
User eks:k8s-metrics
```
# 既存のクラスターで KMS を使用して Kubernetes シークレットを暗号化する
**重要**
この手順の対象となるのは、Kubernetes バージョン 1.27 以前を実行している EKS クラスターのみです。Kubernetes バージョン 1.28 以降を実行している場合、デフォルトでは Kubernetes シークレットはエンベロープ暗号化で保護されます。詳細については、「[すべての Kubernetes API データを対象とするデフォルトのエンベロープ暗号化](envelope-encryption.md)」を参照してください。
[シークレット暗号化](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)を有効にすると、選択した AWS KMS キーを使用して Kubernetes シークレットが暗号化されます。KMS キーは次の条件を満たす必要があります：
+ 対称
+ データの暗号化と復号が可能
+ クラスターと同じ AWS リージョンに作成
+ KMS キーが別のアカウントで作成された場合、[IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)にはその KMS キーへのアクセス権が必要となります。
詳細については「[AWS キーマネジメントサービス開発者ガイド](https://docs.aws.amazon.com/kms/latest/developerguide/)」の「[他のアカウントの IAM プリンシパルが KMS キーを使用することを許可する](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html)」を参照してください。
**警告**
一度有効化したシークレット暗号化は無効化できません。このアクションを元に戻すことはできません。
eksctl
この手順の対象となるのは、Kubernetes バージョン 1.27 以前を実行している EKS クラスターのみです。詳細については、「[すべての Kubernetes API データを対象とするデフォルトのエンベロープ暗号化](envelope-encryption.md)」を参照してください。
暗号化は次の 2 つの方法のいずれかで有効にできます：
+ 1 つのコマンドでクラスターに暗号化を追加します。
シークレットを自動的に再暗号化するには次のコマンドを実行してください。
```
eksctl utils enable-secrets-encryption \
--cluster my-cluster \
--key-arn arn:aws:kms:region-code:account:key/key
```
シークレットの自動的な再暗号化をオプトアウトするには次のコマンドを実行してください。
```
eksctl utils enable-secrets-encryption
--cluster my-cluster \
--key-arn arn:aws:kms:region-code:account:key/key \
--encrypt-existing-secrets=false
```
+ `kms-cluster.yaml` ファイルを使用してクラスターに暗号化を追加します。
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: region-code
secretsEncryption:
keyARN: arn:aws:kms:region-code:account:key/key
```
シークレットに自動的な再暗号化をさせるには次のコマンドを実行してください。
```
eksctl utils enable-secrets-encryption -f kms-cluster.yaml
```
シークレットの自動的な再暗号化をオプトアウトするには次のコマンドを実行してください。
```
eksctl utils enable-secrets-encryption -f kms-cluster.yaml --encrypt-existing-secrets=false
```
AWS マネジメントコンソール
1. この手順の対象となるのは、Kubernetes バージョン 1.27 以前を実行している EKS クラスターのみです。詳細については、「[すべての Kubernetes API データを対象とするデフォルトのエンベロープ暗号化](envelope-encryption.md)」を参照してください。
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. KMS 暗号化を追加するクラスターを選択してください。
1. **[Overview]** (概要 タブを選択してください (これはデフォルトで選択されています)。
1. **[秘密の暗号化]** (シークレットの暗号化 セクションまでスクロールダウンし、**[Enable]** (有効化 ボタンを選択してください。
1. ドロップダウンリストからキーを選択し、**[Enable]** (有効化 ボタンを選択してください。キーが一覧表示されていない場合は最初にキーを作成する必要があります。詳細については「[キーの作成](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)」を参照してください。
1. **[Confirm]** (確認) ボタンを選択して、指定したキーを使用します。
AWS CLI
1. この手順の対象となるのは、Kubernetes バージョン 1.27 以前を実行している EKS クラスターのみです。詳細については、「[すべての Kubernetes API データを対象とするデフォルトのエンベロープ暗号化](envelope-encryption.md)」を参照してください。
1. 次の AWS CLI コマンドを使用して、[シークレット暗号化](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)設定をクラスターに関連付けます。値の例 は実際に使用する値に置き換えます。
```
aws eks associate-encryption-config \
--cluster-name my-cluster \
--encryption-config '[{"resources":["secrets"],"provider":{"keyArn":"arn:aws:kms:region-code:account:key/key"}}]'
```
出力例は次のとおりです。
```
{
"update": {
"id": "3141b835-8103-423a-8e68-12c2521ffa4d",
"status": "InProgress",
"type": "AssociateEncryptionConfig",
"params": [
{
"type": "EncryptionConfig",
"value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws:kms:region-code:account:key/key\"}}]"
}
],
"createdAt": 1613754188.734,
"errors": []
}
}
```
1. 次のコマンドを使用すると、暗号化更新のステータスをモニタリングできます。前の出力で返された特定の `cluster name` と `update ID` を使用します。`Successful` ステータスが表示されると、更新は完了です。
```
aws eks describe-update \
--region region-code \
--name my-cluster \
--update-id 3141b835-8103-423a-8e68-12c2521ffa4d
```
出力例は次のとおりです。
```
{
"update": {
"id": "3141b835-8103-423a-8e68-12c2521ffa4d",
"status": "Successful",
"type": "AssociateEncryptionConfig",
"params": [
{
"type": "EncryptionConfig",
"value": "[{\"resources\":[\"secrets\"],\"provider\":{\"keyArn\":\"arn:aws:kms:region-code:account:key/key\"}}]"
}
],
"createdAt": 1613754188.734>,
"errors": []
}
}
```
1. クラスターで暗号化が有効になっていることを確認するには`describe-cluster` コマンドを実行してください。レスポンスの内容は文字列 `EncryptionConfig` です。
```
aws eks describe-cluster --region region-code --name my-cluster
```
クラスターで暗号化を有効にしたら、既存のすべてのシークレットを新しいキーで暗号化する必要があります：
**注記**
`eksctl` を使用する場合、シークレットを自動的に再暗号化することをオプトアウトした場合にのみ、次のコマンドを実行する必要があります。
```
kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - kms-encryption-timestamp="time value"
```
**警告**
既存のクラスターで[シークレット暗号化](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)を有効にし、使用する KMS キーが削除されている場合はこのクラスターを復旧する手段はありません。KMS キーを削除すると、クラスターは永続的にパフォーマンスが低下した状態になります。詳細については「[AWSKMS キーを削除する](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html)」を参照してください。
**注記**
`create-key` コマンドではデフォルトで[対称暗号化 KMS キー](https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html)が作成されます。この際にはアカウントのルート管理者に AWS KMS アクションとリソースへのアクセスを許可する、キーポリシーが使用されます。アクセス許可の範囲を絞り込む場合は`create-cluster` API を呼び出すプリンシパルのポリシーで、`kms:DescribeKey` および `kms:CreateGrant` アクションが許可されていることを確認します。
KMS エンベロープ暗号化を使用するクラスターの場合、`kms:CreateGrant` アクセス許可が必要です。条件 `kms:GrantIsForAWSResource` はクラスター作成 アクションでサポートされていないため、クラスター作成 を実行するユーザーの `kms:CreateGrant` アクセス許可を制御する KMS ポリシーで使用しないでください。
# Amazon EKS ポッドで AWS 秘密マネジャー シークレットを使用する
Secrets Manager のシークレットとパラメータストアのパラメータを、Amazon EKS Pod にマウントされたファイルとして表示するには、[Kubernetes の Secrets Store CSI ドライバー](https://secrets-store-csi-driver.sigs.k8s.io/)向けの AWS Secrets and Configuration Provider (ASCP) を使用します。
ASCP を使用すると、Secrets Manager でシークレットを保存および管理し、Amazon EKS で実行されているワークロードを介して、そのシークレットを取得することが可能です。IAM ロールとポリシーを使用して、シークレットへのアクセスをクラスターにある特定の Kubernetes Pod に制限することができます。ASCP は、Pod Identity を取得して IAM ロールと交換します。ASCP が Pod の IAM ロールを引き受けると、Secrets Manager からそのロールに対して認可されているシークレットを取得できます。
シークレットに 秘密マネジャー の自動ローテーションを使用する場合は シークレットストア CSI ドライバーのローテーション調整機能を使用して、秘密マネジャー から最新のシークレットを取得することもできます。
**注記**
AWS Fargate (Fargate) ノードグループはサポートされていません。
詳細についてはAWS 秘密マネジャー ユーザーガイドの「[Using 秘密マネジャー secrets in Amazon EKS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_csi_driver.html)」を参照してください。
# すべての Kubernetes API データを対象とするデフォルトのエンベロープ暗号化
Amazon Elastic Kubernetes Service (Amazon EKS) はデフォルトでエンベロープ暗号化を備えており、Kubernetes バージョン 1.28 以降を実行している EKS クラスター内のすべての Kubernetes API データが暗号化の対象となります。
エンベロープ暗号化は、Kubernetes API サーバーで保存するデータを保護します。例えば、エンベロープ暗号化は `ConfigMaps` といった Kubernetes クラスターの設定に適用されます。一方、ノードや EBS ボリューム上のデータにはエンベロープ暗号化は適用されません。EKS は以前には Kubernetes シークレットの暗号化をサポートしていましたが、現在ではこのエンベロープ暗号化の対象がすべての Kubernetes API データへと広がっています。
Kubernetes アプリケーションの多層防御を実装するマネージドサービスがデフォルトで提供されるため、お客様側で対策を講じる必要はありません。
Amazon EKS は、[Kubernetes KMS プロバイダー v2](https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#configuring-the-kms-provider-kms-v2) で AWS [Key Management Service (KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) を使用して、[Amazon Web Services 所有のキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk)と、AWS KMS から独自の[カスタマーマネージドキー (CMK)](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) を取り込めるオプションにより、このセキュリティ層を追加しています。
## エンベロープ暗号化について
エンベロープ暗号化とは、データストア (etcd) への送信に先立ってプレーンテキストデータをデータ暗号化キー (DEK) で暗号化し、次にリモートで一元管理される KMS システム (AWS KMS) に保存されているルート KMS キーで DEK を暗号化するプロセスです。これは多層防御といわれる戦略で、暗号化キー (DEK) でデータを保護し、さらにその DEK をキー暗号化キー (KEK) という別途安全に保存された暗号化キーで保護してセキュリティ層をもう 1 つ追加することからそう呼ばれています。
## Amazon EKS が AWS KMS v2 と KMS でデフォルトのエンベロープ暗号化を実現する仕組み
Amazon EKS は、[KMS v2](https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#kms-v2) を使用して、マネージド Kubernetes コントロールプレーン内のすべての API データをデフォルトでエンベロープ暗号化してから [etcd](https://etcd.io/docs/v3.5/faq/) データベースに保存します。起動時に、クラスター API サーバーはランダムに生成されたデータと組み合わせて、シークレットシードからデータ暗号化キー (DEK) を生成します。同じく起動時に、API サーバーは KMS プラグインへの呼び出しを行い、AWS KMS からリモートのキー暗号化キー (KEK) を使用して DEK シードを暗号化します。これは、API サーバーの起動時と KEK のローテーション時に実行される 1 回限りの呼び出しです。暗号化された DEK シードは API サーバーにキャッシュされます。API サーバーは、そのキャッシュした DEK シードを使用して、キー導出関数 (KDF) に基づいて 1 回限り使用される DEK を別途生成します。こうして生成した各 DEK を Kubernetes リソースごとに 1 回のみ使用して暗号化し、その後 etcd に保存します。KMS v2 で暗号化してキャッシュされた DEK シードを使用すると、API サーバーで Kubernetes リソースを暗号化するプロセスのパフォーマンスとコスト効率が向上します。
**この KEK はデフォルトでは AWS によって所有されているものですが、必要に応じて AWS KMS から独自のものを取り込むこともできます。**
以下の図は、API サーバーの起動時に行われる DEK の生成と暗号化を示しています。
![\[図は、API サーバーの起動時に行われる DEK の生成と暗号化を示している\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/security-generate-dek.png)
以下の概要図は、etcd に保存される前に行われる Kubernetes リソースの暗号化を示しています。
![\[概要図は、etcd に保存される前に行われる Kubernetes リソースの暗号化を示しています。\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/security-encrypt-request.png)
## よくある質問
### デフォルトのエンベロープ暗号化によって、EKS クラスターのセキュリティ体制はどのように改善されますか?
メタデータとカスタマーコンテンツが暗号化されない対象領域と期間を減らします。デフォルトのエンベロープ暗号化により、メタデータとカスタマーコンテンツは etcd に保存される前に kube-apiserver のメモリ内で一時的に暗号化されていない状態になるだけです。kube-apiserver のメモリは、[Nitro システム](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/the-components-of-the-nitro-system.html)によって安全に保護されます。Amazon EKS で [Nitro ベースの EC2 インスタンス](https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/security-design-of-aws-nitro-system.html)が使用されるのは、マネージド Kubernetes コントロールプレーンに限られます。これらのインスタンスでは、システムや個人がメモリにアクセスできないよう、しっかりとセキュリティ管理が設計されています。
### この機能を利用するためには、Kubernetes のどのバージョンを実行する必要がありますか?
デフォルトのエンベロープ暗号化を有効にするには、Kubernetes バージョン 1.28 以降で Amazon EKS クラスターを実行している必要があります。
### この機能をサポートしていない Kubernetes クラスターバージョンを実行していても、データは引き続き安全に保護されますか?
はい。AWS では、[セキュリティを最優先事項としています](https://aws.amazon.com/security/)。Amazon のデジタルトランスフォーメーションとイノベーションはすべてセキュリティが最も高い運用プラクティスに基づいており、Amazon はそのレベルアップに真摯に取り組んでいます。
実行中の Kubernetes バージョンに関係なく、etcd に保存されているすべてのデータが EKS クラスターごとにディスクレベルで暗号化されます。EKS では、ルートキーを使用してボリューム暗号化キーを生成し、それを EKS サービスで管理しています。また、あらゆる Amazon EKS クラスターが、クラスター固有の仮想マシンを使用して、分離された VPC で実行されます。このアーキテクチャに加え、運用セキュリティにまつわる Amazon のプラクティスにより、Amazon EKS は SOC 1、2、3、PCI-DSS、ISO、HIPAA 適格性といった[コンプライアンス評価と基準をいくつも実現しています](https://docs.aws.amazon.com/eks/latest/userguide/compliance.html)。こうしたコンプライアンス評価と基準は、デフォルトのエンベロープ暗号化の有無にかかわらず、すべての EKS クラスターに対して維持されています。
### Amazon EKS では、エンベロープ暗号化はどのように機能しますか?
起動時に、クラスター API サーバーはランダムに生成されたデータと組み合わせて、シークレットシードからデータ暗号化キー (DEK) を生成します。同じく起動時に、API サーバーは KMS プラグインへの呼び出しを行い、AWS KMS からリモートのキー暗号化キー (KEK) を使用して DEK を暗号化します。これは、API サーバーの起動時と KEK のローテーション時に実行される 1 回限りの呼び出しです。暗号化された DEK シードは API サーバーにキャッシュされます。API サーバーは、そのキャッシュした DEK シードを使用して、キー導出関数 (KDF) に基づいて 1 回限り使用される DEK を別途生成します。こうして生成した各 DEK を Kubernetes リソースごとに 1 回のみ使用して暗号化し、その後 etcd に保存します。
AWS KMS 統合のヘルスと通常の機能性を検証するために、API サーバーから追加で呼び出しが行われることに留意してください。こうした追加のヘルスチェックは、AWS CloudTrail に表示されます。
### この機能を EKS クラスターで動作させるために何かを実行したり、アクセス許可を変更したりする必要はありますか?
いいえ。特に何もする必要はありません。Amazon EKS のエンベロープ暗号化は今ではデフォルトの設定となり、Kubernetes バージョン 1.28 以降を実行しているすべてのクラスターで有効になっています。AWS KMS 統合は、AWS 側で管理する Kubernetes API サーバーによって確立されます。つまり、クラスターで KMS 暗号化を使い始めるためにアクセス許可を設定する必要はありません。
### クラスターでデフォルトのエンベロープ暗号化が有効になっているかどうかを確認するには、どうすればよいですか?
独自の CMK の使用に切り替えると、クラスターに関連付けられている KMS キーの ARN が表示されます。また、クラスターの CMK の使用に関連する AWS CloudTrail イベントログを確認することもできます。
クラスターが AWS 所有のキーを使用している場合には、その情報が EKS コンソールに詳しく表示されます (キーの ARN を除く)。
### Amazon EKS でデフォルトのエンベロープ暗号化に使用される AWS 所有のキーに AWS からアクセスできますか?
いいえ。AWS では Amazon EKS のセキュリティ管理は厳しく、etcd データベース内のデータの保護に使用されるプレーンテキストの暗号化キーには誰もアクセスできません。こうしたセキュリティ対策は、AWS 所有の KMS キーにも適用されます。
### デフォルトのエンベロープ暗号化は既存の EKS クラスターで有効になっていますか?
Kubernetes バージョン 1.28 以降で Amazon EKS クラスターを実行している場合は、すべての Kubernetes API データに対してエンベロープ暗号化が有効になっています。既存のクラスターの場合、Amazon EKS は `eks:kms-storage-migrator` RBAC ClusterRole を使用して、以前に etcd でエンベロープ暗号化されていなかったデータをこの新しい暗号化状態に移行します。
### これは、EKS クラスターに対してシークレットのエンベロープ暗号化を既に有効にしていた場合にはどうなりますか?
Kubernetes シークレットをエンベロープ暗号化するために使用されたカスタマーマネージドキー (CMK) が KMS に既にある場合は、その同じキーがクラスター内のすべての Kubernetes API データタイプをエンベロープ暗号化するための KEK として使用されます。
### デフォルトのエンベロープ暗号化を有効にして EKS クラスターを実行すると、追加でコストが発生しますか?
デフォルトのエンベロープ暗号化に [Amazon Web Services 所有のキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk)を使用している場合、マネージド Kubernetes コントロールプレーンに関連して追加でコストが発生することはありません。デフォルトでは、Kubernetes バージョン 1.28 以降を実行しているすべての EKS クラスターが [Amazon Web Services 所有のキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk)を使用します。ただし、独自の AWS KMS キーを使用した場合は、通常の [KMS 料金](https://aws.amazon.com/kms/pricing/)が適用されます。
### 独自の AWS KMS キーを使用してクラスター内の Kubernetes API データを暗号化するには、どのくらいのコストがかかりますか?
作成または KMS にインポートするカスタムキーを保しておくには、1 か月あたり 1 ドルの支払いが発生します。KMS では、暗号化と復号をリクエストすると課金されます。アカウントごとに 1 か月あたり 20,000 件のリクエストという無料利用枠があり、この無料利用枠を超えると 1 か月あたり 10,000 件のリクエストごとに 0.03 ドルの支払いが発生します。これはアカウントで使用したすべての KMS に適用されるため、クラスターで独自の AWS KMS キーを使用した場合のコストは、このキーをアカウント内の他のクラスターや AWS リソースで使用した場合の影響を受けます。
### カスタマーマネージドキー (CMK) を使用してシークレットだけでなくすべての Kubernetes API データをエンベロープ暗号化すると、KMS の料金は高くなりますか?
いいえ。KMS v2 で実装したことにより、AWS KMS に対する呼び出しの数が大幅に減ります。そのため、EKS クラスターで Kubernetes データが追加で暗号化または復号されたとしても、CMK に関連するコストは削減されます。
既に詳述したように、Kubernetes リソースの暗号化のために生成された DEK シードは、リモート KEK で暗号化されたうえで Kubernetes API サーバーのキャッシュにローカルに保存されます。暗号化された DEK シードが API サーバーのキャッシュ内にない場合、API サーバーは AWS KMS を呼び出して DEK シードを暗号化します。その後、API サーバーは暗号化された DEK シードをキャッシュして今後 KMS を呼び出さなくてもクラスターで使用できるようにします。同じく復号リクエストでも、API サーバーは最初の復号リクエストに対して AWS KMS を呼び出し、その後復号された DEK シードをキャッシュして今後の復号操作に使用します。
詳細については、GitHub で Kubernetes 拡張機能の「[KEP-3299: KMS v2 Improvements](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/3299-kms-v2-improvements)」を参照してください。
### 複数の Amazon EKS クラスターで同じ CMK キーを使用できますか?
はい。キーを再度使用するには、キーの作成時に ARN をクラスターに関連付けることで、キーを同じリージョン内のクラスターにリンクします。ただし、複数の EKS クラスターで同じ CMK を使用している場合は、CMK が任意に無効にされないように必要な対策を講じる必要があります。そうしないと、無効になった CMK が複数の EKS クラスターに関連付けられて、キーによってはクラスターに幅広く影響が及びます。
### デフォルトのエンベロープ暗号化が有効になった後で CMK が使用できなくなった場合、EKS クラスターはどうなりますか?
KMS キーを無効にすると、そのキーは[暗号化オペレーション](https://docs.aws.amazon.com/kms/latest/developerguide/kms-cryptography.html#cryptographic-operations)で使用できなくなります。既存の CMK にアクセスできないと、API サーバーは新規に作成された Kubernetes オブジェクトを暗号化して保持できないほか、以前に暗号化されて etcd に保存された Kubernetes オブジェクトを復号できなくなります。CMK が無効になると、クラスターはすぐに異常/パフォーマンス低下状態になり、関連付けられた CMK を再び有効にするまで[サービスコミットメント](https://aws.amazon.com/eks/sla/)を満たすことができなくなります。
CMK が無効になると、EKS クラスターがパフォーマンス低下状態になり、Kubernetes コントロールプレーンリソースを正常に復元するためには CMK が無効になってから 30 日以内に再び有効にする必要があるとの通知が届きます。
### CMK が無効化/削除された場合の影響から EKS クラスターを保護するには、どうすればよいですか?
このような事態の発生から EKS クラスターを保護するには、キー管理者が最小特権の原則に基づく IAM ポリシーを使用して KMS キーオペレーションへのアクセスを管理し、EKS クラスターに関連付けられているキーが任意に無効化または削除されるリスクを軽減する必要があります。また、CMK の状態を通知する [CloudWatch アラーム](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys-creating-cloudwatch-alarm.html)を設定できます。
### CMK を再び有効にすると、EKS クラスターが復元されますか?
EKS クラスターが正常に復元されるように、CMK が無効になってから 30 日以内に再び有効にすることを強くお勧めします。ただし、EKS クラスターが正常に復元されるかどうかは、クラスターが異常/パフォーマンス低下状態のときに自動 Kubernetes アップグレードが発生したために API が大きく変更されたかどうかによっても異なります。
### CMK を無効にした後で、EKS クラスターが異常/パフォーマンス低下状態になるのはなぜですか?
EKS コントロールプレーンの API サーバーは、暗号化されて API サーバーのメモリにキャッシュされた DEK キーを使用して、作成/更新操作時にすべてのオブジェクトを暗号化してから etcd に保存します。etcd から既存のオブジェクトを取得するときに、API サーバーはキャッシュされたその同じ DEK キーを使用して、Kubernetes リソースオブジェクトを復号します。CMK を無効にしても、DEK キーが API サーバーのメモリにキャッシュされているため、API サーバーはすぐには影響を受けません。ただし、API サーバーインスタンスを再起動すると、キャッシュされた DEK が保持されないため、暗号化と復号の操作を行うには AWS KMS を呼び出す必要があります。CMK がない場合、このプロセスは KMS\$1KEY\$1DISABLED エラーコードで失敗し、API サーバーが正常に起動しなくなります。
### CMK を削除すると、EKS クラスターはどうなりますか?
EKS クラスターに関連付けられている CMK キーを削除すると、ヘルスが低下して回復の見込みがなくなります。クラスターの CMK がないと、API サーバーは新規の Kubernetes オブジェクトを暗号化して保持できないほか、以前に暗号化されて etcd データベースに保存された Kubernetes オブジェクトを復号できなくなります。EKS クラスターの CMK キーを削除するのは、今後 EKS クラスターを使用する必要はないと確信できるときだけにしてください。
CMK が見つからない (KMS\$1KEY\$1NOT\$1FOUND) 場合やクラスターに関連付けられた CMK の許可が取り消されている (KMS\$1GRANT\$1REVOKED) 場合は、クラスターを回復できなくなるので注意してください。クラスターのヘルスとエラーコードの詳細については、「[Cluster health FAQs and error codes with resolution paths](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html#cluster-health-status)」を参照してください。
### CMK を無効または削除したために EKS クラスターでパフォーマンス低下/異常が発生した場合でも課金されますか?
はい。CMK が無効になると EKS コントロールプレーンは使用できなくなりますが、EKS クラスターに割り当てられた専用のインフラストラクチャリソースはお客様が削除するまで AWS で引き続き稼働します。また、このような状況では Amazon の[サービスコミットメント](https://aws.amazon.com/eks/sla/)は適用されません。お客様が自発的にアクションを起こしたこと、あるいは何もアクションを起こさなかったことで、EKS クラスターの通常のヘルスとオペレーションが阻害されたためです。
### CMK が無効であるために異常/パフォーマンス低下状態になったときでも、EKS クラスターを自動的にアップグレードできますか?
はい。ただし、クラスターで CMK が無効である場合、30 日以内であれば再び有効にできます。この 30 日の間、Kubernetes クラスターは自動的にアップグレードされません。ただし、この期間が過ぎても CMK を再び有効にしなかった場合、クラスターは次のバージョン (n\$11) に自動的にアップグレードされます。これは標準のサポートであり、EKS の Kubernetes バージョンライフサイクルに従った動作です。
クラスターが影響を受けていることに気づいたら、無効になった CMK をすぐに再び有効にすることを強くお勧めします。なお、EKS はこうした影響を受けたクラスターを自動的にアップグレードしますが、正常に回復する保証はありません。特に、クラスターが複数回の自動アップグレードを経験している場合にはそうです。この場合、Kubernetes API に変更が加えられ、API サーバーのブートストラッププロセスが予期しない動作をする可能性があるからです。
### KMS キーのエイリアスを使用できますか?
はい。Amazon EKS は、[KMS キーのエイリアスの使用をサポートしています](https://docs.aws.amazon.com/eks/latest/APIReference/API_EncryptionConfig.html#API_EncryptionConfig_Contents)。エイリアスは、[Amazon Web Services KMS キー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys)をわかりやすくした名前です。例えば、エイリアスを使用すると、KMS キーを **`1234abcd-12ab-34cd-56ef-1234567890ab`** ではなく **my-key** として参照できます。
### 独自の Kubernetes バックアップソリューションを使用して、クラスターリソースをバックアップおよび復元できますか?
はい。Kubernetes クラスターのディザスタリカバリ、データ移行、データ保護に Kubernetes バックアップソリューション ([Velero](https://velero.io/) など) を使用できます。API サーバーを介してクラスターリソースにアクセスする Kubernetes バックアップソリューションを実行している場合、アプリケーションが取得するデータは復号されてからクライアントに送られます。そのため、別の Kubernetes クラスターにクラスターリソースを復元できます。
# Amazon EKS Auto Mode におけるセキュリティに関する考慮事項
このトピックでは、Amazon EKS Auto Mode のセキュリティアーキテクチャ、コントロール、ベストプラクティスについて説明します。組織がコンテナ化されたアプリケーションを大規模にデプロイするにつれて、強力なセキュリティ体制を維持することがますます複雑になります。EKS Auto Mode は、自動化されたセキュリティコントロールを実装し、AWS セキュリティサービスと統合して、クラスターのインフラストラクチャ、ワークロード、データを保護します。EKS Auto Mode は、強制ノードライフサイクル管理や自動パッチデプロイなどの組み込みセキュリティ機能を通じて、運用オーバーヘッドを削減しながらセキュリティのベストプラクティスを維持するのに役立ちます。
このトピックを進める前に、基本的な EKS Auto Mode の概念を理解していること、およびクラスターで EKS Auto Mode を有効にするための前提条件を確認しているようにしてください。Amazon EKS セキュリティに関する一般的な情報については、「[Amazon EKS のセキュリティ](security.md)」を参照してください。
Amazon EKS Auto Mode は、Amazon EKS の既存のセキュリティ基盤に基づいて構築されると同時に、EC2 マネージドインスタンスに対する追加の自動セキュリティコントロールを導入します。
## API セキュリティと認証
Amazon EKS Auto Mode は、AWS プラットフォームのセキュリティメカニズムを使用して、Amazon EKS API への呼び出しを保護および認証します。
+ Kubernetes API へのアクセスは、AWS IAM ID と統合された EKS アクセスエントリを介して保護されます。
+ 詳細については、「[EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する](access-entries.md)」を参照してください。
+ お客様は、EKS アクセスエントリの設定を通じて、Kubernetes API エンドポイントへのきめ細かなアクセスコントロールを実装できます。
## ネットワークセキュリティ
Amazon EKS Auto Mode は、複数のネットワークセキュリティレイヤーをサポートしています。
+ **VPC 統合**
+ Amazon Virtual Private Cloud (VPC) 内で動作
+ カスタムの VPC 設定とサブネットレイアウトをサポート
+ クラスターコンポーネント間のプライベートネットワーキングを有効化
+ 詳細については、「[Amazon Virtual Private Cloud のセキュリティの責任の管理](https://docs.aws.amazon.com/vpc/latest/userguide/security.html)」を参照してください
+ **ネットワークポリシー**
+ Kubernetes ネットワークポリシーのネイティブサポート
+ 詳細なネットワークトラフィックルールを定義する機能
+ 詳細については、「[Kubernetes ネットワークポリシーにより Pod トラフィックを制限する](cni-network-policy.md)」を参照してください。
## EC2 マネージドインスタンスのセキュリティ
Amazon EKS Auto Mode は、次のセキュリティコントロールを使用して EC2 マネージドインスタンスを操作します。
### EC2 セキュリティ
+ EC2 マネージドインスタンスは、Amazon EC2 のセキュリティ機能を維持します。
+ EC2 マネージドインスタンスの詳細については、「[Security in Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security.html)」を参照してください。
### インスタンスのライフサイクル管理
EKS Auto Mode によって運用される EC2 マネージドインスタンスの最大存続期間は 21 日です。Amazon EKS Auto Mode は、この存続期間を超えたインスタンスを自動的に終了します。この存続期間制限は、設定のドリフトを防ぎ、セキュリティ体制を維持するのに役立ちます。
### データ保護
+ Amazon EC2 インスタンスストレージは暗号化されており、インスタンスに直接アタッチされたストレージになっています。詳細については、「[Amazon EC2 でのデータ保護](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html)」を参照してください。
+ EKS Auto Mode は、ルートボリュームやデータボリュームなど、作成時に EC2 インスタンスにアタッチされたボリュームを管理します。EKS Auto Mode は、Kubernetes 永続ストレージ機能を使用して作成された EBS ボリュームを完全には管理しません。
### パッチ管理
+ Amazon EKS Auto Mode は、マネージドインスタンスにパッチを自動的に適用します。
+ パッチには以下が含まれます。
+ オペレーティングシステムの更新
+ セキュリティパッチ
+ Amazon EKS Auto Mode コンポーネント
**注記**
これらのインスタンスで実行されているワークロードを保護および更新するのはお客様です。
### アクセス制御
+ インスタンスへの直接アクセスは制限されています。
+ SSH アクセスは使用できません。
+ AWS Systems Manager Session Manager (SSM) アクセスは使用できません。
+ 管理オペレーションは、Amazon EKS API と Kubernetes API を介して実行されます。
## 自動リソース管理
Amazon EKS Auto Mode は、Kubernetes 永続ストレージ機能を使用して作成された Amazon Elastic Block Store (Amazon EBS) ボリュームを完全には管理しません。EKS Auto Mode は Elastic Load Balancer (ELB) も管理しません。Amazon EKS Auto Mode は、これらのリソースのルーチンタスクを自動化します。
### ストレージセキュリティ
+ AWS では、Kubernetes 永続ストレージ機能によってプロビジョニングされた EBS ボリュームの暗号化を有効にすることをお勧めします。詳細については、「[ストレージクラスを作成する](create-storage-class.md)」を参照してください。
+ AWS KMS を使用した保管時の暗号化
+ 作成した新しい EBS ボリュームとスナップショットコピーの暗号化を強制するように AWS アカウントを設定できます。詳細については、「Amazon EBS ユーザーガイド」の「[Enable Amazon EBS encryption by default](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html)」を参照してください。
+ 詳細については、「[Security in Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/security.html)」を参照してください。
### ロードバランサーのセキュリティ
+ Elastic Load Balancer の自動設定
+ AWS Certificate Manager 統合による SSL/TLS 証明書管理
+ ロードバランサーアクセスコントロールのセキュリティグループ自動化
+ 詳細については、「[Security in Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/security.html)」を参照してください。
## セキュリティに関するベストプラクティス
次のセクションでは、Amazon EKS Auto Mode におけるセキュリティのベストプラクティスについて説明します。
+ AWS IAM ポリシーと EKS アクセスエントリを定期的に確認します。
+ ワークロードに最小特権のアクセスパターンを実装します。
+ AWS CloudTrail と Amazon CloudWatch を使用してクラスターのアクティビティをモニタリングします。詳細については、[API コールを AWS CloudTrail イベントとしてログします。](logging-using-cloudtrail.md)および[Amazon CloudWatch でクラスターデータをモニタリングする](cloudwatch.md)を参照してください。
+ セキュリティ体制の評価には AWS Security Hub を使用します。
+ ワークロードに適したポッドセキュリティ標準を実装します。
# EKS 機能のセキュリティに関する考慮事項
このトピックでは、EKS 機能のセキュリティを考慮するうえで重要な事項について説明します。具体的には、IAM ロール設定、Kubernetes アクセス許可、マルチクラスターデプロイとクロスアカウント AWS リソース管理のアーキテクチャパターンなどです。
EKS 機能では、IAM ロール、EKS アクセスエントリ、Kubernetes RBAC を組み合わせることにより、AWS サービスとクラスター内 Kubernetes リソースに安全にアクセスし、AWS CodeConnections、AWS Secrets Manager、およびその他の AWS サービスと統合できます。
## 機能 IAM ロール
機能を作成するときは、自分の代わりに EKS がアクションを実行するように IAM 機能ロールを指定できます。このロールの要件は次のとおりです。
+ クラスターおよび機能リソースと同じ AWS アカウントに存在していること
+ 信頼ポリシーにより、`capabilities.eks.amazonaws.com` サービスプリンシパルがロールを引き受けることを許可すること
+ 要件に応じて、機能タイプとユースケースに適した IAM アクセス許可を付与すること 必要な IAM アクセス許可の詳細については、「[AWS CodeConnections を使用して Git リポジトリに接続する](integration-codeconnections.md)」、「[AWS Secrets Manager を使用してアプリケーションシークレットを管理する](integration-secrets-manager.md)」、「[ACK アクセス許可を設定する](ack-permissions.md)」を参照してください。
ここでのベストプラクティスは、特定のユースケースに必要な権限の範囲を考慮したうえで、要件を満たすために必要なアクセス許可のみを付与することです。例えば、Kube Resource Orchestrator に EKS 機能を使用する場合には IAM アクセス許可は必要ありませんが、Kubernetes 用 AWS コントローラーに EKS 機能を使用する場合には 1 つ以上の AWS サービスへのフルアクセスを許可できます。
**重要**
ユースケースによっては広範な管理者権限の使用を許可できますが、特定のユースケースに必要な最小限の IAM アクセス許可のみを付与して最小特権の原則に従うと、ワイルドカードアクセス許可を使用するのではなく、ARN と条件キーを使用して、特定のリソースへのアクセスを制限できます。
機能 IAM ロールの作成と設定の詳細については、「[Amazon EKS 機能 IAM ロール](capability-role.md)」を参照してください。
## EKS アクセスエントリ
IAM ロールと共に機能を作成すると、Amazon EKS がそのロールのアクセスエントリをクラスターに自動的に作成します。このアクセスエントリにより、動作に必要なベースラインとなる Kubernetes アクセス許可が機能に付与されます。
**注記**
アクセスエントリが作成されるクラスターは、機能が作成されているクラスターです。Argo CD でリモートクラスターにデプロイする場合は、Argo CD 機能がアプリケーションをデプロイおよび管理できるように、そのクラスターにアクセスエントリを作成して適切なアクセス許可を付与する必要があります。
アクセスエントリの内容は以下のとおりです。
+ IAM ロール ARN をプリンシパルとします。
+ 機能固有のアクセスエントリポリシーでベースライン Kubernetes アクセス許可を付与します。
+ 機能タイプに基づいて適切な範囲 (クラスター全体または名前空間範囲内) を指定します。
**注記**
Argo CD の場合、名前空間範囲のアクセス許可は機能設定に指定された名前空間に付与されます (デフォルトは `argocd`)。
**機能別のデフォルトアクセスエントリポリシー**
機能タイプごとに必要なアクセス許可が機能ロールに付与され、次のように異なるデフォルトアクセスエントリポリシーが設定されます。
**kro**
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSKROPolicy` (クラスター範囲)
ResourceGraphDefinitions を監視および管理するアクセス許可を付与し、RGD に定義されたカスタムリソースのインスタンスを作成します。
**ACK**
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSACKPolicy` (クラスター範囲)
すべての名前空間で ACK カスタムリソースを作成、読み取り、更新、削除できるアクセス許可を付与します。
**Argo CD**
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy` (クラスター範囲)
Argo CD がリソースを検出し、クラスター範囲のオブジェクトを管理するために必要なクラスターレベルのアクセス許可を付与します。
+ `arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy` (名前空間範囲)
Argo CD がアプリケーションをデプロイおよび管理するために必要な名前空間レベルのアクセス許可を付与します。機能設定に指定された名前空間に限定されます (デフォルトは `argocd`)。
詳細については、「[アクセスポリシーアクセス許可を確認する](access-policy-permissions.md)」を参照してください。
## その他の Kubernetes アクセス許可
機能によっては、デフォルトのアクセスエントリポリシーの範囲を超える Kubernetes アクセス許可が追加で必要になる場合があります。こうしたアクセス許可を付与するには、次のいずれかを使用します。
+ **アクセスエントリポリシー**: 追加の管理ポリシーをアクセスエントリに関連付けます。
+ **Kubernetes RBAC**: 機能の Kubernetes ユーザーに対して `Role` または `ClusterRole` バインディングを作成します。
**ACK シークレット読み取りアクセス許可**
ACK コントローラーによっては、データベースパスワードなどの機密データを取得するために Kubernetes シークレットを読み取る必要があります。次の ACK コントローラーでは、シークレット読み取りアクセスが必要です。
+ `acm`, `acmpca`, `documentdb`, `memorydb`, `mq`, `rds`, `secretsmanager`
シークレット読み取りアクセス許可を付与するには:
1. `arn:aws:eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicy` アクセスエントリポリシーを機能のアクセスエントリに関連付けます。
1. ACK リソースがシークレットを参照するか、クラスター全体のアクセスを許可する、特定の名前空間にポリシーの範囲を限定します。
**重要**
シークレット読み取りアクセス許可の範囲は、アクセスエントリポリシーを関連付けるときに指定する名前空間に限定されます。これにより、機能がどのシークレットにアクセスできるかを制限できます。
**kro による任意のリソースアクセス許可**
kro には、ResourceGraphDefinitions に定義されたリソースを作成および管理するためのアクセス許可が必要です。デフォルトでは、kro は RGD 自体を監視および管理できるだけです。
kro にリソースを作成するためのアクセス許可を付与するには:
**オプション 1: アクセスエントリポリシー**
`AmazonEKSAdminPolicy` や `AmazonEKSEditPolicy` などの事前定義済みのアクセスエントリポリシーを機能のアクセスエントリに関連付けます。
**オプション 2: Kubernetes RBAC**
`ClusterRoleBinding` を作成して、機能の Kubernetes ユーザーに必要なアクセス許可を付与します。
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kro-cluster-admin
subjects:
- kind: User
name: arn:aws:sts::111122223333:assumed-role/my-kro-role/KRO
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
```
**注記**
kro の Kubernetes ユーザー名は、`arn:aws:sts::ACCOUNT_ID:assumed-role/ROLE_NAME/KRO` というパターンに従います。
セッション名 `/KRO` (大文字) は、EKS kro 機能によって自動的に設定されます。
## 機能で必要な IAM アクセス許可
**kro (Kube Resource Orchestrator)**
必須の IAM アクセス許可はありません。ポリシーをアタッチせずに機能ロールを作成できます。kro に必要なのは Kubernetes RBAC アクセス許可のみです。
**ACK (Kubernetes 用 AWS コントローラー)**
ACK が作成および管理する AWS リソースを管理するためのアクセス許可が必要です。要件に基づいて、特定のサービス、アクション、リソースに対するアクセス許可の範囲を限定する必要があります。IAM ロールセレクターによる本番稼働のベストプラクティスなど、ACK アクセス許可の設定の詳細については、「[ACK アクセス許可を設定する](ack-permissions.md)」を参照してください。
**Argo CD**
デフォルトでは、必須の IAM アクセス許可はありません。以下のものには、オプションでアクセス許可が必要になる場合があります。
+ AWS Secrets Manager: Git リポジトリ認証情報を Secrets Manager に保存する場合
+ AWS CodeConnections: Git リポジトリの認証に CodeConnections を使用する場合
+ Amazon ECR: Amazon ECR に OCI 形式で保存された Helm チャートを使用する場合
## セキュリティのベストプラクティス
### IAM 最小特権
ユースケースに必要なアクセス許可のみを機能リソースに付与します。これは、機能には必要に応じて広範な管理アクセス許可を付与できないという意味ではありません。このような場合は、そうしたリソースに対するアクセスを適切に管理する必要があります。
**機能ロール**:
+ **ACK**: 可能であれば、ユースケースと要件に基づいて、チームに必要な特定の AWS サービスとリソースに IAM アクセス許可を制限します。
+ **Argo CD**: 特定の Git リポジトリと Kubernetes 名前空間に対するアクセスを制限します。
+ **kro**: 信頼ポリシーに機能ロールは必要ですが、IAM アクセス許可は必要ありません (クラスター RBAC のみを使用します)。
**例**: `"Resource": "*"` ではなく、特定のリソースやリソースグループに対するパターンを指定します。
```
"Resource": [
"arn:aws:s3:::my-app-*",
"arn:aws:rds:us-west-2:111122223333:db:prod-*"
]
```
IAM 条件キーを使用して、アクセスをさらに制限します。
```
"Condition": {
"StringEquals": {
"aws:ResourceTag/Environment": "production"
}
}
```
IAM 設定の詳細については、各機能の考慮事項に関するセクションを参照してください。
### Argo CD シークレットの名前空間の分離
マネージド Argo CD 機能は、自身に設定された名前空間内のすべての Kubernetes シークレットにアクセスできます (デフォルト: `argocd`)。最適なセキュリティ体制を維持するには、名前空間の分離に関する以下のプラクティスに従ってください。
+ Argo CD 関連のシークレットのみを Argo CD 名前空間内に保持します。
+ 無関係なアプリケーションシークレットを Argo CD と同じ名前空間に保存しないようにします。
+ Argo CD オペレーションに必要ないアプリケーションシークレットには別の名前空間を使用します。
この分離により、Argo CD のシークレットアクセスは、Git リポジトリの認証やその他の Argo CD に固有のオペレーションに必要な認証情報のみに制限されます。
### Kubernetes RBAC
機能リソースを作成および管理できるユーザーおよびサービスアカウントを制御します。ここでのベストプラクティスは、適切な RBAC ポリシーに沿って専用の名前空間に機能リソースをデプロイすることです。
例: ACK で RBAC ロールを使用して、`app-team` 名前空間で S3 バケットリソースを管理できるようにします。
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: ack-s3-manager
namespace: app-team
rules:
- apiGroups: ["s3.services.k8s.aws"]
resources: ["buckets"]
verbs: ["get", "list", "create", "update", "delete"]
```
### 監査ログ
**CloudTrail**: すべての EKS Capability API オペレーション (作成、更新、削除) が AWS CloudTrail に記録されます。
CloudTrail ログ記録では以下を追跡できます。
+ 誰が機能を作成または変更したか
+ いつ機能設定が変更されたか
+ どのような機能ロールが使用されているか
### ネットワークアクセスおよび VPC エンドポイント
#### プライベート Argo CD API アクセス
Argo CD API サーバーへのアクセスを制限するには、ホストされた Argo CD エンドポイントに 1 つ以上の VPC エンドポイントを関連付けます。これにより、パブリックインターネットを経由することなく、VPC 内からのプライベート接続が可能になります。VPC エンドポイントは、Argo CD ウェブ UI と Argo CD API (CLI アクセスを含む) の両方へのアクセスを提供します。
**注記**
ホストされた Argo CD API エンドポイントに接続されている VPC エンドポイント (eks-capabilities.*region*.amazonaws.com を使用) は、VPC エンドポイントポリシーをサポートしていません。
#### プライベートクラスターにデプロイする
Argo CD 機能ではアプリケーションを完全にプライベートな EKS クラスターにデプロイできるため、VPC ピアリングや複雑なネットワーク設定が不要になり、運用面で大きなメリットが得られます。ただし、このアーキテクチャを設計するときは、Argo CD が Git リポジトリ (パブリックの場合あり) から設定をプルして、プライベートクラスターに適用するようにすることを検討してください。
以下の点を確認します。
+ 機密のワークロードにプライベートな Git リポジトリを使用している
+ Git リポジトリに適切なアクセスコントロールと認証を実装している
+ マージする前にプルリクエストを通じて変更を確認のうえ承認している
+ Argo CD の同期期間を使用してデプロイのタイミングを制御することを検討している
+ Argo CD 監査ログをモニタリングして不正な設定変更がないか確認している
### コンプライアンス
EKS 機能は、完全マネージド型で、Amazon EKS のコンプライアンス認定を受けています。
現在のコンプライアンス情報については、「[コンプライアンスプログラムによる対象範囲内の AWS サービス](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。
## 次のステップ
+ [ACK アクセス許可を設定する](ack-permissions.md) - ACK 用に IAM アクセス許可を設定する
+ [kro アクセス許可の設定](kro-permissions.md) - kro 用に Kubernetes RBAC を設定する
+ [Argo CD アクセス許可を設定する](argocd-permissions.md) - Argo CD 用にアイデンティティセンター統合を設定する
+ [EKS 機能をトラブルシューティングする](capabilities-troubleshooting.md) - セキュリティとアクセス許可の問題をトラブルシューティングする
# Amazon EKS の Identity and Access Management
AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御するのに役立つ AWS のサービスです。IAM 管理者は、誰の (サインイン) を*認証*し、誰による Amazon EKS リソースの使用を*承認する* (アクセス許可を付与する) かを制御します。IAM は、AWS のサービスで追加料金は発生しません。
## オーディエンス
AWS Identity and Access Management (IAM) の使用方法は、Amazon EKS で行う作業によって異なります。
**サービスユーザー** – ジョブを実行するために Amazon EKS サービスを使用する場合は、管理者から必要なアクセス許可と認証情報が与えられます。さらに多くの Amazon EKS 機能を使用して作業を行う場合は、追加のアクセス許可が必要になることがあります。アクセスの管理方法を理解すると、管理者から適切なアクセス許可をリクエストするのに役に立ちます。Amazon EKS の機能にアクセスできない場合は、「[IAM のトラブルシューティング](security-iam-troubleshoot.md)」を参照してください。
**サービス管理者** – 社内の Amazon EKS リソースを管理しているユーザーには、通常、Amazon EKS への完全なアクセス権限があります。サービスのユーザーがどの Amazon EKS 機能やリソースにアクセスするかを決めるのは管理者の仕事です。その後、IAM 管理者にリクエストを送信して、サービスユーザーの権限を変更する必要があります。このページの情報を確認して、IAM の基本概念を理解してください。企業が Amazon EKS で IAM を利用する方法については、「[アマゾン EKS で IAM を使用する方法](security-iam-service-with-iam.md)」を参照してください。
**IAM 管理者** – IAM 管理者には、Amazon EKS へのアクセスを管理するポリシーの作成方法を、詳細に把握する必要が生じる場合があります。IAM で使用可能な、Amazon EKS アイデンティティベースのポリシーの例を確認するには、「[Amazon EKS でのアイデンティティベースのポリシーの例](security-iam-id-based-policy-examples.md)」を参照してください。
## アイデンティティを使用した認証
認証とは、アイデンティティ認証情報を使用して AWS にサインインする方法です。ユーザーは、AWS アカウントのルートユーザーもしくは IAM ユーザーとして、または IAM ロールを引き受けることによって、*認証を受ける* (AWS にサインインする) 必要があります。
ID ソースから提供された認証情報を使用して、フェデレーティッドアイデンティティとして AWS にサインインできます。AWSフェデレーティッドアイデンティティの例としては、IAM アイデンティティセンター (IAM アイデンティティセンター) ユーザー、貴社のシングルサインオン認証、Google または Facebook の認証情報などがあります。フェデレーティッド ID としてサインインする場合、IAM ロールを使用して、前もって管理者により ID フェデレーションが設定されています。フェデレーションを使用して AWSにアクセスする場合、間接的にロールを引き受けることになります。
ユーザーのタイプに応じて、AWS マネジメントコンソール または AWS アクセスポータルにサインインできます。AWS へのサインインの詳細については、AWS サインインユーザーガイドの「[AWS アカウントにサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。
プログラムを使用して AWS にアクセスする場合、AWSは Software Development Kit (SDK) とコマンドラインインターフェイス (CLI) を提供し、認証情報を使用してリクエストに暗号で署名します。AWS ツールを使用しない場合は、リクエストに自分で署名する必要があります。リクエストに署名する推奨方法の使用については、「*IAM ユーザーガイド*」の「[AWS API リクエストの署名](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html)」を参照してください。
使用する認証方法を問わず、追加セキュリティ情報の提供をリクエストされる場合もあります。例えば、AWS は、アカウントのセキュリティを強化するために多要素認証 (MFA) を使用することをお勧めします。詳細については、「*AWS IAM Identity Center ユーザーガイド*」の「[多要素認証 (MFA)](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html)」および「*IAM ユーザーガイド*」の「[AWS での多要素認証 (MFA) の使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)」を参照してください。
### AWS アカウントのルートユーザー
AWS アカウントを作成する場合は、このアカウントのすべての AWS サービスとリソースに対して完全なアクセス権を持つ 1 つのサインインアイデンティティから始めます。このアイデンティティは AWS アカウント*ルートユーザー*と呼ばれ、アカウントの作成に使用したメールアドレスとパスワードでのサインインによりアクセスされます。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー資格情報は保護し、ルートユーザーでしか実行できないタスクを実行するときに使用します。ルートユーザーとしてサインインする必要があるタスクの完全なリストについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。
### IAM ユーザーとグループ
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*IAM ユーザー*は、単一のユーザーまたはアプリケーションに対する特定の許可を持つ AWS アカウント内のアイデンティティです。可能であれば、パスワードやアクセスキーなどの長期的な認証情報を保有する IAM ユーザーを作成する代わりに、一時的な認証情報を使用することをお勧めします。ただし、IAM ユーザーでの長期的な認証情報が必要な特定のユースケースがある場合は、アクセスキーをローテーションすることをお勧めします。詳細については、「*IAM ユーザーガイド*」の「[長期的な認証情報を必要とするユースケースのためにアクセスキーを定期的にローテーションする](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials)」を参照してください。
[IAM グループ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、IAM ユーザーのコレクションを指定するアイデンティティです。グループとしてサインインすることはできません。グループを使用して、複数のユーザーに対して一度に権限を指定できます。多数のユーザーグループがある場合、グループを使用することで権限の管理が簡単になります。例えば、*IAMAdmins* という名前のグループを設定して、そのグループに IAM リソースを管理する許可を与えることができます。
ユーザーは、ロールとは異なります。ユーザーは 1 人の人または 1 つのアプリケーションに一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。ユーザーには永続的な長期の認証情報がありますが、ロールでは一時的な認証情報が提供されます。詳細については、「*IAM ユーザーガイド*」の「(ロールではなく) [IAM ユーザーの作成が適している場合](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose)」を参照してください。
### IAM ロール
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*IAM ロール*は、特定のアクセス許可を持つ、AWS アカウント内のアイデンティティです。これは IAM ユーザーに似ていますが、特定のユーザーに関連付けられていません。[ロールを切り替える](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)ことによって、AWS マネジメントコンソールで IAM ロールを一時的に引き受けることができます。ロールを引き受けるには、AWS CLI または AWS API オペレーションを呼び出すか、カスタム URL を使用します。ロールを使用する方法の詳細については、「*IAM ユーザーガイド*」の「[IAM ロールの使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html)」を参照してください。
IAM ロールと一時的な認証情報は、次の状況で役立ちます:
+ **フェデレーションユーザーアクセス** – フェデレーティッド ID に許可を割り当てるには、ロールを作成してそのロールの許可を定義します。フェデレーテッド ID が認証されると、その ID はロールに関連付けられ、ロールで定義されている許可が付与されます。フェデレーションの詳細については、「*IAM ユーザーガイド*」の「[サードパーティーアイデンティティプロバイダー向けロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html)」を参照してください。IAM Identity Center を使用する場合は、許可セットを設定します。アイデンティティが認証後にアクセスできるものを制御するため、IAM Identity Center は、権限セットを IAM のロールに関連付けます。アクセス許可セットの詳細については、「*AWS IAM Identity Center ユーザーガイド*」の「[アクセス許可セット](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)」を参照してください。
+ **一時的な IAM ユーザー権限** - IAM ユーザーまたはロールは、特定のタスクに対して複数の異なる権限を一時的に IAM ロールで引き受けることができます。
+ **クロスアカウントアクセス** - IAM ロールを使用して、自分のアカウントのリソースにアクセスすることを、別のアカウントの人物 (信頼済みプリンシパル) に許可できます。ロールは、クロスアカウントアクセスを許可する主な方法です。ただし、一部の AWS のサービスでは、 (ロールをプロキシとして使用する代わりに) リソースにポリシーを直接アタッチできます。クロスアカウントアクセスにおけるロールとリソースベースのポリシーの違いについては、「*IAM ユーザーガイド*」の「[IAM でのクロスアカウントのリソースへのアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)」を参照してください。
+ **クロスサービスアクセス** – 一部の AWS のサービスは、AWS の他のサービスの機能を使用します。例えば、サービスで呼び出しを行うと、通常そのサービスによって Amazon EC2 でアプリケーションが実行されたり、Amazon S3 にオブジェクトが保存されたりします。サービスは、呼び出し元のプリンシパルの許可、サービスロール、サービスリンクロールを使用してこれを行う場合があります。
+ **転送アクセスセッション (FAS)** – IAM ユーザーまたはロールを使用して AWS でアクションを実行するユーザーは、プリンシパルと見なされます。一部のサービスを使用する際に、アクションを実行することで、別のサービスの別のアクションがトリガーされることがあります。FAS は、AWS サービスを呼び出すプリンシパルの権限を、AWS サービスのリクエストと合わせて使用し、ダウンストリームのサービスに対してリクエストを行います。FAS リクエストは、サービスが、完了するために他の AWS サービスまたはリソースとのやりとりを必要とするリクエストを受け取ったときにのみ行われます。この場合、両方のアクションを実行するためのアクセス許可が必要です。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。
+ **サービスロール** - サービスがユーザーに代わってアクションを実行するために引き受ける [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)です。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除することができます。詳細については、『*IAM ユーザーガイド*』の「[AWS のサービスにアクセス許可を委任するロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)」を参照してください。
+ **サービスリンクロール** – サービスリンクロールは、AWS のサービスにリンクされているサービスロールの一種です。サービスがロールを引き受け、ユーザーに代わってアクションを実行できるようになります。サービスにリンクされたロールは、AWS アカウント内に表示され、サービスによって所有されます。IAM 管理者は、サービスリンクロールのアクセス許可を表示できますが、編集することはできません。
+ **Amazon EC2 で実行されているアプリケーション** – EC2 インスタンスで実行され、AWS CLI または AWS API リクエストを作成しているアプリケーションの一時的な認証情報を管理するには、IAM ロールを使用します。これは、EC2 インスタンス内でのアクセスキーの保存に推奨されます。AWS ロールを EC2 インスタンスに割り当て、そのすべてのアプリケーションで使用できるようにするには、インスタンスに添付されたインスタンスプロファイルを作成します。インスタンスプロファイルにはロールが含まれ、EC2 インスタンスで実行されるプログラムは一時的な認証情報を取得できます。詳細については、*IAM ユーザーガイド*の[Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用して許可を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)を参照してください。
IAM ロールと IAM ユーザーのどちらを使用するかについては、*IAM ユーザーガイド*の[(IAM ユーザーではなく) IAM ロールをいつ作成したら良いのか?](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role)を参照してください。
## ポリシーを使用したアクセス権の管理
AWS でアクセスを制御するには、ポリシーを作成して AWS ID またはリソースにアタッチします。ポリシーは AWS のオブジェクトであり、アイデンティティやリソースに関連付けて、これらのアクセス許可を定義します。AWS は、プリンシパル (ユーザー、ルートユーザー、またはロールセッション) がリクエストを行うと、これらのポリシーを評価します。ポリシーでの権限により、リクエストが許可されるか拒否されるかが決まります。大半のポリシーは JSON ドキュメントとして AWSに保存されます。JSON ポリシードキュメントの構造と内容の詳細については、「*IAM ユーザーガイド*」の「[JSON ポリシー概要](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)」を参照してください。
管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
デフォルトでは、ユーザーやロールに権限はありません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。その後、管理者はロールに IAM ポリシーを追加し、ユーザーはロール引き継ぐことができます。
IAM ポリシーは、オペレーションの実行方法を問わず、アクションの許可を定義します。例えば、`iam:GetRole` アクションを許可するポリシーがあるとします。このポリシーがあるユーザーは、AWS マネジメントコンソール、AWS CLI、または AWS API からロール情報を取得できます。
### アイデンティティベースポリシー
アイデンティティベースのポリシーは、IAM ユーザーグループ、ユーザーのグループ、ロールなど、アイデンティティにアタッチできる JSON 許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件をコントロールします。アイデンティティベースのポリシーを作成する方法については、「IAM ユーザーガイド**」の「[IAM ポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。
アイデンティティベースのポリシーは、さらに*インラインポリシー*または*マネージドポリシー*に分類できます。インラインポリシーは、単一のユーザー、グループ、またはロールに直接埋め込まれています。管理ポリシーは、AWS アカウント内の複数のユーザー、グループ、およびロールにアタッチできるスタンドアロンポリシーです。管理ポリシーには、AWS 管理ポリシーとカスタマー管理ポリシーが含まれます。マネージドポリシーまたはインラインポリシーのいずれかを選択する方法については、*IAM ユーザーガイド*の[マネージドポリシーとインラインポリシーの比較](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline)を参照してください。
### リソースベースのポリシー
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM *ロールの信頼ポリシー*や Amazon S3 *バケットポリシー*があげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスをコントロールできます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーで、[[specify a principal]](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) (プリンシパルを指定する) 必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーティッドユーザー、または AWS のサービスを含めることができます。
リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーでは、IAM からの AWS マネージド型ポリシーを使用することはできません。
### アクセスコントロールリスト (ACL)
アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
Amazon S3、AWS WAF、および Amazon VPC は、ACL をサポートするサービスの例です。ACL の詳細については、*Amazon Simple Storage Service デベロッパーガイド* の [アクセスコントロールリスト (ACL) の概要](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) を参照してください。
### その他のポリシータイプ
AWS では、他の一般的ではないポリシータイプをサポートしています。これらのポリシータイプでは、より一般的なポリシータイプで付与された最大の権限を設定できます。
+ **アクセス許可の境界** - アクセス許可の境界は、アイデンティティベースポリシーによって IAM エンティティ (IAM ユーザーまたはロール) に付与できる権限の上限を設定する高度な機能です。エンティティにアクセス許可の境界を設定できます。結果として得られるアクセス許可は、エンティティのアイデンティティベースポリシーとそのアクセス許可の境界の共通部分になります。`Principal` フィールドでユーザーまたはロールを指定するリソースベースのポリシーでは、アクセス許可の境界は制限されません。これらのポリシーのいずれかを明示的に拒否した場合、権限は無効になります。アクセス許可の境界の詳細については、「*IAM ユーザーガイド*」の「[IAM エンティティのアクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。
+ **サービスコントロールポリシー (SCP)** – SCP とは、AWS Organizations 内の組織または組織単位 (OU) に対し、アクセス許可の上限を指定するための JSON ポリシーです。AWSOrganizations は、ビジネスが所有する複数の AWS アカウントを、グループ化および一元管理するためのサービスです。組織内のすべての機能を有効にすると、サービスコントロールポリシー (SCP) を一部またはすべてのアカウントに適用できます。SCP はメンバーアカウントのエンティティに対するアクセス許可を制限します (各 AWS アカウントルートユーザーなど)。Organizations と SCP の詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。
+ **セッションポリシー** - セッションポリシーは、ロールまたはフェデレーションユーザーの一時的なセッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。結果として得られるセッションの許可は、ユーザーまたはロールのアイデンティティベースポリシーとセッションポリシーの共通部分です。また、リソースベースのポリシーから権限が派生する場合もあります。これらのポリシーのいずれかを明示的に拒否した場合、権限は無効になります。詳細については、「*IAM ユーザーガイド*」の「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」を参照してください。
### 複数のポリシータイプ
1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成されるアクセス許可を理解するのがさらに難しくなります。複数のポリシータイプが関連するとき、リクエストを許可するかどうかを AWS が決定する方法の詳細については、*IAM ユーザーガイド*の[ポリシーの評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)を参照してください。
# アマゾン EKS で IAM を使用する方法
IAM を使用して アマゾン EKS へのアクセスを管理する前に、アマゾン EKS で使用できる IAM 機能について理解しておく必要があります。アマゾン EKS およびその他の AWS のサービスが IAM と連携する方法の概要を把握するには*IAM ユーザーガイド* の「[IAM と連携する AWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
**Topics**
+ [アマゾン EKS のアイデンティティベースのポリシー](#security-iam-service-with-iam-id-based-policies)
+ [アマゾン EKS でのリソースベースのポリシー](#security-iam-service-with-iam-resource-based-policies)
+ [アマゾン EKS タグに基づいた認可](#security-iam-service-with-iam-tags)
+ [アマゾン EKS でのIAM 役割](#security-iam-service-with-iam-roles)
## アマゾン EKS のアイデンティティベースのポリシー
IAM アイデンティティベースのポリシーでは許可または拒否するアクションとリソース、またアクションを許可または拒否する条件を指定できます。アマゾン EKS は特定のアクション、リソース、および条件キーをサポートしています。JSON ポリシーで使用するすべての要素については「*IAM ユーザーガイド*」の「[IAM JSON ポリシーエレメントのリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)」を参照してください。
### アクション
管理者は AWS JSON ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。ポリシーアクションの名前は通常、関連する AWS API オペレーションと同じです。一致する API オペレーションのない*アクセス許可のみのアクション*など、いくつかの例外があります。また、ポリシーに複数のアクションが必要なオペレーションもあります。これらの追加アクションは*依存アクション*と呼ばれます。
このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。
アマゾン EKS のポリシーアクションはアクションの前にプレフィックス `eks:` を付加します。例えば、アマゾン EKS クラスターについて説明する情報を入手するアクセス許可を他のユーザーに付与するにはポリシーに `DescribeCluster` アクションを含めます。ポリシーステートメントには`Action` または `NotAction` 要素を含める必要があります。
単一のステートメントに複数のアクションを指定するには次のようにコンマで区切ります。
```
"Action": ["eks:action1", "eks:action2"]
```
ワイルドカード (\$1) を使用して複数アクションを指定できます。例えば、`Describe` という単語で始まるすべてのアクションを指定するには次のアクションを含めます。
```
"Action": "eks:Describe*"
```
アマゾン EKS アクションの一覧については「サービス認可リファレンス」の「[アマゾン エラスティックKubernetesサービス で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)」を参照してください。
### リソース
管理者は AWS JSON ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件**下で**アクション**を実行できるかということです。
`Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ステートメントには`Resource` または `NotResource` 要素を含める必要があります。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。これは*リソースレベルの許可*と呼ばれる特定のリソースタイプをサポートするアクションに対して実行できます。
オペレーションのリスト化など、リソースレベルの許可をサポートしないアクションの場合はステートメントがすべてのリソースに適用されることを表示するワイルドカード (\$1) を使用します。
```
"Resource": "*"
```
アマゾン EKS クラスターリソースの ARN は次のようになります。
```
arn:aws:eks:region-code:account-id:cluster/cluster-name
```
ARN の形式の詳細については「[アマゾン リソースネーム (ARN) と AWS のサービスの名前空間](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)」を参照してください。
例えば、ステートメントで *マイクラスター* という名前のクラスターを指定するには次の ARN を使用します。
```
"Resource": "arn:aws:eks:region-code:111122223333:cluster/my-cluster"
```
特定のアカウントと AWS リージョンに属するすべてのクラスターを指定するにはワイルドカード (\$1) を使用します。
```
"Resource": "arn:aws:eks:region-code:111122223333:cluster/*"
```
リソースの作成を含む、一部の アマゾン EKS アクションは特定のリソースで実行できません。このような場合はワイルドカード \$1を使用する必要があります。
```
"Resource": "*"
```
アマゾン EKS リソースタイプとその ARN の一覧については「サービス認可リファレンス」の「[アマゾン エラスティックKubernetesサービス で定義されるリソース](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-resources-for-iam-policies)」を参照してください。各リソースの ARN を、どのアクションで指定できるかについては「[アマゾン エラスティックKubernetesサービス で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)」を参照してください。
### 条件キー
アマゾン EKS では独自の条件キーが定義されており、また一部のグローバル条件キーの使用がサポートされています。すべての AWS グローバル条件キーを確認するには、*IAM ユーザーガイド*の「[AWS グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。
OpenID Connect プロバイダーをクラスターに関連付ける場合に条件キーを設定できます。詳細については、「[IAM ポリシーの例](authenticate-oidc-identity-provider.md#oidc-identity-provider-iam-policy)」を参照してください。
すべての Amazon EC2 アクションは `aws:RequestedRegion` および `ec2:Region` 条件キーをサポートします。詳細については「[例: 特定の AWS リージョンへのアクセスの制限](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-region)」を参照してください。
Amazon EKS 条件キーのリストについては「*サービス認可リファレンス*」の「[Amazon エラスティックKubernetesサービス によって定義された条件](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys)」を参照してください。条件キーを使用できるアクションとリソースについては「[Amazon エラスティックKubernetesサービス で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)」を参照してください。
### 例
アマゾン EKS でのアイデンティティベースのポリシーの例は「[Amazon EKS でのアイデンティティベースのポリシーの例](security-iam-id-based-policy-examples.md)」でご確認ください。
Amazon EKS クラスターを作成すると、このクラスターを作成する [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)にはAmazon EKS コントロールプレーンのクラスター役割ベースアクセスコントロール (RBAC) 設定で、`system:masters` 許可が自動的に付与されます。このプリンシパルは表示可能な設定の中には表示されません。したがって、どのプリンシパルが最初にクラスターを作成したのかを追跡する必要があります。追加の IAM プリンシパルがクラスターとインタラクションできるようにするには Kubernetes 内の `aws-auth ConfigMap` を編集し、`aws-auth ConfigMap` で指定した `group` の名前を使用して、Kubernetes `rolebinding` または `clusterrolebinding` を作成します。
ConfigMap の使用に関する詳細については「[IAM ユーザーおよびロールに Kubernetes API へのアクセスを付与する](grant-k8s-access.md)」を参照してください。
## アマゾン EKS でのリソースベースのポリシー
アマゾン EKS では リソースベースのポリシーはサポートされていません。
## アマゾン EKS タグに基づいた認可
タグはアマゾン EKS リソースにアタッチすることも、アマゾン EKS へのリクエストの際に渡すこともできます。タグに基づいてアクセスを制御するには`aws:ResourceTag/key-name `、`aws:RequestTag/key-name `、または `aws:TagKeys` の条件キーを使用して、ポリシーの[条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)でタグ情報を提供します。アマゾン EKS リソースのタグ付けの詳細については「[タグを使用して Amazon EKS リソースを整理する](eks-using-tags.md)」を参照してください。条件キーでタグを使用できるアクションの詳細については「[Service Authorization Reference](https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html)」(サービス認可のリファレンス) の「[アマゾン EKS で定義されたアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions)」を参照してください。
## アマゾン EKS でのIAM 役割
[IAM 役割](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) は特定のアクセス許可を持つ、AWS アカウント内のエンティティです。
### アマゾン EKS での一時的な認証情報の使用
一時的な認証情報を使用して、フェデレーションでサインインする、IAM 役割を引き受ける、またはクロスアカウント役割を引き受けることができます。一時的なセキュリティ認証情報を取得するには[AssumeRole または [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) などの AWS](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) STS API オペレーションを呼び出します。
アマゾン EKS では一時認証情報が使用できます。
### サービスにリンクされたロール
[サービスリンクロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)は、AWS サービスが他のサービスのリソースにアクセスしてお客様の代わりにアクションを完了することを許可します。サービスリンクロールは IAM アカウント内に表示され、サービスによって所有されます。管理者はサービスにリンクされたロールのアクセス許可を確認できますが、編集することはできません。
アマゾン EKS はサービスにリンクされた役割をサポートしています。アマゾン EKS でのサービスにリンクされた役割の作成または管理の詳細については「[Amazon EKS でのサービスにリンクされたロールの使用](using-service-linked-roles.md)」を参照してください。
### サービス役割
この機能により、ユーザーに代わってサービスが[サービスロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-role)を引き受けることが許可されます。この役割により、サービスがお客様に代わって他のサービスのリソースにアクセスし、アクションを完了することが許可されます。サービスロールはIAM アカウントに表示され、アカウントによって所有されます。つまり、IAM 管理者はこの役割の権限を変更できます。ただし、これを行うことにより、サービスの機能が損なわれる場合があります。
アマゾン EKS ではサービス役割がサポートされています。詳細については[Amazon EKS クラスター の IAM ロール](cluster-iam-role.md)および[Amazon EKS ノードの IAM ロール](create-node-role.md)を参照してください。
### アマゾン EKS での IAM 役割の選択
アマゾン EKS でクラスターリソースを作成する場合は他のいくつかの AWS リソースに アマゾン EKS が自動的にアクセスすることを許可するための役割を、ユーザーが選択する必要があります。以前に作成したサービス役割がある場合、アマゾン EKS により、選択できる役割のリストが提示されます。アマゾン EKS 管理のポリシーがアタッチされた役割を選択することが重要です。詳細については[既存のクラスターロールの確認](cluster-iam-role.md#check-service-role)および[既存のノードロールの確認](create-node-role.md#check-worker-node-role)を参照してください。
# Amazon EKS でのアイデンティティベースのポリシーの例
デフォルトでは、IAM ユーザーおよびロールには Amazon EKS リソースを作成または変更するアクセス許可はありません。また、AWS マネジメントコンソール、AWS CLI、または AWS API を使用してタスクを実行することもできません。IAM 管理者は、ユーザーとロールに必要な、指定されたリソースで特定の API オペレーションを実行する権限をユーザーとロールに付与する IAM ポリシーを作成する必要があります。続いて、管理者はそれらの権限が必要な IAM ユーザーまたはグループにそのポリシーをアタッチする必要があります。
これらの JSON ポリシードキュメント例を使用して IAM のアイデンティティベースのポリシーを作成する方法については、『*IAM ユーザーガイド*』の「[JSON タブでのポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor)」を参照してください。
Amazon EKS クラスターを作成すると、このクラスターを作成する [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)には、Amazon EKS コントロールプレーンのクラスターロールベースアクセスコントロール (RBAC) 設定で、`system:masters` 許可が自動的に付与されます。このプリンシパルは表示可能な設定の中には表示されません。したがって、どのプリンシパルが最初にクラスターを作成したのかを追跡する必要があります。追加の IAM プリンシパルがクラスターとインタラクションできるようにするには Kubernetes 内の `aws-auth ConfigMap` を編集し、`aws-auth ConfigMap` で指定した `group` の名前を使用して、Kubernetes `rolebinding` または `clusterrolebinding` を作成します。
ConfigMap の使用に関する詳細については「[IAM ユーザーおよびロールに Kubernetes API へのアクセスを付与する](grant-k8s-access.md)」を参照してください。
**Topics**
+ [ポリシーに関するベストプラクティス](#security-iam-service-with-iam-policy-best-practices)
+ [Amazon EKS コンソールの使用](#security-iam-id-based-policy-examples-console)
+ [自分のアクセス許可の表示を IAM ユーザーに許可する](#security-iam-id-based-policy-examples-view-own-permissions)
+ [AWS Cloud に Kubernetes クラスターを作成する](#policy-create-cluster)
+ [Outpost にローカル Kubernetes クラスターを作成する](#policy-create-local-cluster)
+ [Kubernetes クラスターの更新](#policy-example1)
+ [すべてのクラスターの一覧表示または説明](#policy-example2)
## ポリシーに関するベストプラクティス
ID ベースのポリシーは、ユーザーのアカウント内で誰かが Amazon EKS リソースを作成、アクセス、または削除できるどうかを決定します。これらのアクションを実行すると、AWS アカウントに追加料金が発生する可能性があります。アイデンティティベースポリシーを作成したり編集したりする際には、以下のガイドラインと推奨事項に従ってください:
+ **AWS マネージドポリシーを使用して開始し、最小特権の許可に移行する** – ユーザーとワークロードへの許可の付与を開始するには、多くの一般的なユースケースのために許可を付与する AWS マネージドポリシーを使用します。これらは AWS アカウントで使用できます。ユースケースに固有の AWS カスタマー管理ポリシーを定義して、アクセス許可を絞り込むことをお勧めします。詳細については、*IAM ユーザーガイド* の [AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) または [ジョブ機能の AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) を参照してください。
+ **最小特権を適用する** – IAM ポリシーでアクセス許可を設定する場合は、タスクの実行に必要な許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、*最小特権アクセス許可*とも呼ばれています。IAM を使用して許可を適用する方法の詳細については、*IAM ユーザーガイド* の [IAM でのポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) を参照してください。
+ **IAM ポリシーで条件を使用してアクセスをさらに制限する** - ポリシーに条件を追加して、アクションやリソースへのアクセスを制限できます。たとえば、ポリシー条件を記述して、すべてのリクエストを SSL を使用して送信するように指定できます。また、AWS CloudFormation などの特定の AWS サービスを介して使用する場合、条件を使用してサービスアクションへのアクセスを許可することもできます。詳細については、*IAM ユーザーガイド*」の「[IAM JSON ポリシー要素: 条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)」を参照してください。
+ **IAM Access Analyzer を使用して IAM ポリシーを検証し、安全で機能的なアクセス権限を確保する** - IAM Access Analyzer は、新規および既存のポリシーを検証して、ポリシーが IAM ポリシー言語 (JSON) および IAM のベストプラクティスに準拠するようにします。IAM アクセスアナライザーは 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーの作成をサポートします。詳細については、*IAM ユーザーガイド*の[IAM Access Analyzer ポリシーの検証](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)を参照してください。
+ **多要素認証 (MFA) を要求する** – AWS アカウントで IAM ユーザーまたはルートユーザーを要求するシナリオがある場合は、セキュリティを強化するために MFA をオンにします。API オペレーションが呼び出されるときに MFA を必須にするには、ポリシーに MFA 条件を追加します。詳細については、*IAM ユーザーガイド*の[MFA 保護 API アクセスの設定](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)を参照してください。
IAM でのベストプラクティスの詳細については、*IAM ユーザーガイド*の[IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)を参照してください。
## Amazon EKS コンソールの使用
Amazon EKS コンソールにアクセスするには、[IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)に最小限の許可のセットが必要です。これらの許可により、プリンシパルは AWS アカウントの Amazon EKS リソースの詳細をリストおよび表示できます。最小限必要な許可よりも制限されたアイデンティティベースのポリシーを作成すると、そのポリシーをアタッチしたプリンシパルに対してはコンソールが意図したとおりに機能しません。
これらの IAM プリンシパルがまだ Amazon EKS コンソールを使用できるようにするには、`AmazonEKSAdminPolicy` など、独自の名前を付けてポリシーを作成します。ポリシーをプリンシパルにアタッチします。詳細については、*「IAM User Guide」*(IAM ユーザーガイド) の[「Adding and removing IAM identity permissions」](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)(IAM ID アクセス許可の追加と削除) を参照してください。
**重要**
次のポリシー例では、プリンシパルはコンソールの **[設定]** タブで情報を表示できます。AWS マネジメントコンソール で **[概要]** タブと **[リソース]** タブの情報を表示するには、プリンシパルに Kubernetes の許可も必要です。詳細については、「[必要なアクセス許可](view-kubernetes-resources.md#view-kubernetes-resources-permissions)」を参照してください。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "eks.amazonaws.com"
}
}
}
]
}
```
AWS CLI または AWS API のみを呼び出すプリンシパルには、最小限のコンソール許可を付与する必要はありません。代わりに、実行する API オペレーションと一致するアクションのみへのアクセスを許可します。
## 自分のアクセス許可の表示を IAM ユーザーに許可する
この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を IAM ユーザーに許可するポリシーの作成方法を示します。このポリシーには、コンソールで、または AWS CLI もしくは AWS API を使用してプログラム的に、このアクションを完了するための許可が含まれています。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## AWS Cloud に Kubernetes クラスターを作成する
このポリシー例には、*us-west-2* AWS リージョンに *my-cluster* という名前の Amazon EKS クラスターを作成するために必要な最小限の許可が含まれています。AWS リージョンを、クラスターを作成する AWS リージョンに置き換えることができます。AWS マネジメントコンソール で **[ポリシーのアクションはリソースレベルの許可をサポートしていないため、`All resources` を選択する必要があります]** という警告が表示された場合、無視しても問題ありません。アカウントに *AWSServiceRoleForAmazonEKS* ロールが既にある場合は、ポリシーから `iam:CreateServiceLinkedRole` アクションを削除できます。アカウントで Amazon EKS クラスターを作成したことがある場合、削除していない限り、このロールは既に存在します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:CreateCluster",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::111122223333:role/aws-service-role/eks.amazonaws.com/AWSServiceRoleForAmazonEKS",
"Condition": {
"ForAnyValue:StringEquals": {
"iam:AWSServiceName": "eks"
}
}
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::111122223333:role/cluster-role-name"
}
]
}
```
## Outpost にローカル Kubernetes クラスターを作成する
このポリシー例には、*us-west-2* AWS リージョンの Outpost 上に *my-cluster* という名前の Amazon EKS ローカルクラスターを作成するために必要な最小限の許可が含まれています。AWS リージョンを、クラスターを作成する AWS リージョンに置き換えることができます。AWS マネジメントコンソール で **[ポリシーのアクションはリソースレベルの許可をサポートしていないため、`All resources` を選択する必要があります]** という警告が表示された場合、無視しても問題ありません。アカウントに `AWSServiceRoleForAmazonEKSLocalOutpost` ロールがすでにある場合、ポリシーから `iam:CreateServiceLinkedRole` アクションを削除できます。アカウントで Outpost 上に Amazon EKS ローカルクラスターを作成したことがある場合、削除していない限り、このロールはすでに存在します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:CreateCluster",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
},
{
"Action": [
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"iam:GetRole"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::111122223333:role/aws-service-role/outposts.eks-local.amazonaws.com/AWSServiceRoleForAmazonEKSLocalOutpost"
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole",
"iam:ListAttachedRolePolicies"
],
"Resource": "arn:aws:iam::111122223333:role/cluster-role-name"
},
{
"Action": [
"iam:CreateInstanceProfile",
"iam:TagInstanceProfile",
"iam:AddRoleToInstanceProfile",
"iam:GetInstanceProfile",
"iam:DeleteInstanceProfile",
"iam:RemoveRoleFromInstanceProfile"
],
"Resource": "arn:aws:iam::*:instance-profile/eks-local-*",
"Effect": "Allow"
}
]
}
```
## Kubernetes クラスターの更新
このポリシー例には、us-west-2 AWS リージョンに *my-cluster* という名前のクラスターを更新するために必要な最小限の許可が含まれています。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "eks:UpdateClusterVersion",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-cluster"
}
]
}
```
## すべてのクラスターの一覧表示または説明
このポリシーの例には、アカウント内のすべてのクラスターを一覧表示して記述するために必要な最小限の許可が含まれています。`update-kubeconfig` AWS CLI コマンドを使用するには、[IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)がクラスターを一覧表示および記述できる必要があります。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:DescribeCluster",
"eks:ListClusters"
],
"Resource": "*"
}
]
}
```
# Amazon EKS でのサービスにリンクされたロールの使用
Amazon エラスティック Kus サービス はAWS アイデンティティとアクセス管理 (IAM) の[サービberneteスにリンクされた役割](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)を使用します。サービスにリンクされた役割はAmazon EKS に直接リンクされた一意のタイプの IAM 役割です。サービスにリンクされた役割はAmazon EKS で事前定義されています。この役割にはサービスがユーザーに代わって他の AWS のサービスを呼び出すために必要な、すべてのアクセス許可が付与されています。
**Topics**
+ [Amazon EKS クラスターのロールの使用](using-service-linked-roles-eks.md)
+ [アマゾン EKS ノードグループでのロールの使用](using-service-linked-roles-eks-nodegroups.md)
+ [Amazon EKS Fargate プロファイルの役割の使用](using-service-linked-roles-eks-fargate.md)
+ [ロールを使用して Kubernetes クラスターを Amazon EKS に接続する](using-service-linked-roles-eks-connector.md)
+ [アウトポスト で アマゾン EKS ローカルクラスターの役割の使用](using-service-linked-roles-eks-outpost.md)
+ [Amazon EKS ダッシュボードのロールの使用](using-service-linked-roles-eks-dashboard.md)
# Amazon EKS クラスターのロールの使用
アマゾン エラスティック Kus サービス はAWS アイデンティティとアクセス管理 (IAM) の[サービberneteスにリンクされた役割](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)を使用します。サービスにリンクされた役割はアマゾン EKS に直接リンクされた一意のタイプの IAM 役割です。サービスにリンクされた役割はアマゾン EKS で事前定義されています。この役割にはサービスがユーザーに代わって他の AWS のサービスを呼び出すために必要な、すべてのアクセス許可が付与されています。
サービスにリンクされた役割を使用することで、必要なアクセス許可を手動で追加する必要がなくなるため、アマゾン EKS の設定が簡単になります。サービスにリンクされた役割のアクセス許可はアマゾン EKS により定義されます。特に指定されている場合を除き、アマゾン EKS のみがその役割を引き受けることができます。定義される許可は信頼ポリシーと許可ポリシーに含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
サービスリンク役割はまずその関連リソースを削除しなければ削除できません。これにより、リソースへのアクセス許可を不用意に削除することが防止され、アマゾン EKS リソースが保護されます。
サービスにリンクされた役割をサポートする他のサービスについては「[IAM と連動する AWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照し、[**サービス-linked roles**] (サービスにリンクされた役割) の列内で [**Yes**] (はい) と表記されたサービスを確認してください。サービスにリンクされた役割に関するドキュメントをサービスで表示するには[**はい**] リンクを選択してください。
## アマゾン EKS でのサービスにリンクされた役割のアクセス許可
Amazon EKS は、`AWSServiceRoleForAmazonEKS` という名前のサービスにリンクされたロールを使用します。このロールにより、Amazon EKS はアカウント内のクラスターを管理できます。アタッチされたポリシーにより、ロールはネットワークインターフェイス、セキュリティグループ、ログ、VPC のリソースを管理できるようになります。
**注記**
`AWSServiceRoleForAmazonEKS` サービスにリンクされたロールは、クラスターの作成に必要なロールとは異なります。詳細については「[Amazon EKS クラスター の IAM ロール](cluster-iam-role.md)」を参照してください。
`AWSServiceRoleForAmazonEKS` サービスリンク役割は役割の引き受けについて以下のサービスを信頼します。
+ `eks.amazonaws.com`
役割のアクセス許可ポリシーは指定したリソースに対して以下のアクションを実行することを アマゾン EKS に許可します。
+ [アマゾンEKSサービスロールポリシー](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html)
サービスにリンクされた役割の作成、編集、削除を IAM エンティティ (ユーザー、グループ、役割など) に許可するにはアクセス許可を設定する必要があります。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。
## アマゾン EKS でのサービスにリンクされた役割の作成
サービスリンク役割を手動で作成する必要はありません。AWS マネジメントコンソール、AWS CLI、または AWS API でクラスターを作成すると、アマゾン EKS によってサービスリンク役割が作成されます。
このサービスリンク役割を削除した後で再度作成する必要が生じた場合は同じ方法でアカウントに役割を再作成できます。サービスにリンクされた役割はクラスターの作成時に アマゾン EKS で自動的に再作成されます。
## アマゾン EKS でのサービスにリンクされた役割の編集
アマゾン EKS では`AWSServiceRoleForAmazonEKS` のサービスにリンクされた役割を編集することはできません。サービスにリンクされた役割を作成すると、多くのエンティティによって役割が参照される可能性があるため、役割名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については『*IAM ユーザーガイド*』の「[サービスにリンクされた役割の編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。
## アマゾン EKS でのサービスにリンクされた役割の削除
サービスリンク役割が必要な機能またはサービスが不要になった場合にはその役割を削除することをお勧めします。そうすることで、モニタリングや保守が積極的に行われていない未使用のエンティティを排除できます。ただし、手動で削除する前に、サービスリンク役割をクリーンアップする必要があります。
### サービスリンク役割のクリーンアップ
IAM を使用してサービスにリンクされた役割を削除するには最初に、その役割で使用されているリソースをすべて削除する必要があります。
**注記**
リソースの削除を試みた際に、対応する役割が アマゾン EKS サービスで使用されている場合、削除が失敗することがあります。失敗した場合は数分待ってから操作を再試行してください。
1. [アマゾン EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで **[Clusters]** (クラスター) を選択してください。
1. クラスターにノードグループまたは Fargate プロファイルがある場合は、クラスターを削除する前にそれらを削除する必要があります。詳細については「[クラスターからマネージドノードグループを削除する](delete-managed-node-group.md)」および「[Fargate プロファイルを削除する](delete-fargate-profile.md)」を参照してください。
1. [**Clusters (クラスター)**] ページで、削除するクラスターを選択し、[**Delete (削除)**] を選択してください。
1. 削除確認ウィンドウにクラスター名を入力し、[**Delete (削除)**] を選択してください。
1. この手順をアカウント内の他のすべてのクラスターに対して繰り返します。すべての削除操作が完了するまで待ちます。
### サービスリンク役割の手動による削除
サービスにリンクされた役割 `AWSServiceRoleForAmazonEKS` を削除するにはIAM コンソール、AWS CLI、または AWS API を使用します。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割の削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。
## Amazon EKS のサービスにリンクされた役割がサポートされるリージョン
Amazon EKS ではこのサービスを利用できるすべてのリージョンで、サービスにリンクされた役割の使用がサポートされます。詳細については「[Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html)」(Amazon EKS エンドポイントとクォータ) を参照してください。
# アマゾン EKS ノードグループでのロールの使用
アマゾン EKS はAWS アイデンティティとアクセス管理 (IAM) の[サービスにリンクされた役割](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)を使用します。サービスにリンクされた役割はアマゾン EKS に直接リンクされた一意のタイプの IAM 役割です。サービスにリンクされた役割はアマゾン EKS で事前定義されています。この役割にはサービスがユーザーに代わって他の AWS のサービスを呼び出すために必要な、すべてのアクセス許可が付与されています。
サービスにリンクされた役割を使用することで、必要なアクセス許可を手動で追加する必要がなくなるため、アマゾン EKS の設定が簡単になります。サービスにリンクされた役割のアクセス許可はアマゾン EKS により定義されます。特に指定されている場合を除き、アマゾン EKS のみがその役割を引き受けることができます。定義される許可は信頼ポリシーと許可ポリシーに含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
サービスリンク役割はまずその関連リソースを削除しなければ削除できません。これにより、リソースへのアクセス許可を不用意に削除することが防止され、アマゾン EKS リソースが保護されます。
サービスにリンクされた役割をサポートする他のサービスについては「[IAM と連動する AWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照し、[**サービス-linked roles**] (サービスにリンクされた役割) の列内で [**Yes**] (はい) と表記されたサービスを確認してください。サービスにリンクされた役割に関するドキュメントをサービスで表示するには[**はい**] リンクを選択してください。
## アマゾン EKS でのサービスにリンクされた役割のアクセス許可
アマゾン EKS は`AWSServiceRoleForAmazonEKSNodegroup` という名前のサービスにリンクされたロールを使用します。このロールにより、アマゾン EKS はアカウント内のノードグループを管理できます。アタッチされた `AWSServiceRoleForAmazonEKSNodegroup` ポリシーにより、ロールは 自動スケーリング グループ、セキュリティグループ、起動テンプレート、および IAM インスタンスプロファイルのリソースを管理できるようになります。詳細については「[AWS 管理ポリシー: AWSServiceRoleForAmazonEKSNodegroup](security-iam-awsmanpol.md#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup)」を参照してください。
`AWSServiceRoleForAmazonEKSNodegroup` サービスリンク役割は役割の引き受けについて以下のサービスを信頼します。
+ `eks-nodegroup.amazonaws.com`
ロールのアクセス許可ポリシーは指定したリソースに対して以下のアクションを実行することを アマゾン EKS に許可します。
+ [AWSServiceRoleForアマゾンEKSNodegroup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html)
サービスにリンクされたロールの作成、編集、削除を IAM エンティティ (ユーザー、グループ、ロールなど) に許可するにはアクセス許可を設定する必要があります。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。
## アマゾン EKS でのサービスにリンクされた役割の作成
サービスリンクロールを手動で作成する必要はありません。AWS マネジメントコンソール、AWS CLI、または AWS API でノードグループを作成すると、アマゾン EKS によってサービスリンクロールが作成されます。
**重要**
このサービスリンクロールはこのロールでサポートされている機能を使用する別のサービスでアクションが完了した場合にアカウントに表示されます。2017 年 1 月 1 日より前に アマゾン EKS サービスを使用している場合、サービスにリンクされたロールのサポートが開始された時点で、AWSServiceRoleForアマゾンEKSNodegroup ロールは アマゾン EKS によりアカウントに作成されています。詳細については[IAM アカウントに新しいロールが表示される](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared)を参照してください。
### Amazon EKS でのサービスにリンクされた役割の作成 (AWS API)
サービスリンクロールを手動で作成する必要はありません。AWS マネジメントコンソール、AWS CLI、または AWS API でマネージド型ノードグループを作成すると、アマゾン EKS によってサービスリンクロールが作成されます。
このサービスリンクロールを削除した後で再度作成する必要が生じた場合は同じ方法でアカウントにロールを再作成できます。別のマネージド型ノードグループを作成すると、Amazon EKS によってサービスリンク役割が再度作成されます。
## アマゾン EKS でのサービスにリンクされた役割の編集
アマゾン EKS では`AWSServiceRoleForAmazonEKSNodegroup` のサービスにリンクされた役割を編集することはできません。サービスにリンクされた役割を作成すると、多くのエンティティによって役割が参照される可能性があるため、役割名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については『*IAM ユーザーガイド*』の「[サービスにリンクされた役割の編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。
## アマゾン EKS でのサービスにリンクされた役割の削除
サービスリンク役割が必要な機能またはサービスが不要になった場合にはその役割を削除することをお勧めします。そうすることで、モニタリングや保守が積極的に行われていない未使用のエンティティを排除できます。ただし、手動で削除する前に、サービスリンク役割をクリーンアップする必要があります。
### サービスリンク役割のクリーンアップ
IAM を使用してサービスにリンクされた役割を削除するには最初に、その役割で使用されているリソースをすべて削除する必要があります。
**注記**
リソースの削除を試みた際に、対応する役割が アマゾン EKS サービスで使用されている場合、削除が失敗することがあります。失敗した場合は数分待ってから操作を再試行してください。
1. [アマゾン EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで **[クラスター]** を選択してください。
1. **[Compute]** (コンピューティング) タブを選択してください。
1. **[Node groups]** (ノードグループ) セクションで、削除するノードグループを選択してください。
1. 削除確認ウィンドウにノードグループの名前を入力し、[**Delete (削除)**] を選択してください。
1. この手順をクラスター内の他のすべてのノードグループに対して繰り返します。すべての削除操作が完了するまで待ちます。
### サービスリンク役割の手動による削除
サービスにリンクされた役割 `AWSServiceRoleForAmazonEKSNodegroup` を削除するにはIAM コンソール、AWS CLI、または AWS API を使用します。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割の削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。
## Amazon EKS のサービスにリンクされた役割がサポートされるリージョン
Amazon EKS ではこのサービスを利用できるすべてのリージョンで、サービスにリンクされた役割の使用がサポートされます。詳細については「[Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html)」(Amazon EKS エンドポイントとクォータ) を参照してください。
# Amazon EKS Fargate プロファイルの役割の使用
アマゾン EKS はAWS アイデンティティとアクセス管理 (IAM) の[サービスにリンクされた役割](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)を使用します。サービスにリンクされた役割はアマゾン EKS に直接リンクされた一意のタイプの IAM 役割です。サービスにリンクされた役割はアマゾン EKS で事前定義されています。この役割にはサービスがユーザーに代わって他の AWS のサービスを呼び出すために必要な、すべてのアクセス許可が付与されています。
サービスにリンクされた役割を使用することで、必要なアクセス許可を手動で追加する必要がなくなるため、アマゾン EKS の設定が簡単になります。サービスにリンクされた役割のアクセス許可はアマゾン EKS により定義されます。特に指定されている場合を除き、アマゾン EKS のみがその役割を引き受けることができます。定義される許可は信頼ポリシーと許可ポリシーに含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
サービスリンク役割はまずその関連リソースを削除しなければ削除できません。これにより、リソースへのアクセス許可を不用意に削除することが防止され、アマゾン EKS リソースが保護されます。
サービスにリンクされた役割をサポートする他のサービスについては「[IAM と連動する AWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照し、[**サービス-linked roles**] (サービスにリンクされた役割) の列内で [**Yes**] (はい) と表記されたサービスを確認してください。サービスにリンクされた役割に関するドキュメントをサービスで表示するには[**はい**] リンクを選択してください。
## アマゾン EKS でのサービスにリンクされた役割のアクセス許可
アマゾン EKS は`AWSServiceRoleForAmazonEKSForFargate` という名前のサービスにリンクされた役割を使用します。このロールにより、Amazon EKS Fargate は Fargate Pod に必要な VPC ネットワーキングを設定できます。アタッチされたポリシーにより、役割は エラスティック・ネットワーク・インターフェイス の作成と削除、エラスティック・ネットワーク・インターフェイス とリソースの記述ができるようになります。
`AWSServiceRoleForAmazonEKSForFargate` サービスリンク役割は役割の引き受けについて以下のサービスを信頼します。
+ `eks-fargate.amazonaws.com`
役割のアクセス許可ポリシーは指定したリソースに対して以下のアクションを実行することを アマゾン EKS に許可します。
+ [アAmazonEKSForFargateServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html)
サービスリンク役割の作成、編集、削除を IAM エンティティ (ユーザー、グループ、役割など) に許可するにはアクセス許可を設定する必要があります。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。
## アマゾン EKS でのサービスにリンクされた役割の作成
サービスリンク役割を手動で作成する必要はありません。AWS マネジメントコンソール、AWS CLI、または AWS API で Fargate プロファイルを作成すると、アマゾン EKS がサービスリンク役割を作成します。
**重要**
このサービスリンク役割はこの役割でサポートされている機能を使用する別のサービスでアクションが完了した場合にアカウントに表示されます。2019 年 12 月 13 日より前に Amazon EKS サービスを使用している場合、サービスにリンクされた役割のサポートが開始された時点で、AWSServiceRoleForAmazonEKSForFargate は Amazon EKS によりアカウントに作成されています。詳細については「[IAM アカウントに表示される新しい役割](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared)」を参照してください。
### Amazon EKS でのサービスにリンクされた役割の作成 (AWS API)
サービスリンク役割を手動で作成する必要はありません。AWS マネジメントコンソール、AWS CLI、または AWS API で Fargate プロファイルを作成すると、アマゾン EKS がサービスリンク役割を作成します。
このサービスリンク役割を削除した後で再度作成する必要が生じた場合は同じ方法でアカウントに役割を再作成できます。別のマネージド型ノードグループを作成すると、Amazon EKS によってサービスリンク役割が再度作成されます。
## アマゾン EKS でのサービスにリンクされた役割の編集
アマゾン EKS では`AWSServiceRoleForAmazonEKSForFargate` のサービスにリンクされた役割を編集することはできません。サービスにリンクされた役割を作成すると、多くのエンティティによって役割が参照される可能性があるため、役割名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については『*IAM ユーザーガイド*』の「[サービスにリンクされた役割の編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。
## アマゾン EKS でのサービスにリンクされた役割の削除
サービスリンク役割が必要な機能またはサービスが不要になった場合にはその役割を削除することをお勧めします。そうすることで、モニタリングや保守が積極的に行われていない未使用のエンティティを排除できます。ただし、手動で削除する前に、サービスリンク役割をクリーンアップする必要があります。
### サービスリンク役割のクリーンアップ
IAM を使用してサービスにリンクされた役割を削除するには最初に、その役割で使用されているリソースをすべて削除する必要があります。
**注記**
リソースの削除を試みた際に、対応する役割が アマゾン EKS サービスで使用されている場合、削除が失敗することがあります。失敗した場合は数分待ってから操作を再試行してください。
1. [アマゾン EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで **[Clusters]** (クラスター) を選択してください。
1. **[Clusters]** (クラスター) ページで、クラスターを選択してください。
1. **[Compute]** (コンピューティング) タブを選択してください。
1. **[Fargate profiles]** (Fargateプロファイル) セクションに Fargate プロファイルがある場合、それぞれを個別に選択し、**[Delete]** (削除)を選択してください。
1. 削除確認ウィンドウにプロファイルの名前を入力し、[**Delete (削除)**] を選択してください。
1. クラスター内のその他の Fargate プロファイルと、アカウント内のその他のクラスターについて、この手順を繰り返します。
### サービスリンク役割の手動による削除
IAM コンソール、AWS CLI、または AWS API を使用して、AWSServiceRoleForAmazonEKSForFargate のサービスにリンクされた役割を削除します。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割の削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。
## Amazon EKS のサービスにリンクされた役割がサポートされるリージョン
Amazon EKS ではこのサービスを利用できるすべてのリージョンで、サービスにリンクされた役割の使用がサポートされます。詳細については「[Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html)」(Amazon EKS エンドポイントとクォータ) を参照してください。
# ロールを使用して Kubernetes クラスターを Amazon EKS に接続する
Amazon EKS はAWS アイデンティティとアクセス管理 (IAM) の[サービスにリンクされた役割](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)を使用します。サービスにリンクされた役割はAmazon EKS に直接リンクされた一意のタイプの IAM 役割です。サービスにリンクされた役割はAmazon EKS で事前定義されています。この役割にはサービスがユーザーに代わって他の AWS のサービスを呼び出すために必要な、すべてのアクセス許可が付与されています。
サービスにリンクされた役割を使用することで、必要なアクセス許可を手動で追加する必要がなくなるため、Amazon EKS の設定が簡単になります。サービスにリンクされた役割のアクセス許可はAmazon EKS により定義されます。特に指定されている場合を除き、Amazon EKS のみがその役割を引き受けることができます。定義される許可は信頼ポリシーと許可ポリシーに含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
サービスリンク役割はまずその関連リソースを削除しなければ削除できません。これにより、リソースへのアクセス許可を不用意に削除することが防止され、Amazon EKS リソースが保護されます。
サービスにリンクされた役割をサポートする他のサービスについては「[IAM と連動する AWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照し、[**サービス-linked roles**] (サービスにリンクされた役割) の列内で [**Yes**] (はい) と表記されたサービスを確認してください。サービスにリンクされた役割に関するドキュメントをサービスで表示するには[**はい**] リンクを選択してください。
## Amazon EKS でのサービスにリンクされた役割のアクセス許可
Amazon EKS は`AWSServiceRoleForAmazonEKSConnector` という名前のサービスにリンクされた役割を使用します。このロールにより、Amazon EKS は Kubernetes クラスターに接続できます。アタッチされたポリシーにより、ロールは、登録された Kubernetes クラスターに接続するために必要なリソースを管理できます。
`AWSServiceRoleForAmazonEKSConnector` サービスリンク役割は役割の引き受けについて以下のサービスを信頼します。
+ `eks-connector.amazonaws.com`
役割のアクセス許可ポリシーは指定したリソースに対して以下のアクションを実行することを Amazon EKS に許可します。
+ [AmazonEKSConnectorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html)
サービスリンク役割の作成、編集、削除を IAM エンティティ (ユーザー、グループ、役割など) に許可するにはアクセス許可を設定する必要があります。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。
このロールは、SSM (Systems Manager) アクセス許可を使用して安全な接続を確立し、接続された Kubernetes クラスターを管理します。
## Amazon EKS でのサービスにリンクされた役割の作成
サービスにリンクされた役割を手動で作成してクラスターを接続する必要はありません。AWS マネジメントコンソール、AWS CLI、`eksctl` または AWS API でクラスターを接続すると、Amazon EKS によってサービスにリンクされた役割が作成されます。
このサービスリンク役割を削除した後で再度作成する必要が生じた場合は同じ方法でアカウントに役割を再作成できます。サービスにリンクされた役割はクラスターの接続時に Amazon EKS で自動的に再作成されます。
## Amazon EKS でのサービスにリンクされた役割の編集
Amazon EKS では`AWSServiceRoleForAmazonEKSConnector` のサービスにリンクされた役割を編集することはできません。サービスにリンクされた役割を作成すると、多くのエンティティによって役割が参照される可能性があるため、役割名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については『*IAM ユーザーガイド*』の「[サービスにリンクされた役割の編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。
## Amazon EKS でのサービスにリンクされた役割の削除
サービスリンク役割が必要な機能またはサービスが不要になった場合にはその役割を削除することをお勧めします。そうすることで、モニタリングや保守が積極的に行われていない未使用のエンティティを排除できます。ただし、手動で削除する前に、サービスリンク役割をクリーンアップする必要があります。
### サービスリンク役割のクリーンアップ
IAM を使用してサービスにリンクされた役割を削除するには最初に、その役割で使用されているリソースをすべて削除する必要があります。
**注記**
リソースの削除を試みた際に、対応する役割が Amazon EKS サービスで使用されている場合、削除が失敗することがあります。失敗した場合は数分待ってから操作を再試行してください。
1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで **[Clusters]** (クラスター) を選択してください。
1. **[Clusters]** (クラスター) ページで、クラスターを選択してください。
1. **登録解除**タブをクリックし、**Ok** タブを選択してください。
### サービスリンク役割の手動による削除
IAM コンソール、AWS CLI、または AWS API を使用して、AWSServiceRoleForAmazonEKSConnector のサービスにリンクされた役割を削除します。詳細については IAM ユーザーガイド の「[サービスにリンクされた役割の削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。
# アウトポスト で アマゾン EKS ローカルクラスターの役割の使用
アマゾン エラスティック Kus サービス はAWS アイデンティティとアクセス管理 (IAM) の[サービberneteスにリンクされた役割](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)を使用します。サービスにリンクされた役割はアマゾン EKS に直接リンクされた一意のタイプの IAM 役割です。サービスにリンクされた役割はアマゾン EKS で事前定義されています。この役割にはサービスがユーザーに代わって他の AWS のサービスを呼び出すために必要な、すべてのアクセス許可が付与されています。
サービスにリンクされた役割を使用することで、必要なアクセス許可を手動で追加する必要がなくなるため、アマゾン EKS の設定が簡単になります。サービスにリンクされた役割のアクセス許可はアマゾン EKS により定義されます。特に指定されている場合を除き、アマゾン EKS のみがその役割を引き受けることができます。定義される許可は信頼ポリシーと許可ポリシーに含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
サービスリンク役割はまずその関連リソースを削除しなければ削除できません。これにより、リソースへのアクセス許可を不用意に削除することが防止され、アマゾン EKS リソースが保護されます。
サービスにリンクされた役割をサポートする他のサービスについては「[IAM と連動する AWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照し、[**サービス-linked roles**] (サービスにリンクされた役割) の列内で [**Yes**] (はい) と表記されたサービスを確認してください。サービスにリンクされた役割に関するドキュメントをサービスで表示するには[**はい**] リンクを選択してください。
## アマゾン EKS でのサービスにリンクされた役割のアクセス許可
アマゾン EKS は`AWSServiceRoleForAmazonEKSLocalOutpost` という名前のサービスにリンクされた役割を使用します。この役割により、アマゾン EKS はアカウント内のローカルクラスターを管理できます。アタッチされたポリシーにより、役割はネットワークインターフェイス、セキュリティグループ、ログ、アマゾン EC2 インスタンスのリソースを管理できるようになります。
**注記**
`AWSServiceRoleForAmazonEKSLocalOutpost` サービスにリンクされた役割はクラスターの作成に必要な役割とは異なります。詳細については「[Amazon EKS クラスター の IAM ロール](cluster-iam-role.md)」を参照してください。
`AWSServiceRoleForAmazonEKSLocalOutpost` サービスリンク役割は役割の引き受けについて以下のサービスを信頼します。
+ `outposts.eks-local.amazonaws.com`
役割のアクセス許可ポリシーは指定したリソースに対して以下のアクションを実行することを アマゾン EKS に許可します。
+ [アマゾンEKSサービスロールポリシー](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html)
サービスにリンクされた役割の作成、編集、削除を IAM エンティティ (ユーザー、グループ、役割など) に許可するにはアクセス許可を設定する必要があります。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。
## アマゾン EKS でのサービスにリンクされた役割の作成
サービスリンク役割を手動で作成する必要はありません。AWS マネジメントコンソール、AWS CLI、または AWS API でクラスターを作成すると、アマゾン EKS によってサービスリンク役割が作成されます。
このサービスリンク役割を削除した後で再度作成する必要が生じた場合は同じ方法でアカウントに役割を再作成できます。サービスにリンクされた役割はクラスターの作成時に アマゾン EKS で自動的に再作成されます。
## アマゾン EKS でのサービスにリンクされた役割の編集
アマゾン EKS では`AWSServiceRoleForAmazonEKSLocalOutpost` のサービスにリンクされた役割を編集することはできません。サービスリンク役割を作成すると、多くのエンティティによって役割が参照される可能性があるため、役割名を変更することはできません ただし、IAM を使用した役割記述の編集はできます。詳細については『*IAM ユーザーガイド*』の「[サービスにリンクされた役割の編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。
## アマゾン EKS でのサービスにリンクされた役割の削除
サービスリンク役割が必要な機能またはサービスが不要になった場合にはその役割を削除することをお勧めします。そうすることで、モニタリングや保守が積極的に行われていない未使用のエンティティを排除できます。ただし、手動で削除する前に、サービスリンク役割をクリーンアップする必要があります。
### サービスリンク役割のクリーンアップ
IAM を使用してサービスにリンクされた役割を削除するには最初に、その役割で使用されているリソースをすべて削除する必要があります。
**注記**
リソースの削除を試みた際に、対応する役割が アマゾン EKS サービスで使用されている場合、削除が失敗することがあります。失敗した場合は数分待ってから操作を再試行してください。
1. [アマゾン EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。
1. 左のナビゲーションペインで アマゾン EKS **[Clusters]** (クラスター) を選択してください。
1. クラスターにノードグループまたは Fargate プロファイルがある場合はクラスターを削除する前にそれらを削除する必要があります。詳細については「[クラスターからマネージドノードグループを削除する](delete-managed-node-group.md)」および「[Fargate プロファイルを削除する](delete-fargate-profile.md)」を参照してください。
1. [**Clusters (クラスター)**] ページで、削除するクラスターを選択し、[**Delete (削除)**] を選択してください。
1. 削除確認ウィンドウにクラスター名を入力し、[**Delete (削除)**] を選択してください。
1. この手順をアカウント内の他のすべてのクラスターに対して繰り返します。すべての削除操作が完了するまで待ちます。
### サービスリンク役割の手動による削除
サービスにリンクされた役割 `AWSServiceRoleForAmazonEKSLocalOutpost` を削除するにはIAM コンソール、AWS CLI、または AWS API を使用します。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割の削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。
## Amazon EKS のサービスにリンクされた役割がサポートされるリージョン
Amazon EKS ではこのサービスを利用できるすべてのリージョンで、サービスにリンクされた役割の使用がサポートされます。詳細については「[Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html)」(Amazon EKS エンドポイントとクォータ) を参照してください。
# Amazon EKS ダッシュボードのロールの使用
Amazon EKS ダッシュボードでは、このサービスにリンクされたロールを使用して、複数のリージョンとアカウントからクラスターリソースに関する情報を集約します。ダッシュボードは AWS Organizations と統合され、組織内の複数のアカウントに関する情報を安全に読み取ります。
Amazon EKS ダッシュボードの詳細については、「[EKS ダッシュボードを使用してクラスターリソースに関する集計データを表示する](cluster-dashboard.md)」を参照してください。
## 背景
Amazon EKS はAWS アイデンティティとアクセス管理 (IAM) の[サービスにリンクされた役割](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role)を使用します。サービスにリンクされた役割はAmazon EKS に直接リンクされた一意のタイプの IAM 役割です。サービスにリンクされた役割はAmazon EKS で事前定義されています。この役割にはサービスがユーザーに代わって他の AWS のサービスを呼び出すために必要な、すべてのアクセス許可が付与されています。
サービスにリンクされた役割を使用することで、必要なアクセス許可を手動で追加する必要がなくなるため、Amazon EKS の設定が簡単になります。サービスにリンクされた役割のアクセス許可はAmazon EKS により定義されます。特に指定されている場合を除き、Amazon EKS のみがその役割を引き受けることができます。定義される許可は信頼ポリシーと許可ポリシーに含まれており、その許可ポリシーを他の IAM エンティティにアタッチすることはできません。
サービスリンク役割はまずその関連リソースを削除しなければ削除できません。これにより、リソースへのアクセス許可を不用意に削除することが防止され、Amazon EKS リソースが保護されます。
サービスにリンクされた役割をサポートする他のサービスについては「[IAM と連動する AWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照し、[**サービス-linked roles**] (サービスにリンクされた役割) の列内で [**Yes**] (はい) と表記されたサービスを確認してください。サービスにリンクされた役割に関するドキュメントをサービスで表示するには[**はい**] リンクを選択してください。
## Amazon EKS でのサービスにリンクされた役割のアクセス許可
Amazon EKS は`AWSServiceRoleForAmazonEKSDashboard` という名前のサービスにリンクされた役割を使用します。このロールにより、Amazon EKS はクラスターリソースに関して集約された情報を含む EKS ダッシュボードを生成して表示できます。アタッチされた `AmazonEKSDashboardServiceRolePolicy` ポリシーにより、ロールは 自動スケーリング グループ、セキュリティグループ、起動テンプレート、および IAM インスタンスプロファイルのリソースを管理できるようになります。詳細については、「[AWS マネージドポリシー: AmazonEKSDashboardServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy)」を参照してください。
`AWSServiceRoleForAmazonEKSDashboard` サービスリンク役割は役割の引き受けについて以下のサービスを信頼します。
+ `dashboard.eks.amazonaws.com`
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKSDashboardServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json)」を参照してください。
サービスリンク役割の作成、編集、削除を IAM エンティティ (ユーザー、グループ、役割など) に許可するにはアクセス許可を設定する必要があります。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割のアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。
## Amazon EKS でのサービスにリンクされた役割の作成
サービスリンク役割を手動で作成する必要はありません。AWS コンソールでダッシュボードを有効にすると、Amazon EKS によってサービスにリンクされたロールが作成されます。
EKS ダッシュボードの有効化についての詳細は、「[EKS ダッシュボードと AWS Organizations の統合を設定する](cluster-dashboard-orgs.md)」を参照してください。
**重要**
このサービスリンク役割はこの役割でサポートされている機能を使用する別のサービスでアクションが完了した場合にアカウントに表示されます。
## Amazon EKS でのサービスにリンクされた役割の編集
Amazon EKS では`AWSServiceRoleForAmazonEKSDashboard` のサービスにリンクされた役割を編集することはできません。サービスにリンクされた役割を作成すると、多くのエンティティによって役割が参照される可能性があるため、役割名を変更することはできません。ただし、IAM を使用してロールの説明を編集することはできます。詳細については『*IAM ユーザーガイド*』の「[サービスにリンクされた役割の編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)」を参照してください。
## Amazon EKS でのサービスにリンクされた役割の削除
サービスリンク役割が必要な機能またはサービスが不要になった場合にはその役割を削除することをお勧めします。そうすることで、モニタリングや保守が積極的に行われていない未使用のエンティティを排除できます。ただし、手動で削除する前に、サービスリンク役割をクリーンアップする必要があります。
### サービスリンク役割のクリーンアップ
IAM を使用してサービスにリンクされた役割を削除するには最初に、その役割で使用されているリソースをすべて削除する必要があります。
**注記**
リソースの削除を試みた際に、対応する役割が Amazon EKS サービスで使用されている場合、削除が失敗することがあります。失敗した場合は数分待ってから操作を再試行してください。
EKS ダッシュボードの無効化についての詳細は、「[EKS ダッシュボードと AWS Organizations の統合を設定する](cluster-dashboard-orgs.md)」を参照してください。
### サービスリンク役割の手動による削除
サービスにリンクされた役割 `AWSServiceRoleForAmazonEKSDashboard` を削除するにはIAM コンソール、AWS CLI、または AWS API を使用します。詳細については*IAM ユーザーガイド* の「[サービスにリンクされた役割の削除](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)」を参照してください。
## Amazon EKS のサービスにリンクされた役割がサポートされるリージョン
Amazon EKS ではこのサービスを利用できるすべてのリージョンで、サービスにリンクされた役割の使用がサポートされます。詳細については「[Amazon EKS endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/eks.html)」(Amazon EKS エンドポイントとクォータ) を参照してください。
# Amazon EKS Pod 実行 IAM ロール
Pod を AWS Fargate インフラストラクチャで実行するには、Amazon EKS Pod 実行ロールが必要になります。
クラスターが AWS Fargate インフラストラクチャ上で Pod を作成する場合は、Fargate インフラストラクチャ上で実行されているコンポーネントがユーザーに代わって AWS API を呼び出す必要があります。これは、Amazon ECR からコンテナイメージをプルしたり、ログを他の AWS サービスにルーティングしたりするなどのアクションを実行できるようにするためです。Amazon EKS の Pod 実行ロールにより、これらを行うための IAM アクセス許可が付与されます。
Fargate プロファイルを作成するときは、プロファイルを使用して Fargate インフラストラクチャで Amazon EKS コンポーネントを実行できるように、Pod 実行ロールを指定する必要があります。このロールは、承認のためにクラスターの Kubernetes [ロールベースのアクセス制御](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) (RBAC) に追加されます。これにより、Fargate インフラストラクチャで実行されている `kubelet` が Amazon EKS クラスターに登録され、クラスター内でノードとして表示されるようになります。
**注記**
Fargate プロファイルには、Amazon EC2 ノードグループとは異なる IAM ロールが必要です。
**重要**
Fargate Pod で実行されているコンテナは、Pod 実行ロールに関連付けられた IAM アクセス許可を引き受けることはできません。Fargate Pod 内のコンテナに他の AWS サービスへのアクセス許可を付与するには、[IAM ロールをサービスアカウントとして](iam-roles-for-service-accounts.md)使用する必要があります。
Fargate プロファイルを作成する前に、[AmazonEKSFargatePodExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html) で IAM ロールを作成する必要があります。
## 正しく設定された既存の Pod 実行ロールをチェックする
次の手順を使用して、正しく設定された Amazon EKS の Pod 実行ロールがアカウントに既に存在しているかどうかをチェックします。「混乱した代理」のセキュリティ上の問題を回避するには、ロールが `SourceArn` に基づいてアクセスを制限することが重要です。必要に応じて実行ロールを変更し、他のクラスター上で Fargate プロファイルのサポートを含めることができます。
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. **[ロール]** ページで、ロールの一覧から **AmazonEKSFargatePodExecutionRole** を検索します。ロールが存在しない場合は、「[Amazon EKS での Pod 実行ロールの作成](#create-pod-execution-role)」を参照してロールを作成します。ロールが存在する場合は、そのロールを選択します。
1. **[AmazonEKSFargatePodExecutionRole]** ページで、次の操作を実行します。
1. **[許可]** を選択してください。
1. **AmazonEKSFargatePodExecutionRolePolicy** Amazon マネージドポリシーがロールにアタッチされていることを確認します。
1. **[信頼関係]** を選択します。
1. **[信頼ポリシーを編集]** を選択します。
1. **[信頼ポリシーを編集]** ページで、信頼関係に次のポリシーが含まれており、クラスター上で Fargate プロファイルの行が存在していることを確認します。そうである場合は、**[キャンセル]** を選択します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
ポリシーは一致するが、クラスター上で Fargate プロファイルを指定する行が存在しない場合は、`ArnLike` オブジェクトの上部に次の行を追加します。*region-code* はクラスターがある AWS リージョンに、*111122223333* はアカウント ID に、*my-cluster* はクラスターの名前に置き換えます。
```
"aws:SourceArn": "arn:aws:eks:region-code:111122223333:fargateprofile/my-cluster/*",
```
ポリシーが一致しない場合は、前のポリシー全体をフォームにコピーして、**[ポリシーの更新]** を選択します。*region-code* を、クラスターのある AWS リージョンに置き換えます。アカウントで、すべての AWS リージョンで同じロールを使用する場合は、*region-code* を `*` に置き換えます。*111122223333* をアカウント ID に、*my-cluster* をクラスター名に置き換えます。アカウント内のすべてのクラスターに同じロールを使用する場合は、*my-cluster* を `*` に置き換えます。
## Amazon EKS での Pod 実行ロールの作成
クラスター用の Amazon EKS Pod 実行ロールをまだ作成していない場合は、AWS マネジメントコンソール または AWS CLI を使用して作成できます。
AWS マネジメントコンソール
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. **[ロール]** ページで、**[ロールの作成]** を選択してください。
1. **[信頼されたエンティティを選択]** ページで、以下の操作を実行してください：
1. **[信頼するエンティティのタイプ]** で **[AWS サービス]** を選択します。
1. [**他の AWS サービスのユースケース**] ドロップダウンリストから、[**EKS**] を選択します。
1. **[EKS - Fargate Pod]** を選択します。
1. [**次へ**] を選択します。
1. **[アクセス許可を追加]** ページで **[次へ]** を選択します。
1. **[名前を付けて、レビューし、作成する]** ページで、以下の操作を実行します。
1. **[ロール名]** に、`AmazonEKSFargatePodExecutionRole` などのロールの一意の名前を入力します。
1. **[タグの追加 (オプション)]** で、タグをキーバリューのペアとして添付して、メタデータをロールに追加します。IAM でのタグの使用に関する詳細については『*IAM ユーザーガイド*』の「[IAM リソースにタグを付ける](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html)」を参照してください。
1. [**ロールの作成**] を選択してください。
1. **[ロール]** ページで、ロールの一覧から **AmazonEKSFargatePodExecutionRole** を検索します。ロールを選択します。
1. **[AmazonEKSFargatePodExecutionRole]** ページで、次の操作を実行します。
1. **[信頼関係]** を選択します。
1. **[信頼ポリシーを編集]** を選択します。
1. **[信頼ポリシーを編集]** ページで、次の操作を実行します。
1. 次の内容をコピーして、**[信頼ポリシーを編集]** フォームに貼り付けます。*region-code* を、クラスターのある AWS リージョンに置き換えます。アカウントで、すべての AWS リージョンで同じロールを使用する場合は、*region-code* を `*` に置き換えます。*111122223333* をアカウント ID に、*my-cluster* をクラスター名に置き換えます。アカウント内のすべてのクラスターに同じロールを使用する場合は、*my-cluster* を `*` に置き換えます。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. [**ポリシーの更新**] を選択してください。
AWS CLI
1. 次の内容をコピーして、`pod-execution-role-trust-policy.json` という名前のファイルに貼り付けます。*region-code* を、クラスターのある AWS リージョンに置き換えます。アカウントで、すべての AWS リージョンで同じロールを使用する場合は、*region-code* を `*` に置き換えます。*111122223333* をアカウント ID に、*my-cluster* をクラスター名に置き換えます。アカウント内のすべてのクラスターに同じロールを使用する場合は、*my-cluster* を `*` に置き換えます。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:eks:us-east-1:111122223333:fargateprofile/my-cluster/*"
}
},
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Pod 実行 IAM ロールを作成します。
```
aws iam create-role \
--role-name AmazonEKSFargatePodExecutionRole \
--assume-role-policy-document file://"pod-execution-role-trust-policy.json"
```
1. このロールに、必要な Amazon EKS 管理の IAM ポリシーをアタッチします。
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy \
--role-name AmazonEKSFargatePodExecutionRole
```
# Amazon EKS コネクタの IAM ロール
Kubernetes クラスターを接続して AWS マネジメントコンソール に表示することができます。Kubernetes クラスターに接続するには、IAM ロールを作成します。
## 既存の EKS Connector ロールの確認
以下の手順を使用して、アカウントに既に Amazon EKS コネクタロールがあるかどうかを確認できます。
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. ロールのリストで `AmazonEKSConnectorAgentRole` を検索します。`AmazonEKSConnectorAgentRole` が含まれているロールが存在しない場合は、[Amazon EKS コネクタエージェントロールの作成](#create-connector-role) を参照してロールを作成します。`AmazonEKSConnectorAgentRole` が含まれているロールが存在する場合はこのロールを選択してアタッチされているポリシーを表示します。
1. **[許可]** を選択してください。
1. **AmazonEKSConnectorAgentPolicy** 管理ポリシーがロールにアタッチされていることを確認します。ポリシーがアタッチされている場合、Amazon EKS Connector ロールは適切に設定されています。
1. **[信頼関係]** を選択し、**[信頼ポリシーの編集]** を選択してください。
1. 信頼関係に以下のポリシーが含まれていることを確認します。信頼関係が以下のポリシーと一致する場合、**[キャンセル]** を選択してください。信頼関係が一致しない場合、ポリシーを **[信頼ポリシーの編集]** ウィンドウにコピーし、**[ポリシーの更新]** を選択します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
## Amazon EKS コネクタエージェントロールの作成
コネクタエージェントロールを作成するには、AWS マネジメントコンソール または AWS CloudFormation を使用できます。
AWS CLI
1. IAM ロールに使用する次の JSON が含まれる `eks-connector-agent-trust-policy.json` という名前のファイルを作成します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"ssm.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
1. IAM ロールに使用する次の JSON が含まれる `eks-connector-agent-policy.json` という名前のファイルを作成します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SsmControlChannel",
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel"
],
"Resource": "arn:aws:eks:*:*:cluster/*"
},
{
"Sid": "ssmDataplaneOperations",
"Effect": "Allow",
"Action": [
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenDataChannel",
"ssmmessages:OpenControlChannel"
],
"Resource": "*"
}
]
}
```
1. 前のリストアイテムで作成した信頼ポリシーとポリシーを使用して、Amazon EKS Connector エージェントロールを作成します。
```
aws iam create-role \
--role-name AmazonEKSConnectorAgentRole \
--assume-role-policy-document file://eks-connector-agent-trust-policy.json
```
1. Amazon EKS Connector エージェントのロールにポリシーを添付します。
```
aws iam put-role-policy \
--role-name AmazonEKSConnectorAgentRole \
--policy-name AmazonEKSConnectorAgentPolicy \
--policy-document file://eks-connector-agent-policy.json
```
AWS CloudFormation
1. 以下の AWS CloudFormation テンプレートを、テキストファイルとしてローカルシステムに保存します。
**注記**
このテンプレートでは、ここで作成されなければ `registerCluster` API が呼び出されたときに作成される、サービスにリンクされたロールも作成されます。詳細については、「[ロールを使用して Kubernetes クラスターを Amazon EKS に接続する](using-service-linked-roles-eks-connector.md)」を参照してください。
```
---
AWSTemplateFormatVersion: '2010-09-09'
Description: 'Provisions necessary resources needed to register clusters in EKS'
Parameters: {}
Resources:
EKSConnectorSLR:
Type: AWS::IAM::ServiceLinkedRole
Properties:
AWSServiceName: eks-connector.amazonaws.com
EKSConnectorAgentRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action: [ 'sts:AssumeRole' ]
Principal:
Service: 'ssm.amazonaws.com'
EKSConnectorAgentPolicy:
Type: AWS::IAM::Policy
Properties:
PolicyName: EKSConnectorAgentPolicy
Roles:
- {Ref: 'EKSConnectorAgentRole'}
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: 'Allow'
Action: [ 'ssmmessages:CreateControlChannel' ]
Resource:
- Fn::Sub: 'arn:${AWS::Partition}:eks:*:*:cluster/*'
- Effect: 'Allow'
Action: [ 'ssmmessages:CreateDataChannel', 'ssmmessages:OpenDataChannel', 'ssmmessages:OpenControlChannel' ]
Resource: "*"
Outputs:
EKSConnectorAgentRoleArn:
Description: The agent role that EKS connector uses to communicate with AWS services.
Value: !GetAtt EKSConnectorAgentRole.Arn
```
1. [AWS CloudFormation コンソール](https://console.aws.amazon.com/cloudformation/)を開きます。
1. 新しいリソースを使用して **[スタックを作成]** を選択します (標準)。
1. [**テンプレートの指定**] で、[**テンプレートファイルのアップロード**] を選択し、[**ファイルの選択**] を選択します。
1. 作成したファイルを選択し、[**Next (次へ)**] を選択します。
1. [**スタックの名前**] に `eksConnectorAgentRole` などのロール名を入力し、[**次へ**] を選択します。
1. [**スタックオプションの設定**] ページで、[**Next (次へ)**] を選択します。
1. [**Review (レビュー)**] ページの情報から、スタックにより IAM リソースが作成されることを確認し、[**Create stack (スタックの作成)**] を選択します。
# Amazon Elastic Kubernetes Service に関する AWS 管理ポリシー
AWS マネージドポリシーはAWS が作成および管理するスタンドアロンポリシーです。AWS マネージドポリシーは多くの一般的なユースケースに対してアクセス許可を提供するように設計されているため、ユーザー、グループ、役割へのアクセス権の割り当てを開始できます。
AWS マネージドポリシーは特定のユースケースに対して最小特権の許可を付与しない場合があることに注意してください。これはすべての AWS 顧客が使用できる状態になっているためです。ユースケースに固有の[カスタマー管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)を定義して、アクセス許可を絞り込むことをお勧めします。
AWS マネージドポリシーで定義したアクセス権限は変更できません。AWS が AWS マネージドポリシーに定義されているアクセス許可を更新すると、更新はポリシーがアタッチされているすべてのプリンシパルアイデンティティ (ユーザー、グループ、役割) に影響します。新しい AWS サービスを起動するか、既存のサービスで新しい API オペレーションが使用可能になると、AWS が AWS マネージドポリシーを更新する可能性が最も高くなります。
詳細については「*IAM ユーザーガイド*」の「[AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。
## AWS 管理ポリシー: AmazonEKS\$1CNI\$1Policy
`AmazonEKS_CNI_Policy` ポリシーを IAM エンティティにアタッチできます。Amazon EC2 ノードグループを作成する前に、このポリシーを[ノードの IAM ロール](create-node-role.md)、または Amazon VPC CNI Plugin for Kubernetes 専用で使用する IAM ロールにアタッチする必要があります。これはユーザーに代わってアクションを実行できるようにするためです。プラグインでのみ使用される役割にポリシーをアタッチすることをお勧めします。詳細については[Amazon VPC CNI を使用して Pod に IP を割り当てる](managing-vpc-cni.md)および[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)を参照してください。
**許可の詳細**
このポリシーには Amazon EKS に以下のタスクを完了させるための以下の権限が含まれています。
+ **`ec2:*NetworkInterface` および `ec2:*PrivateIpAddresses`** - Amazon VPC CNI プラグインが Pod の Elastic Network Interface や IP アドレスのプロビジョニングなどのアクションを実行し、Amazon EKS で実行されるアプリケーションにネットワークを提供できるようにします。
+ **`ec2` 読み取りアクション** - Amazon VPC CNI プラグインがインスタンスやサブネットを記述して、Amazon VPC サブネット内の空き IP アドレスの量を確認するなどのアクションを実行できるようにします。VPC CNI は各サブネットの空き IP アドレスを使用して、エラスティック・ネットワーク・インターフェイス の作成時に使用する空き IP アドレスが最も多いサブネットを選択できます。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html#AmazonEKS_CNI_Policy-json)」を参照してください。
## AWS 管理ポリシー: AmazonEKSClusterPolicy
IAM エンティティに `AmazonEKSClusterPolicy` をアタッチできます。クラスターを作成する前に、このポリシーをアタッチした[クラスター IAM ロール](cluster-iam-role.md)が必要となります。Amazon EKS によって管理される Kubernetes クラスターは、ユーザーに代わって他の AWS のサービスを呼び出します。これにより、サービスで使用するリソースを管理します。
このポリシーにはアマゾン EKS に以下のタスクを完了させるための以下の権限が含まれています。
+ **`autoscaling`** – 自動スケーリング グループの設定を読み取り、更新します。これらの権限は Amazon EKS では使用されませんが、下位互換性のためにポリシーに残ります。
+ **`ec2`** – Amazon EC2 ノードに関連付けられているボリュームとネットワークリソースを操作します。これは、Kubernetes コントロールプレーンがインスタンスをクラスターに結合し、Kubernetes 永続ボリュームによってリクエストされる Amazon EBS ボリュームを動的にプロビジョニングおよび管理できるようにするために必要です。
+ ** `ec2` ** - VPC CNI によって作成された Elastic Network Interface を削除します。こうした権限付与が必要なのは、VPC CNI が予期せず終了した場合に、残った Elastic Network Interface を EKS によってクリーンアップするためです。
+ ** `elasticloadbalancing` ** – Elastic Load Balancers を操作し、ノードをターゲットとして追加します。これは、Kubernetes コントロールプレーンが Kubernetes サービスによってリクエストされる Elastic Load Balancer を動的にプロビジョニングできるようにするために必要です。
+ ** `iam` ** - サービスにリンクされた役割を作成します。これは、Kubernetes コントロールプレーンが Kubernetes サービスによってリクエストされる Elastic Load Balancer を動的にプロビジョニングできるようにするために必要です。
+ **`kms`** – AWS KMS からキーを読み取ります。これは、Kubernetes コントロールプレーンが `etcd` に保存される Kubernetes シークレットの[シークレット暗号化](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)を管理するために必要です。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json)」を参照してください。
## AWS マネージドポリシー: AmazonEKSDashboardConsoleReadOnly
IAM エンティティに `AmazonEKSDashboardConsoleReadOnly` をアタッチできます。
このポリシーにはアマゾン EKS に以下のタスクを完了させるための以下の権限が含まれています。
+ ** `eks` ** – EKS ダッシュボードのデータ、リソース、クラスターバージョン情報への読み取り専用アクセス。これにより、EKS 関連のメトリクスおよびクラスター設定の詳細を表示できます。
+ ** `organizations` ** – 以下のような AWS Organizations 情報への読み取り専用アクセス。
+ 組織の詳細とサービスアクセスの表示
+ 組織のルート、アカウント、組織単位の一覧表示
+ 組織構造の表示
JSON ポリシードキュメントの最新バージョンを確認するには、「AWS マネージドポリシーのリファレンスガイド」の「[AmazonEKSDashboardConsoleReadOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardConsoleReadOnly.html#AmazonEKSDashboardConsoleReadOnly-json)」を参照してください。
## AWS 管理ポリシー: AmazonEKSFargatePodExecutionRolePolicy
IAM エンティティに `AmazonEKSFargatePodExecutionRolePolicy` をアタッチできます。Fargate プロファイルを作成する前に、Fargate Pod 実行ロールを作成し、このポリシーをアタッチする必要があります。詳細については、「[ステップ 2: Fargate Pod 実行ロールを作成する](fargate-getting-started.md#fargate-sg-pod-execution-role)」および「[起動時にどの Pod が AWS Fargate を使用するのかを定義する](fargate-profile.md)」を参照してください。
このポリシーはロールに対して、Fargate で Amazon EKS Pod を実行するために必要な他の AWS サービスリソースにアクセスするための権限を付与します。
**許可の詳細**
このポリシーにはアマゾン EKS に以下のタスクを完了させるための以下の権限が含まれています。
+ ** `ecr` ** – Fargate で実行中のポッドが、Amazon ECR に格納されているコンテナイメージを取得できるようにします。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKSFargatePodExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSFargatePodExecutionRolePolicy.html#AmazonEKSFargatePodExecutionRolePolicy-json)」を参照してください。
## AWS マネージドポリシー: AmazonEKSConnectorServiceRolePolicy
IAM エンティティに `AmazonEKSConnectorServiceRolePolicy` をアタッチすることはできません。このポリシーはユーザーに代わって アマゾン EKS がアクションを実行することを許可する、サービスにリンクされた役割にアタッチされます。詳細については、「[ロールを使用して Kubernetes クラスターを Amazon EKS に接続する](using-service-linked-roles-eks-connector.md)」を参照してください。
このロールにより、Amazon EKS は Kubernetes クラスターに接続できます。アタッチされたポリシーにより、ロールは、登録された Kubernetes クラスターに接続するために必要なリソースを管理できます。
**アクセス許可の詳細**
このポリシーにはアマゾン EKS が以下のタスクを完了できるようにする以下の権限が含まれています。
+ ** `SSM Management` ** – SSM アクティベーションを作成、説明、削除し、マネージドインスタンスの登録を解除します。これにより、基本的な Systems Manager オペレーションが可能になります。
+ ** `Session Management` ** – EKS クラスター専用の SSM セッションを開始し、AmazonEKS ドキュメントを使用して非インタラクティブコマンドを実行します。
+ ** `IAM Role Passing` ** – SSM サービスに対して特定の IAM ロールを渡します。この操作は、渡されるロールを `ssm.amazonaws.com` に制限する条件によって制御されます。
+ ** `EventBridge Rules` ** – EventBridge ルールとターゲットを作成します。ただし、`eks-connector.amazonaws.com` によって管理される場合にのみ許可されます。ルールは、イベントソースとして AWS SSM のみに制限されます。
JSON ポリシードキュメントの最新バージョンを確認するには「AWS 管理ポリシーリファレンスガイド」の「[AmazonEKSConnectorServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSConnectorServiceRolePolicy.html)」を参照してください。
## AWS 管理ポリシー: AmazonEKSForFargateServiceRolePolicy
IAM エンティティに `AmazonEKSForFargateServiceRolePolicy` をアタッチすることはできません。このポリシーはユーザーに代わって アマゾン EKS がアクションを実行することを許可する、サービスにリンクされた役割にアタッチされます。詳細については「`AWSServiceRoleforAmazonEKSForFargate`」を参照してください。
このポリシーは Fargate タスクを実行するために必要なアクセス権限を Amazon EKS に付与します。このポリシーはFargate ノードがある場合にのみ使用されます。
**アクセス許可の詳細**
このポリシーにはアマゾン EKS が以下のタスクを完了できるようにする以下の権限が含まれています。
+ ** `ec2` ** – Elastic Network Interfaces を作成および削除し、Elastic Network Interfaces とリソースについて説明します。これは Amazon EKS Fargate サービスが Fargate ポッドに必要な VPC ネットワーキングを設定できるようにするために必要です。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKSForFargateServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSForFargateServiceRolePolicy.html#AmazonEKSForFargateServiceRolePolicy-json)」を参照してください。
## AWS マネージドポリシー: AmazonEKSComputePolicy
IAM エンティティに `AmazonEKSComputePolicy` をアタッチできます。このポリシーを[クラスター IAM 役割](cluster-iam-role.md)にアタッチして、EKS がアカウントで管理できるリソースを拡張できます。
このポリシーによって Amazon EKS が EKS クラスター用の EC2 インスタンスを作成および管理するために必要なアクセス許可と、EC2 を設定するために必要な IAM アクセス許可が付与されます。さらに、このポリシーによって、Amazon EKS がユーザーに代わって EC2 スポットサービスにリンクされたロールを作成するためのアクセス許可が付与されます。
### 許可の詳細
このポリシーにはアマゾン EKS に以下のタスクを完了させるための以下の権限が含まれています。
+ ** `ec2` 許可**:
+ `ec2:CreateFleet` および `ec2:RunInstances` - EC2 インスタンスの作成と、EKS クラスターノードのための特定の EC2 リソース (イメージ、セキュリティグループ、サブネット) の使用を許可します。
+ `ec2:CreateLaunchTemplate` - EKS クラスターノードのための EC2 起動テンプレートの作成を許可します。
+ また、このポリシーにはこれらの EC2 許可の使用を、EKS クラスター名および他の関連タグでタグ付けされたリソースに制限する条件も含まれています。
+ `ec2:CreateTags` - `CreateFleet`、`RunInstances`、および `CreateLaunchTemplate` アクションによって作成された EC2 リソースへのタグの追加を許可します。
+ ** `iam` 許可**:
+ `iam:AddRoleToInstanceProfile` - EKS コンピューティングインスタンスプロファイルへの IAM 役割の追加を許可します。
+ `iam:PassRole` - 必要な IAM 役割を EC2 サービスに渡すことを許可します。
JSON ポリシードキュメントの最新バージョンを確認するには「AWS マネージドポリシーリファレンスガイド」の「[AmazonEKSComputePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSComputePolicy.html#AmazonEKSComputePolicy-json)」を参照してください。
## AWS 管理ポリシー: AmazonEKSNetworkingPolicy
IAM エンティティに `AmazonEKSNetworkingPolicy` をアタッチできます。このポリシーを[クラスター IAM 役割](cluster-iam-role.md)にアタッチして、EKS がアカウントで管理できるリソースを拡張できます。
このポリシーは Amazon EKS が EKS クラスターのネットワークインターフェイスを作成および管理するために必要なアクセス許可を付与し、コントロールプレーンとワーカーノードが適切に通信および機能するように設計されています。
### アクセス許可の詳細
このポリシーは Amazon EKS がクラスターのネットワークインターフェイスを管理できるようにする以下のアクセス許可を付与します。
+ **`ec2` ネットワークインターフェイスアクセス許可**:
+ `ec2:CreateNetworkInterface` - EC2 ネットワークインターフェイスの作成を許可します。
+ このポリシーにはこのアクセス許可の使用を EKS クラスター名と Kubernetes CNI ノード名でタグ付けされたネットワークインターフェイスに制限するための条件が含まれています。
+ `ec2:CreateTags` - `CreateNetworkInterface` アクションによって作成されたネットワークインターフェイスへのタグの追加を許可します。
+ **`ec2` ネットワークインターフェイス管理のアクセス許可**:
+ `ec2:AttachNetworkInterface`、`ec2:ModifyNetworkInterfaceAttribute`、`ec2:DetachNetworkInterface` - EC2 インスタンスへのネットワークインターフェイス属性のアタッチ、変更、およびネットワークインターフェイスのデタッチを許可します。
+ `ec2:UnassignPrivateIpAddresses`、`ec2:UnassignIpv6Addresses`、`ec2:AssignPrivateIpAddresses`、`ec2:AssignIpv6Addresses` - ネットワークインターフェイスの IP アドレス割り当ての管理を許可します。
+ これらのアクセス許可はEKS クラスター名でタグ付けされたネットワークインターフェイスに制限されます。
JSON ポリシードキュメントの最新バージョンを確認するにはAWS マネージドポリシーリファレンスガイドの「[AmazonEKSNetworkingPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSNetworkingPolicy.html#AmazonEKSNetworkingPolicy-json)」を参照してください。
## AWS マネージドポリシー: AmazonEKSBlockStoragePolicy
IAM エンティティに `AmazonEKSBlockStoragePolicy` をアタッチできます。このポリシーを[クラスター IAM 役割](cluster-iam-role.md)にアタッチして、EKS がアカウントで管理できるリソースを拡張できます。
このポリシーは Amazon EKS が EKS クラスターのために EC2 ボリュームとスナップショットを作成、管理、メンテナンスするために必要な許可を付与し、Kubernetes ワークロードが必要とする永続的ストレージをコントロールプレーンとワーカーノードがプロビジョニングおよび使用できるようにします。
### アクセス許可の詳細
この IAM ポリシーは Amazon EKS が EC2 ボリュームとスナップショットを管理できるように、次の許可を付与します:
+ **`ec2` ボリューム管理の許可**:
+ `ec2:AttachVolume`、`ec2:DetachVolume`、`ec2:ModifyVolume`、`ec2:EnableFastSnapshotRestores` - EC2 ボリュームの高速スナップショット復元のアタッチ、デタッチ、変更、有効化を許可します。
+ これらの許可はEKS クラスター名でタグ付けされたボリュームに制限されます。
+ `ec2:CreateTags` - `CreateVolume` および `CreateSnapshot` アクションによって作成された EC2 ボリュームとスナップショットへのタグの追加を許可します。
+ **`ec2` ボリューム作成の許可**:
+ `ec2:CreateVolume` - 新しい EC2 ボリュームの作成を許可します。
+ このポリシーにはこの許可の使用を、EKS クラスター名および他の関連タグでタグ付けされたボリュームに制限する条件が含まれています。
+ `ec2:CreateSnapshot` - 新しい EC2 ボリュームスナップショットの作成を許可します。
+ このポリシーにはこの許可の使用を、EKS クラスター名および他の関連タグでタグ付けされたスナップショットに制限する条件が含まれています。
JSON ポリシードキュメントの最新バージョンを確認するには「AWS マネージドポリシーリファレンスガイド」の「[AmazonEKSBlockStoragePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSBlockStoragePolicy.html#AmazonEKSBlockStoragePolicy-json)」を参照してください。
## AWS マネージドポリシー: AmazonEKSLoadBalancingPolicy
IAM エンティティに `AmazonEKSLoadBalancingPolicy` をアタッチできます。このポリシーを[クラスター IAM 役割](cluster-iam-role.md)にアタッチして、EKS がアカウントで管理できるリソースを拡張できます。
この IAM ポリシーは Amazon EKS が Elastic ロードバランサー (ELB) および関連リソースを管理するためにさまざまな AWS サービスと連携するために必要な許可を付与します。
### アクセス許可の詳細
このポリシーによって付与される主な許可は次のとおりです:
+ ** `elasticloadbalancing` **: Elastic Load Balancers とターゲットグループの作成、変更、管理を許可します。これにはロードバランサー、ターゲットグループ、リスナー、ルールを作成、更新、削除するための許可が含まれます。
+ ** `ec2` **: Kubernetes コントロールプレーンがインスタンスをクラスターに参加させ、Amazon EBS ボリュームを管理するために必要なセキュリティグループの作成と管理を許可します。また、インスタンス、VPC、サブネット、セキュリティ グループ、その他のネットワーク リソースなどの EC2 リソースを記述および一覧表示することもできます。
+ ** `iam` **: Kubernetes コントロールプレーンが ELB を動的にプロビジョニングするために必要な、Elastic Load Balancing 用のサービスにリンクされた役割の作成を許可します。
+ **`kms`**: etcd に保存されている Kubernetes シークレットの暗号化をサポートするために Kubernetes コントロールプレーンが必要とする AWS KMS からのキーの読み取りを許可します。
+ **`wafv2`** および **`shield`**: ウェブ ACL 関連付けと関連付け解除、および Elastic ロードバランサー のための AWS Shield 保護の作成/削除を許可します。
+ **`cognito-idp`**、**`acm`**、および **`elasticloadbalancing`**: ユーザープールクライアントの記述、証明書の一覧表示および記述、ならびにターゲットグループの記述を実行するための許可を付与します。これはKubernetes コントロールプレーンが Elastic ロードバランサー を管理するために必要です。
また、このポリシーには`eks:eks-cluster-name` タグを使用して、許可の範囲が管理対象の特定の EKS クラスターに設定されているようにするための条件チェックもいくつか含まれています。
JSON ポリシードキュメントの最新バージョンを確認するには「AWS マネージドポリシーリファレンスガイド」の「[AmazonEKSLoadBalancingPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLoadBalancingPolicy.html#AmazonEKSLoadBalancingPolicy-json)」を参照してください。
## AWS マネージドポリシー: AmazonEKSMCPReadOnlyAccess
IAM エンティティに `AmazonEKSMCPReadOnlyAccess` をアタッチできます。このポリシーは、Amazon EKS リソースおよび関連する AWS サービスへの読み取り専用アクセスを提供し、Amazon EKS モデルコンテキストプロトコル (MCP) サーバーがインフラストラクチャを変更することなくオブザーバビリティおよびトラブルシューティングのオペレーションを実行できるようにします。
**アクセス許可の詳細**
このポリシーには、プリンシパルに以下のタスクを完了させるための以下の権限が含まれています。
+ ** `eks` ** プリンシパルが EKS クラスター、ノードグループ、アドオン、アクセスエントリ、インサイトを記述および一覧表示し、読み取り専用オペレーションのために Kubernetes API にアクセスできるようにします。
+ ** `iam` ** プリンシパルが IAM ロール、ポリシー、およびその添付ファイルに関する情報を取得して、EKS リソースに関連付けられたアクセス許可を理解できるようにします。
+ ** `ec2` ** プリンシパルが VPC、サブネット、ルートテーブルを記述して、EKS クラスターのネットワーク設定を理解できるようにします。
+ ** `sts` ** プリンシパルが認証および認可の目的で発信者 ID 情報を取得できるようにします。
+ ** `logs` ** プリンシパルが、トラブルシューティングとモニタリングのために、CloudWatch Logs でクエリを開始し、クエリ結果を取得できるようにします。
+ ** `cloudwatch` ** プリンシパルがクラスターとワークロードのパフォーマンスをモニタリングするためのメトリクスデータを取得できるようにします。
+ ** `eks-mcp` ** プリンシパルが MCP オペレーションを呼び出し、Amazon EKS MCP サーバー内で読み取り専用ツールを呼び出せるようにします。
JSON ポリシードキュメントの最新バージョンを確認するには、「AWS マネージドポリシーのリファレンスガイド」の「[AmazonEKSMCPReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSMCPReadOnlyAccess.html)」を参照してください。
## AWS 管理ポリシー: AmazonEKSServicePolicy
IAM エンティティに `AmazonEKSServicePolicy` をアタッチできます。2020 年 4 月 16 日より前に作成されたクラスターではIAM 役割を作成し、このポリシーをアタッチする必要がありました。2020 年 4 月 16 日以降に作成されたクラスターでは役割を作成する必要はなく、このポリシーの割り当ても必要ありません。IAM プリンシパルを使用してクラスターを作成する場合、`iam:CreateServiceLinkedRole` 権限がある場合、[AWSServiceRoleforAmazonEKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) のサービスにリンクされた役割が自動的に作成されます。このサービスにリンクされた役割には[管理ポリシー: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) がアタッチされています。
このポリシーにより、Amazon EKS は Amazon EKS クラスターを操作するために必要なリソースを作成および管理できるようになります。
**アクセス許可の詳細**
このポリシーには、Amazon EKS が以下のタスクを完了できるようにする以下の権限が含まれています。
+ ** `eks` ** – 更新を開始した後、クラスターの Kubernetes バージョンを更新します。この権限は Amazon EKS では使用されませんが、下位互換性のためにポリシーに残ります。
+ ** `ec2` ** – Elastic Network Interfaces およびその他のネットワークリソースとタグを操作します。これは、ノードと Kubernetes コントロールプレーン間の通信を容易にするネットワーキングを設定するために、Amazon EKS で必要です。セキュリティグループに関する情報を確認します。セキュリティグループのタグを更新します。
+ ** `route53` ** – VPC をホストゾーンに関連付けます。これは、Kubernetes クラスター API サーバーのプライベートエンドポイントネットワーキングを有効にするために、Amazon EKS で必要です。
+ ** `logs` ** – ログイベント これは、Amazon EKS が Kubernetes コントロールプレーンログを CloudWatch に送信できるようにするために必要です。
+ ** `iam` ** - サービスにリンクされた役割を作成します。これは Amazon EKS がユーザーに代わって [アマゾン EKS でのサービスにリンクされた役割のアクセス許可](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) のサービスにリンクされた役割を作成するために必要です。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html#AmazonEKSServicePolicy-json)」を参照してください。
## AWS 管理ポリシー: AmazonEKSServiceRolePolicy
IAM エンティティに `AmazonEKSServiceRolePolicy` をアタッチすることはできません。このポリシーはユーザーに代わって アマゾン EKS がアクションを実行することを許可する、サービスにリンクされた役割にアタッチされます。詳細については「[アマゾン EKS でのサービスにリンクされた役割のアクセス許可](using-service-linked-roles-eks.md#service-linked-role-permissions-eks)」を参照してください。`iam:CreateServiceLinkedRole` 権限のある IAM プリンシパルを使用してクラスターを作成する場合、[AWSServiceRoleforAmazonEKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) のサービスにリンクされた役割が自動的に作成され、このポリシーがアタッチされます。
このポリシーにより、サービスにリンクされた役割はユーザーに代わって AWS サービスを呼び出します。
**アクセス許可の詳細**
このポリシーにはアマゾン EKS が以下のタスクを完了できるようにする以下の権限が含まれています。
+ ** `ec2` ** – Elastic Network Interface と Amazon EC2 インスタンス、クラスターセキュリティグループ、およびクラスターの作成に必要な VPC を作成、記述します。詳細については「[クラスターの Amazon EKS セキュリティグループ要件を表示する](sec-group-reqs.md)」を参照してください。セキュリティグループに関する情報を確認します。セキュリティグループのタグを更新します。「オンデマンドキャパシティ予約」に関する情報を参照してください。クラスターインサイトの一部として設定の問題を検出するために、ルートテーブルやネットワーク ACL を含む VPC 設定を読み取ります。
+ ** `ec2` Auto Mode** - EKS Auto Mode によって作成された EC2 インスタンスを終了します。詳細については、「[EKS Auto Mode を使用してクラスターインフラストラクチャを自動化する](automode.md)」を参照してください。
+ ** `iam` ** – IAM 役割にアタッチされているすべての管理ポリシーを一覧表示します。これは、Amazon EKS がクラスターの作成に必要なすべての管理ポリシーと権限を一覧表示および検証できるようにするために必要です。
+ **VPC をホストゾーンに関連付ける** – これは、Kubernetes クラスターの API サーバーのプライベートエンドポイントネットワーキングを有効にするために、Amazon EKS で必要です。
+ **ログイベント** – これは、Amazon EKS が Kubernetes コントロールプレーンログを CloudWatch に送信できるようにするために必要です。
+ **Put メトリクス** – これは Amazon EKS が Kubernetes コントロールプレーンログを CloudWatch に送信できるようにするために必要です。
+ ** `eks` ** - クラスターアクセスエントリとポリシーを管理し、EKS リソースにアクセスできるユーザーと、それらのユーザーが実行できるアクションをきめ細かく制御できるようにします。これにはコンピューティング、ネットワーキング、ロードバランシング、ストレージオペレーションのために標準アクセスポリシーを関連付けることが含まれます。
+ ** `elasticloadbalancing` ** - EKS クラスターに関連付けられているロードバランサーとそのコンポーネント (リスナー、ターゲットグループ、証明書) を作成、管理、削除します。ロードバランサーの属性とヘルスステータスを表示します。
+ **`events`** - EKS クラスターに関連する EC2 イベントと AWS ヘルスイベントをモニタリングするための EventBridge ルールを作成および管理し、インフラストラクチャの変更とヘルスアラートへの自動応答を可能にします。
+ ** `iam` ** - EKS ノードの管理に必要な作成、削除、役割の関連付けなど、「eks」プレフィックスを使用して EC2 インスタンスプロファイルを管理します。ユーザーがそれぞれのワーカーノードのカスタムインスタンスプロファイルを定義できるように、インスタンスプロファイルの記述を許可します。
+ ** `pricing` ** ** `shield` ** - AWS の料金情報と Shield 保護ステータスにアクセスし、EKS リソースのコスト管理と高度なセキュリティ機能を可能にします。
+ **リソースのクリーンアップ** - クラスターのクリーンアップオペレーション中に、ボリューム、スナップショット、起動テンプレート、ネットワークインターフェイスなどの EKS タグ付きリソースを安全に削除します。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServiceRolePolicy.html#AmazonEKSServiceRolePolicy-json)」を参照してください。
## AWS 管理ポリシー: AmazonEKSVPCResourceController
`AmazonEKSVPCResourceController` ポリシーを IAM アイデンティティにアタッチできます。[ポッドのセキュリティグループ](security-groups-for-pods.md)を使用している場合はユーザーに代わってアクションを実行させるために、このポリシーを [Amazon EKS クラスターの IAM 役割](cluster-iam-role.md)にアタッチする必要があります。
このポリシーはノードの エラスティック・ネットワーク・インターフェイス と IP アドレスを管理するアクセス権限をクラスター役割に付与します。
**許可の詳細**
このポリシーには、Amazon EKS に以下のタスクを完了させるための以下の権限が含まれています。
+ ** `ec2` ** – Elastic Network Interface と IP アドレスを管理し、Pod のセキュリティグループと Windows ノードをサポートします。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKSVPCResourceController](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html#AmazonEKSVPCResourceController-json)」を参照してください。
## AWS 管理ポリシー: AmazonEKSWorkerNodePolicy
`AmazonEKSWorkerNodePolicy` ポリシーを IAM エンティティにアタッチできます。このポリシーを、Amazon EKS がユーザーに代わってアクションを実行することを許可する Amazon EC2 ノードを作成するときに指定する[ノード IAM 役割](create-node-role.md)にアタッチしなければなりません。`eksctl` を使用してノードグループを作成すると、ノード IAM 役割が作成され、このポリシーを役割に自動的にアタッチします。
このポリシーはアマゾン EKS アマゾン EC2 ノードに アマゾン EKS クラスターに接続するためのアクセス権限を付与します。
**許可の詳細**
このポリシーにはアマゾン EKS に以下のタスクを完了させるための以下の権限が含まれています。
+ ** `ec2` ** – インスタンスボリュームとネットワーク情報を読み取ります。これは、Kubernetes ノードが Amazon EKS クラスターに参加するのに必要な Amazon EC2 リソースに関する情報を記述できるようにするために必要です。
+ ** `eks` ** – オプションで、ノードのブートストラップの一部としてクラスターを記述します。
+ ** `eks-auth:AssumeRoleForPodIdentity` ** – ノード上の EKS ワークロードの認証情報を取得できるようにします。これはEKS Pod Identity が正しく機能するために必要です。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[アマゾンEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html#AmazonEKSWorkerNodePolicy-json) Policy」を参照してください。
## AWS マネージドポリシー: AmazonEKSWorkerNodeMinimalPolicy
IAM エンティティに AmazonEKSWorkerNodeMinimalPolicy をアタッチできます。このポリシーを、Amazon EKS がユーザーに代わってアクションを実行することを許可する Amazon EC2 ノードを作成するときに指定するノード IAM 役割にアタッチすることができます。
このポリシーはアマゾン EKS アマゾン EC2 ノードに アマゾン EKS クラスターに接続するためのアクセス権限を付与します。このポリシーのアクセス許可は AmazonEKSWorkerNodePolicy に比べて少なくなります。
**許可の詳細**
このポリシーにはアマゾン EKS に以下のタスクを完了させるための以下の権限が含まれています。
+ `eks-auth:AssumeRoleForPodIdentity` – ノード上の EKS ワークロードの認証情報を取得できるようにします。これはEKS Pod Identity が正しく機能するために必要です。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[アマゾンEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodeMinimalPolicy.html#AmazonEKSWorkerNodeMinimalPolicy-json) Policy」を参照してください。
## AWS 管理ポリシー: AWSServiceRoleForAmazonEKSNodegroup
IAM エンティティに `AWSServiceRoleForAmazonEKSNodegroup` をアタッチすることはできません。このポリシーはユーザーに代わって アマゾン EKS がアクションを実行することを許可する、サービスにリンクされた役割にアタッチされます。詳細については「[アマゾン EKS でのサービスにリンクされた役割のアクセス許可](using-service-linked-roles-eks-nodegroups.md#service-linked-role-permissions-eks-nodegroups)」を参照してください。
このポリシーは `AWSServiceRoleForAmazonEKSNodegroup` 役割権限を付与し、アカウント内の Amazon EC2 ノードグループを作成および管理できるようにします。
**許可の詳細**
このポリシーにはアマゾン EKS に以下のタスクを完了させるための以下の権限が含まれています。
+ ** `ec2` ** – セキュリティグループ、タグ、キャパシティ予約、および起動テンプレートを操作します。これは Amazon EKS マネージド型ノードグループがリモートアクセス設定を有効にし、マネージド型ノードグループで使用できるキャパシティ予約を記述するために必要です。さらに、Amazon EKS マネージド型ノードグループはユーザーに代わって起動テンプレートを作成します。これは各マネージド型ノードグループをバックアップする Amazon EC2 Auto Scaling グループを設定するためです。
+ ** `iam` ** – サービスにリンクされた役割を作成し、役割を渡します。これは Amazon EKS マネージド型ノードグループが、マネージドノードグループの作成時に渡される役割のインスタンスプロファイルを管理するために必要です。このインスタンスプロファイルはマネージド型ノードグループの一部として起動される Amazon EC2 インスタンスによって使用されます。Amazon EKS は Amazon EC2 Auto Scaling グループなどの他のサービスに対してサービスリンクされた役割を作成する必要があります。これらの権限はマネージド型ノードグループの作成に使用されます。
+ ** `autoscaling` **–セキュリティの Auto Scaling グループを使用します。これはAmazon EKS マネージド型ノードグループが、各マネージドノードグループをバックアップする Amazon EC2 Auto Scaling グループを管理するために必要です。また、ノードグループの更新中にノードが終了またはリサイクルされた場合のポッドのエビクションや、マネージド型ノードグループで構成されたウォームプールの管理などの機能のサポートにも使用されます。
JSON ポリシードキュメントの最新バージョンを確認するには「AWS マネージドポリシーリファレンスガイド」の「[AWSServiceRoleForAmazonEKSNodegroup](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSServiceRoleForAmazonEKSNodegroup.html#AWSServiceRoleForAmazonEKSNodegroup-json)」を参照してください。
## AWS マネージドポリシー: AmazonEKSDashboardServiceRolePolicy
IAM エンティティに `AmazonEKSDashboardServiceRolePolicy` をアタッチすることはできません。このポリシーはユーザーに代わって アマゾン EKS がアクションを実行することを許可する、サービスにリンクされた役割にアタッチされます。詳細については、「[Amazon EKS でのサービスにリンクされた役割のアクセス許可](using-service-linked-roles-eks-dashboard.md#service-linked-role-permissions-eks-dashboard)」を参照してください。
このポリシーは `AWSServiceRoleForAmazonEKSDashboard` 役割権限を付与し、アカウント内の Amazon EC2 ノードグループを作成および管理できるようにします。
**アクセス許可の詳細**
このポリシーには、以下のタスクを完了させるためにアクセスできる次の権限が含まれています。
+ ** `organizations` ** – AWS Organizations の構造とアカウントに関する情報を表示します。これには、組織内のアカウントを一覧表示する、組織単位とルートを表示する、委任された管理者を一覧表示する、組織にアクセスできるサービスを表示する、および組織とアカウントに関する詳細情報を取得する権限が含まれます。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKSDashboardServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSDashboardServiceRolePolicy.html#AmazonEKSDashboardServiceRolePolicy-json)」を参照してください。
## AWS 管理ポリシー: AmazonEBSCSIDriverPolicy
`AmazonEBSCSIDriverPolicy` ポリシーは Amazon EBS コンテナ・ストレージ・インターフェース (CSI) ドライバーが、ユーザーに代わってボリュームを作成、変更、コピー、アタッチ、デタッチ、削除できるようにします。これには既存のボリュームのタグの変更や、EBS ボリュームでの高速スナップショット復元 (FSR) の有効化が含まれます。また、EBS CSI ドライバーに、スナップショットを作成、ロック、復元、削除したり、インスタンス、ボリューム、スナップショットを一覧表示する権限も付与します。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEBSCSIDriverServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEBSCSIDriverPolicy.html#AmazonEBSCSIDriverPolicy-json)」を参照してください。
## AWS マネージドポリシー: AmazonEFSCSIDriverPolicy
`AmazonEFSCSIDriverPolicy` ポリシーでは Amazon EFS コンテナストレージインターフェイス (CSI) がユーザーに代わってアクセスポイントを作成および削除できるようにすることができます。また、Amazon EFS CSI ドライバーに、アクセスポイント、ファイルシステム、マウントターゲット、Amazon EC2 アベイラビリティゾーンを一覧表示するアクセス許可を付与することもできます。
JSON ポリシードキュメントの最新バージョンを確認するにはAWS マネージドポリシーリファレンスガイドの「[AmazonEFSCSIDriverServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEFSCSIDriverPolicy.html#AmazonEFSCSIDriverPolicy-json)」を参照してください。
## AWS マネージドポリシー: AmazonEKSLocalOutpostClusterPolicy
このポリシーを IAM エンティティにアタッチできます。ローカルクラスターを作成する前に、このポリシーを[クラスターロール](cluster-iam-role.md)にアタッチする必要があります。Amazon EKS によって管理される Kubernetes クラスターは、ユーザーに代わって他の AWS のサービスを呼び出します。これにより、サービスで使用するリソースを管理します。
`AmazonEKSLocalOutpostClusterPolicy` には以下の権限が含まれています。
+ **`ec2` 読み取りアクション** – コントロールプレーンインスタンスがアベイラビリティーゾーン、ルートテーブル、インスタンス、ネットワークインターフェイスのプロパティを記述できるようにします。Amazon EC2 インスタンスがコントロールプレーンインスタンスとして正常にクラスターに参加するために必要なアクセス許可です。
+ **`ssm`** - Amazon EC2 Systems Manager がコントロールプレーンインスタンスに接続できるようにします。これはアカウントのローカルクラスターと通信して管理するために、Amazon EKS によって使用されます。
+ ** `logs` ** - インスタンスが Amazon CloudWatch にログをプッシュできるようにします。
+ **`secretsmanager`** - インスタンスがコントロールプレーンインスタンスのブートストラップデータを AWS 秘密マネジャー から安全に取得および削除できるようにします。
+ ** `ecr` ** - コントロールプレーンインスタンス上で動作している Pod とコンテナが、Amazon Elastic Container Registry に格納されているコンテナイメージをプルできるようにします。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKSLocalOutpostClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostClusterPolicy.html#AmazonEKSLocalOutpostClusterPolicy-json)」を参照してください。
## AWS マネージドポリシー: AmazonEKSLocalOutpostServiceRolePolicy
このポリシーを IAM エンティティにアタッチすることはできません。`iam:CreateServiceLinkedRole` 権限のある IAM プリンシパルを使用してクラスターを作成する場合、Amazon EKS は [AWSServiceRoleforAmazonEKSLocalOutpost](using-service-linked-roles-eks-outpost.md) のサービスにリンクされた役割を自動的に作成し、このポリシーをアタッチします。このポリシーはサービスにリンクされた役割はローカルクラスターの代わりに AWS サービスを呼び出すことを許可します。
`AmazonEKSLocalOutpostServiceRolePolicy` には以下の権限が含まれています。
+ ** `ec2` ** - Amazon EKS がセキュリティ、ネットワーク、その他のリソースと連携して、アカウント内のコントロールプレーンインスタンスを正常に起動および管理できるようにします。
+ ** `ssm`、`ssmmessages` ** – Amazon EC2 システムマネージャーがコントロールプレーンインスタンスに接続できるようにします。アカウントのローカルクラスターと通信および管理するため、Amazon EKS によって使用されます。
+ ** `iam` ** - Amazon EKS がコントロールプレーンインスタンスに関連付けられたインスタンスプロファイルを管理できるようにします。
+ **`secretsmanager`** - Amazon EKS がコントロールプレーンインスタンスのブートストラップデータを AWS 秘密マネジャー に格納できるようにします。これにより、インスタンスのブートストラップ中に安全に参照できるようになります。
+ ** `outposts` ** - Amazon EKS がお客様のアカウントから Outpost 情報を取得して、Outpost でローカルクラスターを正常に起動できるようにします。
JSON ポリシードキュメントの最新バージョンを確認するには『AWS管理ポリシーリファレンスガイド』の「[AmazonEKSLocalOutpostServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostServiceRolePolicy.html#AmazonEKSLocalOutpostServiceRolePolicy-json)」を参照してください。
## Amazon EKS による AWS 管理ポリシーの更新
Amazon EKS の AWS 管理ポリシーの更新に関する詳細を、このサービスがこれらの変更の追跡を開始した以降の分について表示します。
この特定のドキュメントページへのすべてのソースファイルの変更通知を受け取るには、RSS リーダーを使用して次の URL をサブスクライブできます。
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/security/iam-reference/security-iam-awsmanpol.adoc.atom
```
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| [AWS 管理ポリシー: AmazonEKSNetworkingPolicy](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy) にアクセス許可が追加されました。 | `AmazonEKSNetworkingPolicy` に `ec2:ModifyNetworkInterfaceAttribute` アクセス許可を追加しました。これにより、Amazon EKS 自動モードコントローラーは EC2 インスタンスに関連するネットワークインターフェイス属性を変更できます。 | 2026 年 2 月 3 日 |
| 許可を [AWS 管理ポリシー: AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup) に追加しました。 | `AWSServiceRoleForAmazonEKSNodegroup` に `autoscaling:PutWarmPool`、`autoscaling:DeleteWarmPool` および `autoscaling:DescribeWarmPool` のアクセス許可を追加しました。これにより、Amazon EKS Managed Nodegroup はノードグループのライフサイクル全体で基盤となる ASG ウォームプールリソースを管理できます。 | 2026 年 2 月 17 日 |
| [AWS 管理ポリシー: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) にアクセス許可が追加されました。 | `AmazonEKSServiceRolePolicy` 内の、`iam:GetInstanceProfile` アクセス許可のターゲットインスタンスプロファイル名に「eks」プレフィックスを付ける要件を削除しました。これにより、Amazon EKS Auto Mode は「eks」という命名プレフィックスを必要とせずに NodeClasses のカスタムインスタンスプロファイルを検証して使用できます。 | 2026 年 2 月 2 日 |
| [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy) にアクセス許可を追加しました。 | EBS CSI ドライバーが EBS スナップショットを直接ロックできるように、`ec2:LockSnapshot` アクセス許可を追加しました。 | 2026 年 1 月 15 日 |
| [AWS マネージドポリシー: AmazonEKSMCPReadOnlyAccess](#security-iam-awsmanpol-amazoneksmcpreadonlyaccess) について説明しました。 | Amazon EKS は、オブザーバビリティとトラブルシューティングのために、Amazon EKS MCP サーバーで読み取り専用ツールを有効にする新しいマネージドポリシー `AmazonEKSMCPReadOnlyAccess` を導入しました。 | 2025 年 11 月 21 日 |
| [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy) にアクセス許可を追加しました。 | EBS CSI ドライバーが EBS ボリュームを直接コピーできるようにする `ec2:CopyVolumes` アクセス許可を追加しました。 | 2025 年 11 月 17 日 |
| [AWS 管理ポリシー: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) にアクセス許可が追加されました。 | `AmazonEKSServiceRolePolicy` に `ec2:DescribeRouteTables` および `ec2:DescribeNetworkAcls` アクセス許可を追加しました。これにより、Amazon EKS はクラスターインサイトの一部として、ハイブリッドノードの VPC ルートテーブルとネットワーク ACL の設定問題を検出できます。 | 2025 年 10 月 22 日 |
| [AWSServiceRoleForAmazonEKSConnector](using-service-linked-roles-eks-connector.md) にアクセス許可が追加されました | `AmazonEKSConnectorServiceRolePolicy` に `ssmmessages:OpenDataChannel` アクセス許可を追加しました。 | 2025 年 10 月 15 日 |
| [AWS 管理ポリシー: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) にアクセス許可が追加されました | このロールは、新しいアクセスポリシー `AmazonEKSEventPolicy` をアタッチできます。`ec2:DeleteLaunchTemplate` と `ec2:TerminateInstances` の制限されたアクセス許可。 | 2025 年 8 月 26 日 |
| [AWS マネージドポリシー: AmazonEKSLocalOutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) にアクセス許可が追加されました | `AmazonEKSLocalOutpostServiceRolePolicy` に `ssmmessages:OpenDataChannel` アクセス許可が追加されました。 | 2025 年 6 月 26 日 |
| [AWS マネージドポリシー: AmazonEKSComputePolicy](#security-iam-awsmanpol-AmazonEKSComputePolicy) にアクセス許可が追加されました。 | キャパシティ予約 ` arn:aws:ec2:*:*:capacity-reservation/*` を含めるため、`ec2:RunInstances` および `ec2:CreateFleet` アクションのリソースアクセス許可が更新されました。これにより、Amazon EKS Auto Mode は、アカウントの EC2 オンデマンドキャパシティ予約を使用してインスタンスを起動できるようになります。Amazon EKS Auto Mode がユーザーに代わって EC2 スポットサービスにリンクされたロール `AWSServiceRoleForEC2Spot` を作成できるように、`iam:CreateServiceLinkedRole` が追加されました。 | 2025 年 6 月 20 日 |
| [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) にアクセス許可を追加しました。 | アカウントの EC2 オンデマンドキャパシティ予約を使用して Amazon EKS Auto Mode がインスタンスを起動できるように、`ec2:DescribeCapacityReservations` アクセス許可が追加されました。 | 2025 年 6 月 20 日 |
| [AWS マネージドポリシー: AmazonEKSDashboardConsoleReadOnly](#security-iam-awsmanpol-amazoneksdashboardconsolereadonly) について説明しました。 | 新しい `AmazonEKSDashboardConsoleReadOnly` ポリシーを導入しました。 | 2025 年 6 月 19 日 |
| [AWS マネージドポリシー: AmazonEKSDashboardServiceRolePolicy](#security-iam-awsmanpol-AmazonEKSDashboardServiceRolePolicy) について説明しました。 | 新しい `AmazonEKSDashboardServiceRolePolicy` ポリシーを導入しました。 | 2025 年 5 月 21 日 |
| [アマゾンEKSClusterPolicy](#security-iam-awsmanpol-amazoneksclusterpolicy) に権限を追加しました。 | VPC CNI が予期せず終了した場合に残された Elastic Network Interface を Amazon EKS が削除できるように、`ec2:DeleteNetworkInterfaces` アクセス許可が追加されました。 | 2025 年 4 月 16 日 |
| [AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) にアクセス許可を追加しました。 | EKS 1.33 バージョンリリースの一環として、EKS AI/ML の顧客が EFA と互換性のあるセキュリティグループ Egress (アウトバウンド) ルールをデフォルトの EKS クラスター SG に追加できるように、`ec2:RevokeSecurityGroupEgress` および `ec2:AuthorizeSecurityGroupEgress` アクセス許可が追加されました。 | 2025 年 4 月 14 日 |
| [アマゾンEKSサービスRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) に許可を追加しました。 | EKS Auto Mode によって作成された EC2 インスタンスを終了できるようにアクセス許可を追加しました。 | 2025 年 2 月 28 日 |
| [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy) にアクセス許可を追加しました。 | EBS CSI ドライバーがすべてのスナップショットを復元することを許可する新しいステートメントを追加しました。これは既存のポリシーでは以前は許可されていましたが、`CreateVolume` の IAM の処理が変更されたため、新しい明示的なステートメントが必要になりました。 EBS CSI ドライバーが既存のボリュームのタグを変更する機能を追加しました。EBS CSI ドライバーは、Kubernetes VolumeAttributesClasses のパラメータを介して既存のボリュームのタグを変更できます。 EBS ボリューム上で高速スナップショット復元 (FSR) を有効にするために EBS CSI ドライバーの機能を追加しました。EBS CSI ドライバーは、Kubernetes ストレージクラスのパラメータを介して、新しいボリュームで FSR を有効にできます。 | 2025年1月13日 |
| 許可を [AWS マネージドポリシー: AmazonEKSLoadBalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy) に追加しました。 | `AmazonEKSLoadBalancingPolicy` を更新して、ネットワークおよび IP アドレス リソースの一覧表示と説明ができるようになりました。 | 2024 年 12 月 26 日 |
| 許可を [AWS 管理ポリシー: AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup) に追加しました。 | `AWSServiceRoleForAmazonEKSNodegroup` が中国リージョンとの互換性のために更新されました。 | 2024 年 11 月 22 日 |
| アクセス許可を [AWS マネージドポリシー: AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) に追加しました。 | 各ノードが存在するアベイラビリティーゾーンを、クラスターコントロールプレーンの AWS クラウド コントローラー マネージャー が識別できるように、`AmazonEKSLocalOutpostClusterPolicy` に `ec2:DescribeAvailabilityZones` 許可を追加しました。 | 2024 年 11 月 21 日 |
| 許可を [AWS 管理ポリシー: AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup) に追加しました。 | Amazon EKS マネージドノードグループによって作成されたインスタンスのために `ec2:RebootInstances` を許可するように `AWSServiceRoleForAmazonEKSNodegroup` ポリシーを更新しました。Amazon EC2 リソースについての `ec2:CreateTags` 許可を制限しました。 | 2024 年 11 月 20 日 |
| 許可を [AWS 管理ポリシー: AmazonEKSServiceRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) に追加しました。 | EKS が AWS マネージドポリシー `AmazonEKSServiceRolePolicy` を更新しました。EKS アクセスポリシー、ロードバランサーの管理、クラスターリソースの自動クリーンアップの許可を追加しました。 | 2024 年 11 月 16 日 |
| [AWS マネージドポリシー: AmazonEKSComputePolicy](#security-iam-awsmanpol-AmazonEKSComputePolicy) について説明しました。 | EKS が AWS マネージドポリシー `AmazonEKSComputePolicy` を更新しました。`iam:AddRoleToInstanceProfile` アクションのリソース許可を更新しました。 | 2024 年 11 月 7 日 |
| [AWS マネージドポリシー: AmazonEKSComputePolicy](#security-iam-awsmanpol-AmazonEKSComputePolicy) について説明しました。 | AWS は `AmazonEKSComputePolicy` を導入しました。 | 2024 年 11 月 1 日 |
| アクセス許可を `AmazonEKSClusterPolicy` に追加しました。 | Amazon EKS がトポロジ情報をラベルとしてノードにアタッチできるようにする `ec2:DescribeInstanceTopology` 許可を追加しました。 | 2024 年 11 月 1 日 |
| [AWS マネージドポリシー: AmazonEKSBlockStoragePolicy](#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy) について説明しました。 | AWS は `AmazonEKSBlockStoragePolicy` を導入しました。 | 2024 年 10 月 30 日 |
| [AWS マネージドポリシー: AmazonEKSLoadBalancingPolicy](#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy) について説明しました。 | AWS は `AmazonEKSLoadBalancingPolicy` を導入しました。 | 2024 年 10 月 30 日 |
| [アマゾンEKSサービスRolePolicy](#security-iam-awsmanpol-amazoneksservicerolepolicy) に許可を追加しました。 | Amazon EKS が Amazon CloudWatch にメトリクスを発行できるようにする `cloudwatch:PutMetricData` 許可を追加しました。 | 2024 年 10 月 29 日 |
| [AWS 管理ポリシー: AmazonEKSNetworkingPolicy](#security-iam-awsmanpol-AmazonEKSNetworkingPolicy) について説明しました。 | AWS は `AmazonEKSNetworkingPolicy` を導入しました。 | 2024 年 10 月 28 日 |
| `AmazonEKSServicePolicy` および `AmazonEKSServiceRolePolicy` にアクセス許可を追加しました。 | EKS がセキュリティグループ情報を読み取り、関連するタグを更新できるように、`ec2:GetSecurityGroupsForVpc` および関連するタグの許可を追加しました。 | 2024 年 10 月 10 日 |
| [AmazonEKSWorkerNodeMinimalPolicy](#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy) を導入しました。 | AWS は `AmazonEKSWorkerNodeMinimalPolicy` を導入しました。 | 2024 年 10 月 3 日 |
| [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup) に権限を追加しました。 | Amazon EKS が管理する 自動スケーリング グループで Amazon EKS が `AZRebalance` を一時停止および再開できるようにする `autoscaling:ResumeProcesses` および `autoscaling:SuspendProcesses` アクセス許可が追加されました。 | 2024 年 8 月 21 日 |
| [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup) に権限を追加しました。 | Amazon EKS がユーザーのアカウントでキャパシティ予約を記述できるようにする `ec2:DescribeCapacityReservations` アクセス許可を追加しました。`CAPACITY_BLOCK` ノードグループでスケジュールされたスケーリングの設定を有効にする `autoscaling:PutScheduledUpdateGroupAction` アクセス許可を追加しました。 | 2024 年 6 月 27 日 |
| [AmazonEKS\$1CNI\$1Policy](#security-iam-awsmanpol-amazoneks-cni-policy) – 既存のポリシーへの更新 | Amazon EKS は、Amazon VPC CNI Plugin for Kubernetes で Amazon VPC サブネット内の空き IP アドレスの量を確認できるようにする新しい `ec2:DescribeSubnets` 許可を追加しました。VPC CNI は各サブネットの空き IP アドレスを使用して、エラスティック・ネットワーク・インターフェイス の作成時に使用する空き IP アドレスが最も多いサブネットを選択できます。 | 2024 年 3 月 4 日 |
| [AmazonEKSWorkerNodePolicy](#security-iam-awsmanpol-amazoneksworkernodepolicy) – 既存のポリシーへの更新 | Amazon EKS は EKS Pod Identity を許可する新しいアクセス権限を追加しました。Amazon EKS Pod Identity エージェントはノード役割を使用します。 | 2023 年 11 月 26 日 |
| [AmazonEFSCSIDriverPolicy](#security-iam-awsmanpol-amazonefscsidriverservicerolepolicy) を導入しました。 | AWS は `AmazonEFSCSIDriverPolicy` を導入しました。 | 2023 年 7 月 26 日 |
| [アマゾンEKSClusterPolicy](#security-iam-awsmanpol-amazoneksclusterpolicy) に権限を追加しました。 | ロードバランサーを作成しながら、サブネットの自動検出中に Amazon EKS が AZ の詳細を取得できるようにする `ec2:DescribeAvailabilityZones` 許可が追加されました。 | 2023 年 2 月 7 日 |
| [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy) のポリシー条件が更新されました。 | `StringLike` キーフィールドにワイルドカード文字を含む無効なポリシー条件を削除しました。また `ec2:DeleteVolume` に新しい条件 `ec2:ResourceTag/kubernetes.io/created-for/pvc/name: "*"` も追加され、ツリー内プラグインで作成されたボリュームを EBS CSI ドライバーが削除できるようになりました。 | 2022 年 11 月 17 日 |
| [AmazonEKSLocalOutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) にアクセス許可を追加しました。 | 前提条件の検証とマネージドライフサイクルの管理が向上するように、`ec2:DescribeVPCAttribute`、`ec2:GetConsoleOutput`、`ec2:DescribeSecret` を追加しました。また、Outposts のコントロールプレーン Amazon EC2 インスタンスの配置制御をサポートするため、`ec2:DescribePlacementGroups`、`"arn:aws:ec2:*:*:placement-group/*"`、`ec2:RunInstances` が追加しました。 | 2022 年 10 月 24 日 |
| [AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) の Amazon Elastic Container Registry のアクセス権限を更新します。 | `ecr:GetDownloadUrlForLayer` アクションを、全リソースセクションからスコープされたセクションに移動しました。` arn:aws:ecr:*:*:repository/eks/ ` リソースを追加しました。` arn:aws:ecr:` リソースを削除しました。このリソースは追加された ` arn:aws:ecr:*:*:repository/eks/*` リソースでカバーします。 | 2022 年 10 月 20 日 |
| [AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) にアクセス許可を追加しました。 | クラスターコントロールプレーンインスタンスがいくつかの `kubelet` 引数を更新できるように、` arn:aws:ecr:*:*:repository/kubelet-config-updater` Amazon Elastic Container Registry リポジトリを追加しました。 | 2022 年 8 月 31 日 |
| [AmazonEKSLocalOutpostClusterPolicy](#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) を導入しました。 | AWS は `AmazonEKSLocalOutpostClusterPolicy` を導入しました。 | 2022 年 8 月 24 日 |
| [AmazonEKSLocalOutpostServiceRolePolicy](#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) を導入しました。 | AWS は `AmazonEKSLocalOutpostServiceRolePolicy` を導入しました。 | 2022 年 8 月 23 日 |
| [AmazonEBSCSIDriverPolicy](#security-iam-awsmanpol-amazonebscsidriverservicerolepolicy) を導入しました。 | AWS は `AmazonEBSCSIDriverPolicy` を導入しました。 | 2022 年 4 月 4 日 |
| [AmazonEKSWorkerNodePolicy](#security-iam-awsmanpol-amazoneksworkernodepolicy) に権限を追加しました。 | インスタンスレベルのプロパティを自動検出できる Amazon EKS に最適化された AMI を有効化する `ec2:DescribeInstanceTypes` を追加しました。 | 2022 年 3 月 21 日 |
| [AWSServiceRoleForAmazonEKSNodegroup](#security-iam-awsmanpol-awsserviceroleforamazoneksnodegroup) に権限を追加しました。 | Amazon EKS がメトリクスの収集を有効にすることを許可する `autoscaling:EnableMetricsCollection` アクセス許可を追加しました。 | 2021 年 12 月 13 日 |
| [アマゾンEKSClusterPolicy](#security-iam-awsmanpol-amazoneksclusterpolicy) に権限を追加しました。 | `ec2:DescribeAccountAttributes`、`ec2:DescribeAddresses`、`ec2:DescribeInternetGateways` の権限を追加し、Amazon EKS が Network Load Balancer のサービスにリンクされた役割を作成できるようになりました。 | 2021 年 6 月 17 日 |
| Amazon EKS が変更の追跡を開始しました。 | Amazon EKS が AWS 管理ポリシーの変更の追跡を開始しました。 | 2021 年 6 月 17 日 |
# IAM のトラブルシューティング
このトピックでは、IAM での Amazon EKS の使用中に表示される一般的なエラーとその回避方法について説明します。
## AccessDeniedException
AWS API オペレーションの呼び出し時に `AccessDeniedException` を受け取った場合、使用している [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)の認証情報には、その呼び出しに必要な許可がありません。
```
An error occurred (AccessDeniedException) when calling the DescribeCluster operation:
User: arn:aws:iam::111122223333:user/user_name is not authorized to perform:
eks:DescribeCluster on resource: arn:aws:eks:region:111122223333:cluster/my-cluster
```
前記のメッセージの例では、ユーザーには Amazon EKS `DescribeCluster` API オペレーションを呼び出す許可がありません。IAM プリンシパルに Amazon EKS 管理者の許可を付与するには、「[Amazon EKS でのアイデンティティベースのポリシーの例](security-iam-id-based-policy-examples.md)」を参照してください。
IAM の一般的な情報については、*IAM ユーザーガイド*の「[ポリシーを使用したアクセスの制御](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html)」を参照してください。
## **[Compute]** (コンピューティング) タブに **[Nodes]** (ノード) が表示されず、また **[Resources]** (リソース) タブにも何も表示されず、AWS マネジメントコンソール でエラーが表示される
`Your current user or role does not have access to Kubernetes objects on this EKS cluster`というコンソールのエラーメッセージが表示されることがあります。AWS マネジメントコンソール を使用している [IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)ユーザーに必要な許可があることを確認してください。詳細については、「[必要なアクセス許可](view-kubernetes-resources.md#view-kubernetes-resources-permissions)」を参照してください。
## aws-auth `ConfigMap` がクラスターへのアクセスを許可しない
[AWS IAM Authenticator](https://github.com/kubernetes-sigs/aws-iam-authenticator) は、`ConfigMap` で使用されるロール ARN でパスを許可しません。したがって、`rolearn` を指定する前に、パスを削除してください。例えば、` arn:aws:iam::111122223333:role/team/developers/eks-admin ` を ` arn:aws:iam::111122223333:role/eks-admin ` に変更します。
## iam:PassRole を実行する権限がありません
`iam:PassRole` アクションを実行する権限がないというエラーが表示された場合は、ポリシーを更新して Amazon EKS にロールを渡せるようにする必要があります。
一部の AWS サービスでは、新しいサービスロールまたはサービスリンクロールを作成せずに、既存のロールをサービスに渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。
次の例のエラーは、`marymajor` という IAM ユーザーがコンソールを使用して Amazon EKS でアクションを実行しようとする場合に発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与されたアクセス許可が必要です。Mary には、ロールをサービスに渡すアクセス許可がありません。
```
User: {arn-aws}iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
この場合、メアリーのポリシーを更新してメアリーに `iam:PassRole` アクションの実行を許可する必要があります。
サポートが必要な場合は、AWS 管理者に問い合わせてください。サインイン認証情報を提供した担当者が管理者です。
## AWS アカウント以外のユーザーに Amazon EKS リソースへのアクセスを許可したい
他のアカウントのユーザーや組織外のユーザーが、リソースへのアクセスに使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。
詳細については、以下を参照してください。
+ Amazon EKS がこれらの機能をサポートしているかどうかについては、「[アマゾン EKS で IAM を使用する方法](security-iam-service-with-iam.md)」を参照してください。
+ 所有している AWS アカウント間でリソースへのアクセスを付与する方法については、*IAM ユーザーガイド* の「[所有している別の AWS アカウントへのアクセスを IAM ユーザーに許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)」を参照してください。
+ リソースへのアクセスをサードパーティーの AWS アカウントに提供する方法については、IAM ユーザーガイドの「[サードパーティーが所有する AWS アカウントへのアクセスの提供](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)」を参照してください。
+ ID フェデレーションを介してアクセスを提供する方法については、*IAM ユーザーガイド* の [外部で認証されたユーザー (ID フェデレーション) へのアクセスの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) を参照してください。
+ クロスアカウントアクセスにおけるロールとリソースベースのポリシーの使用方法の違いについては、*IAM ユーザーガイド* の [IAM でのクロスアカウントのリソースへのアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。
## ポッドコンテナは次のエラーを受け取ります: `An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region`
アプリケーションが AWS STS グローバルエンドポイント (`https://sts.amazonaws`) に明示的にリクエストを行っていて、Kubernetes サービスアカウントがリージョンエンドポイントを使用するように設定されている場合、コンテナはこのエラーを受け取ります。次のいずれかのオプションを使用して問題を解決できます。
+ アプリケーションコードを更新して、AWS STS グローバルエンドポイントへの明示的な呼び出しを削除します。
+ アプリケーションコードを更新して、`https://sts.us-west-2.amazonaws.com` などのリージョンエンドポイントへの明示的な呼び出しを行います。AWS リージョン内のサービスに障害が発生した場合に別の AWS リージョンを選択するよう、アプリケーションに冗長性が組み込まれている必要があります。詳細については、IAM ユーザーガイドの「[AWS リージョンでの AWS STS の管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html)」を参照してください。
+ グローバルエンドポイントを使用するようにサービスアカウントを設定します。クラスターでは、デフォルトでリージョンエンドポイントが使用されます。詳細については、「[サービスアカウントの AWS Security Token Service エンドポイントを設定する](configure-sts-endpoint.md)」を参照してください。
# Amazon EKS クラスター の IAM ロール
Amazon EKS クラスター IAM ロールはクラスターごとに必要です。Amazon EKS によって管理される Kubernetes クラスターはこのロールを使用してノードを管理し、[レガシークラウドプロバイダー](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider)はこのロールを使用して Elastic Load Balancing によるロードバランサーをサービス用に作成します。
Amazon EKS クラスターを使用するには、事前に次の IAM ポリシーのいずれかを持つ IAM ロールを作成する必要があります。
+ [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html)
+ カスタム IAM ポリシー。以下の最小限の許可では、Kubernetes クラスターがノードを管理することはできますが、[レガシークラウドプロバイダー](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/#legacy-cloud-provider)が Elastic Load Balancing によるロードバランサーを作成することはできません。カスタム IAM ポリシーには、少なくとも以下の許可が必要です。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"ForAnyValue:StringLike": {
"aws:TagKeys": "kubernetes.io/cluster/*"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeVpcs",
"ec2:DescribeDhcpOptions",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeInstanceTopology",
"kms:DescribeKey"
],
"Resource": "*"
}
]
}
```
**注記**
2023 年 10 月 3 日より前は、各クラスターの IAM ロールには [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) が必要でした。
2020 年 4 月 16 日までは、[AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) および [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html) が必須であり、ロールに推奨される名前は `eksServiceRole` でした。`AWSServiceRoleForAmazonEKS` のサービスにリンクされたロールにより、2020 年 4 月 16 日以降に作成されたクラスターに対しては、[AmazonEKSServicePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSServicePolicy.html) ポリシーは必要なくなりました。
## 既存のクラスターロールの確認
次の手順を使用して、アカウントに Amazon EKS クラスターロールが既に存在しているかどうかが確認できます。
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. ロールのリストで `eksClusterRole` を検索します。`eksClusterRole` が含まれているロールが存在しない場合は、[Amazon EKS でのクラスターロールの作成](#create-service-role) を参照してロールを作成します。`eksClusterRole` が含まれているロールが存在する場合はこのロールを選択してアタッチされているポリシーを表示します。
1. **[許可]** を選択してください。
1. **AmazonEKSClusterPolicy** 管理ポリシーがロールにアタッチされていることを確認します。ポリシーがアタッチされている場合、Amazon EKS クラスターロールは適切に設定されています。
1. **[Trust relationships]** (信頼関係）を 選択し、**[Edit trust policy]** (信頼ポリシーの編集）を選択してください。
1. 信頼関係に以下のポリシーが含まれていることを確認します。信頼関係が以下のポリシーと一致する場合、**[キャンセル]** を選択してください。信頼関係が一致しない場合、ポリシーを **[信頼ポリシーの編集]** ウィンドウにコピーし、**[ポリシーの更新]** を選択します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
## Amazon EKS でのクラスターロールの作成
クラスターロールを作成するにはAWS マネジメントコンソール または AWS CLI を使用できます。
AWS マネジメントコンソール
1. https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。
1. [**ロール**] を選択してから [**ロールの作成**] を選びます。
1. [**信頼できるエンティティタイプ**] の下で、[**AWS サービス**] を選択してください。
1. [**他の AWS サービスのユースケース**] ドロップダウンリストから、[**EKS**] を選択してください。
1. ユースケースに **[EKS - Cluster]** (EKS - クラスター）を 選択し、**[ 次へ]** (次へ）を 選択してください。
1. **[Add permissions]** (アクセス許可を追加する) タブで、**[Next]** (次へ) を選択します。
1. **[ロール名]** に、`eksClusterRole` などのロールの一意の名前を入力します。
1. **[Description]** (説明） には`Amazon EKS - Cluster role` のような説明文を入力してください。
1. [**ロールの作成**] を選択してください。
AWS CLI
1. 次の内容を *cluster-trust-policy.jsonl* という名前のファイルにコピーします。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. ロールを作成します。*eksClusterRole* は、任意の名前で置き換えることができます。
```
aws iam create-role \
--role-name eksClusterRole \
--assume-role-policy-document file://"cluster-trust-policy.json"
```
1. 必要な IAM ポリシーをロールにアタッチします。
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy \
--role-name eksClusterRole
```
# Amazon EKS ノードの IAM ロール
Amazon EKS ノード `kubelet` デーモンが、ユーザーに代わって AWS API への呼び出しを実行します。ノードは、IAM インスタンスプロファイルおよび関連ポリシーを通じて、これらの API コールのアクセス許可を受け取ります。ノードを起動してクラスターに登録する前に、起動するときに使用するノード用の IAM ロールを作成する必要があります。この要件は、Amazon が提供する Amazon EKS 最適化 AMI で起動されたノード、または使用する予定の他のノード AMI で起動されたノードに適用されます。さらに、この要件はマネージド型ノードグループとセルフマネージド型ノードの両方に適用されます。
**注記**
クラスターの作成に使用したロールは使用できません。
ノードを使用するには、次の アクセス許可を持つ IAM ロールを作成する必要があります。
+ `kubelet` が VPC 内の Amazon EC2 リソースを記述するためのアクセス許可 ([AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html) ポリシーで規定されているなど)。このポリシーは、Amazon EKS Pod Identity エージェントのアクセス許可も提供します。
+ `kubelet` が Amazon Elastic Container Registry (Amazon ECR) のコンテナイメージを使用するためのアクセス許可 ([AmazonEC2ContainerRegistryPullOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEC2ContainerRegistryPullOnly.html) ポリシーで規定されているなど)。ネットワーキング用の組み込みアドオンは Amazon ECR のコンテナイメージを使用するポッドを実行するため、Amazon Elastic Container Registry (Amazon ECR) のコンテナイメージを使用する許可が必要です。
+ (オプション) Amazon EKS Pod Identity エージェントが `eks-auth:AssumeRoleForPodIdentity` アクションを使用してポッドの認証情報を取得するためのアクセス許可。[AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSWorkerNodePolicy.html) を使用しない場合、EKS Pod Identity を使用するには EC2 アクセス許可に加えてこのアクセス許可も提供する必要があります。
+ (任意) IRSA または EKS Pod Identity を使用して VPC CNI ポッドにアクセス許可を付与しない場合は、インスタンスロールで VPC CNI のアクセス許可を付与する必要があります。[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html) マネージドポリシー (`IPv4` ファミリーを使用してクラスターを作成した場合) または[作成した IPv6 ポリシー](cni-iam-role.md#cni-iam-role-create-ipv6-policy) (`IPv6` ファミリーを使用してクラスターを作成した場合) のいずれかを使用できます。ただし、このロールにポリシーをアタッチするのではなく、Amazon VPC CNI アドオン専用の別のロールにポリシーをアタッチすることをお勧めします。Amazon VPC CNI アドオン用に別のロールを作成する方法の詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。
**注記**
Amazon EC2 ノードグループには、Fargate プロファイルとは異なる IAM ロールが必要です。詳細については、「[Amazon EKS Pod 実行 IAM ロール](pod-execution-role.md)」を参照してください。
## 既存のノードロールの確認
以下の手順を使用して、アカウントに既に Amazon EKS ノードロールがあるかどうかが確認できます。
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. ロールのリストで `eksNodeRole`、`AmazonEKSNodeRole`、または `NodeInstanceRole` を検索します。これらの名前のいずれかを持つロールが存在しない場合、「[Amazon EKS ノードでの IAM ロールの作成](#create-worker-node-role)」を参照してロールを作成してください。`eksNodeRole`、`AmazonEKSNodeRole`、あるいは `NodeInstanceRole` を含むロールが存在する場合、そのロールを選択して、アタッチされているポリシーを表示します。
1. **[許可]** を選択してください。
1. **AmazonEKSWorkerNodePolicy** および **AmazonEC2ContainerRegistryPullOnly** のマネージドポリシーがロールにアタッチされていること、またはカスタムポリシーが最小限の許可でアタッチされていることを確認します。
**注記**
そのロールに [**AmazonEKS\$1CNI\$1Policy**] ポリシーがアタッチされている場合は、そのポリシーを一度削除して、`aws-node` Kubernetes サービスアカウントにマッピングされた IAM ロールにアタッチし直すことをお勧めします。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。
1. **[信頼関係]** を選択し、**[信頼ポリシーの編集]** を選択します。
1. 信頼関係に以下のポリシーが含まれていることを確認します。信頼関係が以下のポリシーと一致する場合、**[キャンセル]** を選択してください。信頼関係が一致しない場合、ポリシーを **[信頼ポリシーの編集]** ウィンドウにコピーし、**[ポリシーの更新]** を選択してください。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Principal": {
"Service": [
"ec2.amazonaws.com"
]
}
}
]
}
```
## Amazon EKS ノードでの IAM ロールの作成
AWS マネジメントコンソール または AWS CLI を使用して、ノードの IAM ロールを作成できます。
AWS マネジメントコンソール
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. **[ロール]** ページで、**[ロールの作成]** を選択してください。
1. **[信頼されたエンティティを選択]** ページで、以下の操作を実行してください：
1. **[信頼するエンティティのタイプ]** で **[AWS サービス]** を選択してください。
1. **[ユースケース]** で、**[EC2]** を選択してください。
1. [**次へ**] を選択します。
1. **[アクセス許可を追加]** ページで、カスタムポリシーをアタッチするか、以下の操作を行います。
1. **[フィルタポリシー]** ボックスに `AmazonEKSWorkerNodePolicy` と入力します。
1. 検索結果の **[AmazonEKSWorkerNodePolicy]** の左にあるチェックボックスを選択します。
1. **[フィルターのクリア]** を選択します。
1. **[フィルタポリシー]** ボックスに `AmazonEC2ContainerRegistryPullOnly` と入力します。
1. 検索結果の **[AmazonEC2ContainerRegistryPullOnly]** の左にあるチェックボックスを選択します。
このロールまたは `aws-node` Kubernetes サービスアカウントにマッピングされた別のロールに、**AmazonEKS\$1CNI\$1Policy** マネージドポリシーまたは作成した [IPv6 ポリシー](cni-iam-role.md#cni-iam-role-create-ipv6-policy)をアタッチする必要もあります。このロールに対してではなく、Kubernetes サービスアカウントに関連付けられたロールに、前出のポリシーを割り当てることをお勧めします。詳細については、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照してください。
1. **[Next]** (次へ) を選択します。
1. **[名前を付けて、レビューし、作成する]** ページで、以下の操作を実行します。
1. **[ロール名]** に、`AmazonEKSNodeRole` などのロールの一意の名前を入力します。
1. **[説明]** では現在のテキストを「`Amazon EKS - Node role`」などの説明文に置き換えます。
1. **[タグの追加 (オプション)]** で、タグをキーバリューのペアとして添付して、メタデータをロールに追加します。IAM でのタグの使用に関する詳細については『*IAM ユーザーガイド*』の「[IAM リソースにタグを付ける](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html)」を参照してください。
1. [**ロールの作成**] を選択してください。
AWS CLI
1. 次のコマンドを実行して、`node-role-trust-relationship.json` ファイルを作成します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Principal": {
"Service": [
"ec2.amazonaws.com"
]
}
}
]
}
```
1. IAM ロールの作成
```
aws iam create-role \
--role-name AmazonEKSNodeRole \
--assume-role-policy-document file://"node-role-trust-relationship.json"
```
1. IAM ロールに、2 つの必須なマネージド IAM ポリシーをアタッチします。
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \
--role-name AmazonEKSNodeRole
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly \
--role-name AmazonEKSNodeRole
```
1. クラスターを作成した IP ファミリーに応じて、次の IAM ポリシーの 1 つを IAM ロールにアタッチします。このポリシーは、このロール、または、Kubernetes の `aws-node` サービスアカウントに関連付けられたロールにアタッチされる必要があります。これらのロールは、Amazon VPC CNI plugin for Kubernetes で使用されます。このポリシーは、Kubernetes サービスアカウントに関連付けられたロールにを割り当てることをお勧めします。Kubernetes サービスアカウントに関連付けられたロールへのポリシーの割り当てについては、「[IRSA を使用するように Amazon VPC CNI プラグインを設定する](cni-iam-role.md)」を参照しください。
+ IPv4
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \
--role-name AmazonEKSNodeRole
```
+ IPv6
1. 次のテキストをコピーし、`vpc-cni-ipv6-policy.json` という名前のファイルに保存します。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssignIpv6Addresses",
"ec2:DescribeInstances",
"ec2:DescribeTags",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeInstanceTypes"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": [
"arn:aws:ec2:*:*:network-interface/*"
]
}
]
}
```
1. IAM ポリシーを作成する
```
aws iam create-policy --policy-name AmazonEKS_CNI_IPv6_Policy --policy-document file://vpc-cni-ipv6-policy.json
```
1. IAM ロールに IAM ポリシーをアタッチします。*111122223333* は、ご自分のアカウント ID に置き換えます。
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::111122223333:policy/AmazonEKS_CNI_IPv6_Policy \
--role-name AmazonEKSNodeRole
```
# Amazon EKS 自動モードl クラスター IAM ロール
Amazon EKS クラスター IAM ロールはクラスターごとに必要です。Amazon EKS によって管理される Kubernetes クラスターはこのロールを使用して、ストレージ、ネットワーキング、コンピューティングの自動スケーリングのルーチンタスクを自動化します。
Amazon EKS クラスターを使用するにはEKS 自動モードl に必要なポリシーを持つ IAM ロールを作成する必要があります。推奨の AWS IAM マネージドポリシーをアタッチするか、同等のアクセス許可を持つカスタムポリシーを作成することができます。
+ [Amazon EKSコンピュートポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [Amazon EKSブロックストレージポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [Amazon EKSロードバランシングポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [Amazon EKSネットワーキングポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [AmazonEKSClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
## 既存のクラスターロールの確認
次の手順を使用して、アカウントに Amazon EKS クラスターロールが既に存在しているかどうかが確認できます。
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. ロールのリストで `AmazonEKSAutoClusterRole` を検索します。`AmazonEKSAutoClusterRole` を含むロールが存在しない場合は次のセッションの手順を参照してロールを作成します。`AmazonEKSAutoClusterRole` が含まれているロールが存在する場合はこのロールを選択してアタッチされているポリシーを表示します。
1. **[許可]** を選択してください。
1. **AmazonEKSClusterPolicy** 管理ポリシーがロールにアタッチされていることを確認します。ポリシーがアタッチされている場合、Amazon EKS クラスターロールは適切に設定されています。
1. **[Trust relationships]** (信頼関係）を 選択し、**[Edit trust policy]** (信頼ポリシーの編集）を選択してください。
1. 信頼関係に以下のポリシーが含まれていることを確認します。信頼関係が以下のポリシーと一致する場合、**[キャンセル]** を選択してください。信頼関係が一致しない場合、ポリシーを **[信頼ポリシーの編集]** ウィンドウにコピーし、**[ポリシーの更新]** を選択してください。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
**注記**
AWS ではこのロールの名前 `AmazonEKSAutoClusterRole` は必要ありません。
## Amazon EKS でのクラスターロールの作成
クラスターロールを作成するにはAWS マネジメントコンソール または AWS CLI を使用できます。
### AWS マネジメントコンソール
1. https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。
1. [**ロール**] を選択してから [**ロールの作成**] を選びます。
1. [**信頼できるエンティティタイプ**] の下で、[**AWS サービス**] を選択してください。
1. [**他の AWS サービスのユースケース**] ドロップダウンリストから、[**EKS**] を選択してください。
1. ユースケースに **[EKS - Cluster]** (EKS - クラスター）を 選択し、**[ 次へ]** (次へ）を 選択してください。
1. **[アクセス許可を追加]** タブで、ポリシーを選択し、**[次へ]** を選択してください。
+ [Amazon EKSコンピュートポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSComputePolicy)
+ [Amazon EKSブロックストレージポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSBlockStoragePolicy)
+ [Amazon EKSロードバランシングポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSLoadBalancingPolicy)
+ [Amazon EKSネットワーキングポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSNetworkingPolicy)
+ [アマゾンEKSクラスターポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy)
1. **[ロール名]** に、`AmazonEKSAutoClusterRole` などのロールの一意の名前を入力します。
1. **[Description]** (説明） には`Amazon EKS - Cluster role` のような説明文を入力してください。
1. [**ロールの作成**] を選択してください。
### AWS CLI
1. 次の内容を *cluster-trust-policy.jsonl* という名前のファイルにコピーします。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
1. ロールを作成します。*AmazonEKSAutoClusterRole* は任意の名前に置き換えることができます。
```
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://"cluster-trust-policy.json"
```
1. 必要な IAM ポリシーをロールにアタッチします：
**AmazonEKSClusterPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
```
**AmazonEKSコンピュートポリシー**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSComputePolicy
```
**AmazonEKSブロックストレージポリシー**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSBlockStoragePolicy
```
**AmazonEKSロードバランシングポリシー**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSLoadBalancingPolicy
```
**Amazon EKSネットワーキングポリシー**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSNetworkingPolicy
```
# Amazon EKS 自動モードl ノードの IAM ロール
**注記**
クラスターの作成に使用したロールは使用できません。
ノードを作成する前に、次のパイプラインまたは同等のアクセス許可を持つ IAM ロールを作成する必要があります：
+ [Amazon EKSワーカーノードミニマルポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [Amazon EC2コンテナレジストリプルオンリー](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
## 既存のノードロールの確認
以下の手順を使用して、アカウントに既に Amazon EKS ノードロールがあるかどうかが確認できます。
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. ロールのリストで `AmazonEKSAutoNodeRole` を検索します。これらの名前のいずれかを持つロールが存在しない場合は次のセクションの手順を参照してロールを作成します。`AmazonEKSAutoNodeRole` を含むロールがある場合はロールを選択して、アタッチされたポリシーを表示します。
1. **[許可]** を選択してください。
1. 上記の必要なポリシーまたは同等のカスタムポリシーがアタッチされていることを確認します。
1. **[信頼関係]** を選択し、**[信頼ポリシーの編集]** を選択してください。
1. 信頼関係に以下のポリシーが含まれていることを確認します。信頼関係が以下のポリシーと一致する場合、**[キャンセル]** を選択してください。信頼関係が一致しない場合、ポリシーを **[信頼ポリシーの編集]** ウィンドウにコピーし、**[ポリシーの更新]** を選択してください。
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
## Amazon EKS ノードでの IAM ロールの作成
AWS マネジメントコンソール または AWS CLI を使用して、ノードの IAM ロールを作成できます。
### AWS マネジメントコンソール
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. **[ロール]** ページで、**[ロールの作成]** を選択してください。
1. **[信頼されたエンティティを選択]** ページで、以下の操作を実行してください：
1. **[信頼するエンティティのタイプ]** で **[AWS サービス]** を選択してください。
1. **[ユースケース]** で、**[EC2]** を選択してください。
1. [** 次へ**] を選択してください。
1. **[アクセス許可を追加]** ページで、次のポリシーをアタッチします：
+ [Amazon EKSワーカーノードミニマルポリシー](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonEKSWorkerNodeMinimalPolicy)
+ [Amazon EC2コンテナレジストリプルオンリー](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonEC2ContainerRegistryPullOnly)
1. **[名前を付けて、レビューし、作成する]** ページで、以下の操作を実行してください：
1. **[ロール名]** に、`AmazonEKSAutoNodeRole` などのロールの一意の名前を入力します。
1. **[説明]** では現在のテキストを「`Amazon EKS - Node role`」などの説明文に置き換えます。
1. **[タグの追加 (オプション)]** で、タグをキーバリューのペアとして添付して、メタデータをロールに追加します。IAM でのタグの使用に関する詳細については『*IAM ユーザーガイド*』の「[IAM リソースにタグを付ける](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html)」を参照してください。
1. [**ロールの作成**] を選択してください。
### AWS CLI
**ノード IAM ロールを作成する**
前のステップの **node-trust-policy.json** ファイルを使用して、ロールを引き受けることができるエンティティを定義します。次のコマンドを実行してノード IAM ロールを作成します：
```
aws iam create-role \
--role-name AmazonEKSAutoNodeRole \
--assume-role-policy-document file://node-trust-policy.json
```
**ロールの ARN をメモする**
ロールを作成したら、ノード IAM ロールの ARN を取得して保存します。以降のステップでこの ARN が必要になります。次のコマンドを使用して ARN を取得します：
```
aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text
```
**必要なポリシーをアタッチする**
次の AWS マネージドポリシーをノード IAM ロールにアタッチして、必要なアクセス許可を付与します：
Amazon EKSワーカーノードミニマルポリシー をアタッチするには:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy
```
Amazon EC2コンテナレジストリプルオンリー をアタッチするには:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
# Amazon EKS 機能 IAM ロール
EKS 機能には、機能 IAM ロール (または機能ロール) を設定する必要があります。機能は、このロールを使用して AWS サービスに対してアクションを実行し、自動的に作成されたアクセスエントリを介してクラスター内の Kubernetes リソースにアクセスします。
機能の作成時に機能ロールを指定する場合は、事前に IAM ロールを作成してその機能のタイプに適した信頼ポリシーとアクセス許可を付与する必要があります。このように作成した IAM ロールは、任意の数の機能リソースで再利用できます。
## 機能ロールの要件
機能ロールは、以下の要件を満たしている必要があります。
+ クラスターおよび機能リソースと同じ AWS アカウントに存在する必要があります
+ 信頼ポリシーにより、EKS 機能サービスがロールを引き受けることを許可する必要があります。
+ 機能タイプとユースケースの要件に適したアクセス許可を付与する必要があります (「[機能タイプ別のアクセス許可](#capability-permissions)」を参照)。
## 機能ロールの信頼ポリシー
すべての機能ロールに、次の信頼ポリシーを含める必要があります。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
この信頼ポリシーにより、EKS は以下のことを行うことができます。
+ AWS API オペレーションを実行するロールを引き受けます。
+ 監査と追跡の目的でセッションにタグを付けます。
## 機能タイプ別のアクセス許可
必要な IAM アクセス許可は、使用している機能と現在のデプロイモデルによって異なります。
**注記**
本番稼働でのデプロイに IAM ロールセレクターと ACK を使用する場合や、AWS サービスを統合することなく kro または Argo CD を使用する場合、機能ロールには信頼ポリシー以外に IAM アクセス許可は必要ありません。
**kro (Kube Resource Orchestrator)**
必須の IAM アクセス許可はありません。ポリシーをアタッチせずに機能ロールを作成できます。kro に必要なのは Kubernetes リソースを作成および管理するための Kubernetes RBAC アクセス許可のみです。
**Kubernetes 用 AWS コントローラー (ACK)**
ACK は、2 つのアクセス許可モデルをサポートしています。
+ **シンプルなセットアップ (開発/テスト)**: AWS サービスアクセス許可を機能ロールに直接追加します。これは、使用を開始する場合、シングルアカウントでデプロイする場合、またはすべてのユーザーに同じアクセス許可が必要な場合に適しています。
+ **本番稼働のベストプラクティス**: IAM ロールセレクターを使用して最小特権のアクセスを実装します。このアプローチで機能ロールに必要なのは、サービス固有のロールを引き受ける `sts:AssumeRole` アクセス許可のみです。機能ロール自体に AWS サービスアクセス許可 (S3 や RDS など) を追加しないでください。そうしたアクセス許可は、特定の名前空間にマッピングされた個々の IAM ロールに付与します。
IAM ロールセレクターにより、以下のことを行うことができます。
+ 名前空間レベルでのアクセス許可の分離
+ クロスアカウントリソース管理
+ チームに固有の IAM ロール
+ 最小特権セキュリティモデル
IAM ロールセレクターによるアプローチでの機能ロールポリシーの例:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::111122223333:role/ACK-S3-Role",
"arn:aws:iam::111122223333:role/ACK-RDS-Role",
"arn:aws:iam::444455556666:role/ACKCrossAccountRole"
]
}
]
}
```
IAM ロールセレクターなど ACK アクセス許可の詳細な設定については、「[ACK アクセス許可を設定する](ack-permissions.md)」を参照してください。
**Argo CD**
デフォルトでは、必須の IAM アクセス許可はありません。以下のものには、オプションでアクセス許可が必要になる場合があります。
+ **AWS Secrets Manager**: Secrets Manager を使用して Git リポジトリ認証情報を保存する場合
+ **AWS CodeConnections**: Git リポジトリの認証に CodeConnections を使用する場合
Secrets Manager と CodeConnections のポリシーの例:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "arn:aws:secretsmanager:region:account-id:secret:argocd/*"
},
{
"Effect": "Allow",
"Action": [
"codeconnections:UseConnection",
"codeconnections:GetConnection"
],
"Resource": "arn:aws:codeconnections:region:account-id:connection/*"
}
]
}
```
Argo CD アクセス許可要件の詳細については、「[Argo CD に関する考慮事項](argocd-considerations.md)」を参照してください。
## 既存の機能ロールを確認する
アカウントに既にユースケースに適した機能 IAM ロールがあるかどうかを確認するには、次の手順を使用できます。
1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ロール]** を選択してください。
1. ロールのリストを検索して、機能ロール名 (`ACKCapabilityRole` や `ArgoCDCapabilityRole` など) を確認します。
1. ロールが存在する場合は、そのロールを選択して、アタッチされたポリシーおよび信頼関係を表示します。
1. **[信頼関係]** を選択し、**[信頼ポリシーの編集]** を選択してください。
1. 信頼関係が[機能信頼ポリシー](#capability-trust-policy)と一致することを確認します。一致しない場合は、信頼ポリシーを更新します。
1. **[アクセス許可]** を選択し、ロールに機能タイプとユースケースに適したアクセス許可が付与されていることを確認します。
## 機能 IAM ロールを作成する
AWS マネジメントコンソール または AWS CLI を使用して、機能ロールを作成できます。
** AWS マネジメントコンソール **
1. https://console.aws.amazon.com/iam/ で IAM コンソールを開きます。
1. [**ロール**] を選択してから [**ロールの作成**] を選びます。
1. **[信頼されたエンティティタイプ]** で、**[カスタム信頼ポリシー]** を選択します。
1. [機能信頼ポリシー](#capability-trust-policy)をコピーして、信頼ポリシーエディタに貼り付けます。
1. [**次へ**] を選択します。
1. **[アクセス許可を追加]** タブで、機能タイプに適したポリシーを選択または作成します (「[機能タイプ別のアクセス許可](#capability-permissions)」を参照)。kro では、このステップをスキップできます。
1. [**次へ**] を選択します。
1. **[ロール名]** に、`ACKCapabilityRole`、`ArgoCDCapabilityRole`、`kroCapabilityRole` などロールの一意の名前を入力します。
1. **[Description]** (説明） には`Amazon EKS - ACK capability role` のような説明文を入力してください。
1. [**ロールの作成**] を選択してください。
**AWS CLI**
1. [機能信頼ポリシー](#capability-trust-policy)を `capability-trust-policy.json` という名前のファイルにコピーします。
1. ロールを作成します。`ACKCapabilityRole` を目的のロール名で置き換えます。
```
aws iam create-role \
--role-name ACKCapabilityRole \
--assume-role-policy-document file://capability-trust-policy.json
```
1. 必要な IAM ポリシーをロールにアタッチします。ACK の場合、管理する AWS サービスのポリシーをアタッチします。Argo CD の場合、必要に応じて Secrets Manager または CodeConnections のポリシーをアタッチします。kro では、このステップをスキップできます。
ACK に S3 アクセス許可を付与した例:
```
aws iam put-role-policy \
--role-name ACKCapabilityRole \
--policy-name S3Management \
--policy-document file://s3-policy.json
```
## 機能ロールの問題をトラブルシューティングする
**機能の作成が「無効な IAM ロール」で失敗する**
以下を確認してください。
+ ロールがクラスターと同じアカウントに存在する
+ 信頼ポリシーが[機能信頼ポリシー](#capability-trust-policy)と一致する
+ ロールに `iam:PassRole` アクセス許可が付与されている
**機能でアクセス許可エラーが表示される**
以下を確認してください。
+ ロールに、機能タイプに必要な IAM アクセス許可が付与されている
+ ロールのアクセスエントリがクラスターに存在する
+ 必要に応じて追加の Kubernetes アクセス許可が設定される (「[その他の Kubernetes アクセス許可](capabilities-security.md#additional-kubernetes-permissions)」を参照)
**ACK リソースが「アクセス許可が拒否されました」というエラーで失敗する**
以下を確認してください。
+ ロールに、ユースケースに必要な IAM アクセス許可が付与されている
+ ACK コントローラーがシークレットを参照する場合、適切な名前空間に範囲が限定された `AmazonEKSSecretReaderPolicy` アクセスエントリポリシーを関連付けていることを確認します。
トラブルシューティングの詳しいガイダンスについては、「[EKS 機能のセキュリティに関する考慮事項](capabilities-security.md)」を参照してください。