Cookie の設定を選択する

当社は、当社のサイトおよびサービスを提供するために必要な必須 Cookie および類似のツールを使用しています。当社は、パフォーマンス Cookie を使用して匿名の統計情報を収集することで、お客様が当社のサイトをどのように利用しているかを把握し、改善に役立てています。必須 Cookie は無効化できませんが、[カスタマイズ] または [拒否] をクリックしてパフォーマンス Cookie を拒否することはできます。

お客様が同意した場合、AWS および承認された第三者は、Cookie を使用して便利なサイト機能を提供したり、お客様の選択を記憶したり、関連する広告を含む関連コンテンツを表示したりします。すべての必須ではない Cookie を受け入れるか拒否するには、[受け入れる] または [拒否] をクリックしてください。より詳細な選択を行うには、[カスタマイズ] をクリックしてください。

Amazon EKS で IAM を使用する方法

フォーカスモード
Amazon EKS で IAM を使用する方法 - Amazon EKS

このページの改善にご協力ください

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。

このページの改善にご協力ください

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。

IAM を使用して Amazon EKS へのアクセスを管理する前に、Amazon EKS で使用できる IAM 機能について理解しておく必要があります。Amazon EKS およびその他の AWS のサービスが IAM と連携する方法の概要を把握するにはIAM ユーザーガイド の「IAM と連携する AWS のサービス」を参照してください。

Amazon EKS のアイデンティティベースのポリシー

IAM アイデンティティベースのポリシーでは許可または拒否するアクションとリソース、またアクションを許可または拒否する条件を指定できます。Amazon EKS は特定のアクション、リソース、および条件キーをサポートしています。JSON ポリシーで使用するすべての要素については「IAM ユーザーガイド」の「IAM JSON ポリシーエレメントのリファレンス」を参照してください。

アクション

管理者は AWS JSON ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どのプリンシパルがどのリソースに対してどのような条件下でアクションを実行できるかということです。

JSON ポリシーの Action 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。ポリシーアクションの名前は通常、関連する AWS API オペレーションと同じです。一致する API オペレーションのないアクセス許可のみのアクションなど、いくつかの例外があります。また、ポリシーに複数のアクションが必要なオペレーションもあります。これらの追加アクションは依存アクションと呼ばれます。

このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。

Amazon EKS のポリシーアクションはアクションの前にプレフィックス eks: を付加します。例えば、Amazon EKS クラスターについて説明する情報を入手するアクセス許可を他のユーザーに付与するにはポリシーに DescribeCluster アクションを含めます。ポリシーステートメントにはAction または NotAction 要素を含める必要があります。

単一のステートメントに複数のアクションを指定するには次のようにコンマで区切ります。

"Action": ["eks:action1", "eks:action2"]

ワイルドカード (*) を使用して複数アクションを指定できます。例えば、Describe という単語で始まるすべてのアクションを指定するには次のアクションを含めます。

"Action": "eks:Describe*"

Amazon EKS アクションの一覧については「サービス認可リファレンス」の「Amazon Elastic Kubernetes Serviceで定義されるアクション」を参照してください。

リソース

管理者は AWS JSON ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どのプリンシパルが、どのリソースに対してどのような条件下でアクションを実行できるかということです。

Resource JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ステートメントにはResource または NotResource 要素を含める必要があります。ベストプラクティスとして、Amazon リソースネーム (ARN) を使用してリソースを指定します。これはリソースレベルの許可と呼ばれる特定のリソースタイプをサポートするアクションに対して実行できます。

オペレーションのリスト化など、リソースレベルの許可をサポートしないアクションの場合はステートメントがすべてのリソースに適用されることを表示するワイルドカード (*) を使用します。

"Resource": "*"

Amazon EKS クラスターリソースの ARN は次のようになります。

arn:aws:eks:region-code:account-id:cluster/cluster-name

ARN の形式の詳細については「Amazon リソースネーム (ARN) と AWS のサービスの名前空間」を参照してください。

例えば、ステートメントで マイクラスター という名前のクラスターを指定するには次の ARN を使用します。

"Resource": "arn:aws:eks:region-code:111122223333:cluster/my-cluster"

特定のアカウントと AWS リージョンに属するすべてのクラスターを指定するにはワイルドカード (*) を使用します。

"Resource": "arn:aws:eks:region-code:111122223333:cluster/*"

リソースの作成を含む、一部の Amazon EKS アクションは特定のリソースで実行できません。このような場合はワイルドカード *を使用する必要があります。

"Resource": "*"

Amazon EKS リソースタイプとその ARN の一覧については「サービス認可リファレンス」の「Amazon Elastic Kubernetes Service で定義されるリソース」を参照してください。各リソースの ARN を、どのアクションで指定できるかについては「Amazon Elastic Kubernetes Service で定義されるアクション」を参照してください。

条件キー

Amazon EKS では独自の条件キーが定義されており、また一部のグローバル条件キーの使用がサポートされています。すべての AWS グローバル条件キーを確認するには、IAM ユーザーガイドの「AWS グローバル条件コンテキストキー」を参照してください。

OpenID Connect プロバイダーをクラスターに関連付ける場合に条件キーを設定できます。詳細については、「IAM ポリシーの例」を参照してください。

すべての Amazon EC2 アクションは aws:RequestedRegion および ec2:Region 条件キーをサポートします。詳細については「例: 特定の AWS リージョンへのアクセスの制限」を参照してください。

Amazon EKS 条件キーのリストについては「サービス認可リファレンス」の「Amazon Elastic Kubernetes Service によって定義された条件」を参照してください。条件キーを使用できるアクションとリソースについては「Amazon Elastic Kubernetes Service で定義されるアクション」を参照してください。

Amazon EKS でのアイデンティティベースのポリシーの例は「Amazon EKS でのアイデンティティベースのポリシーの例」でご確認ください。

Amazon EKS クラスターを作成すると、このクラスターを作成する IAM プリンシパルには、Amazon EKS コントロールプレーンのクラスターロールベースアクセスコントロール (RBAC) 設定で、system:masters 許可が自動的に付与されます。このプリンシパルは表示可能な設定の中には表示されません。したがって、どのプリンシパルが最初にクラスターを作成したのかを追跡する必要があります。追加の IAM プリンシパルがクラスターとインタラクションできるようにするには Kubernetes 内の aws-auth ConfigMap を編集し、aws-auth ConfigMap で指定した group の名前を使用して、Kubernetes rolebinding または clusterrolebinding を作成します。

ConfigMap の使用に関する詳細については「IAM ユーザーおよびロールに Kubernetes API へのアクセスを付与する」を参照してください。

Amazon EKS でのリソースベースのポリシー

Amazon EKS では リソースベースのポリシーはサポートされていません。

Amazon EKS タグに基づいた認可

タグは Amazon EKS リソースにアタッチすることも、Amazon EKS へのリクエストの際に渡すこともできます。タグに基づいてアクセスを制御するにはaws:ResourceTag/key-name aws:RequestTag/key-name 、または aws:TagKeys の条件キーを使用して、ポリシーの条件要素でタグ情報を提供します。Amazon EKS リソースのタグ付けの詳細については「タグを使用して Amazon EKS リソースを整理する」を参照してください。条件キーでタグを使用できるアクションの詳細については「Service Authorization Reference」(サービス認可のリファレンス) の「Amazon EKS で定義されたアクション」を参照してください。

Amazon EKS でのIAM 役割

IAM 役割 は特定のアクセス許可を持つ、AWS アカウント内のエンティティです。

Amazon EKS での一時的な認証情報の使用

一時的な認証情報を使用して、フェデレーションでサインインする、IAM 役割を引き受ける、またはクロスアカウント役割を引き受けることができます。一時的なセキュリティ認証情報を取得するにはAssumeRole または GetFederationToken などの AWS STS API オペレーションを呼び出します。

Amazon EKS では一時認証情報が使用できます。

サービスにリンクされた役割

link:IAM/latest/UserGuide/id_roles.html#iam-term-service-linked-role[Service-linked roles,type="documentation"] allow {aws} services to access resources in other services to complete an action on your behalf. Service-linked roles appear in your IAM account and are owned by the service. An administrator can view but can't edit the permissions for service-linked roles.

Amazon EKS はサービスにリンクされた役割をサポートしています。Amazon EKS でのサービスにリンクされた役割の作成または管理の詳細については「Amazon EKS でのサービスにリンクされたロールの使用」を参照してください。

サービス役割

この機能により、ユーザーに代わってサービスがサービス役割を引き受けることが許可されます。この役割により、サービスがお客様に代わって他のサービスのリソースにアクセスし、アクションを完了することが許可されます。サービス役割はIAM アカウントに表示され、アカウントによって所有されます。つまり、IAM 管理者はこの役割の権限を変更できます。ただし、これを行うことにより、サービスの機能が損なわれる場合があります。

Amazon EKS ではサービス役割がサポートされています。詳細についてはAmazon EKS クラスター の IAM ロールおよびAmazon EKS ノードの IAM ロールを参照してください。

Amazon EKS での IAM 役割の選択

Amazon EKS でクラスターリソースを作成する場合は他のいくつかの AWS リソースに Amazon EKS が自動的にアクセスすることを許可するための役割を、ユーザーが選択する必要があります。以前に作成したサービス役割がある場合、Amazon EKS により、選択できる役割のリストが提示されます。Amazon EKS 管理のポリシーがアタッチされた役割を選択することが重要です。詳細については既存のクラスターロールの確認および既存のノードロールの確認を参照してください。

プライバシーサイト規約Cookie の設定
© 2025, Amazon Web Services, Inc. or its affiliates.All rights reserved.