アクセスエントリを作成する - アマゾン EKS
AWS Management ConsoleAWS CLI

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

本ユーザーガイドの改善にご協力いただけませんか? すべてのページの右側のペインにある GitHub リンクで、このページの編集を選択してください。皆さまにご協力いただくことで、あらゆる人々に使いやすいユーザーガイドになります。

アクセスエントリを作成する

アクセスエントリを作成する前に、次の点を考慮してください：

  • 適切に設定された認証モード。「アクセスエントリを使用するように認証モードを変更する」を参照してください。

  • アクセスエントリには1 つだけの既存の IAM プリンシパルの アマゾン リソースネーム (ARN) が含まれます。IAM プリンシパルは複数のアクセスエントリに含めることはできません。指定する ARN に関するその他の考慮事項

    • IAM のベストプラクティスでは長期認証情報を持つ IAM ユーザーではなく、短期認証情報を持つ IAM ロールを使用してクラスターにアクセスすることを推奨しています。詳細は「IAM ユーザーガイド」の「人間のユーザーが一時的な認証情報を使用して AWS にアクセスするにはID プロバイダーとのフェデレーションの使用が必要です」を参照してください。

    • ARN が IAM ロール用の場合はパスを含めることができます。aws-auth ConfigMap エントリの ARN にはパスを含めることはできません。例えば、ARN は arn:aws:iam::<111122223333>:role/<development/apps/my-role> または arn:aws:iam::<111122223333>:role/<my-role> にすることができます。

    • アクセスエントリのタイプが STANDARD 以外の場合 (タイプに関する次の考慮事項を参照)、ARN はクラスターと同じ AWS アカウントにある必要があります。タイプが STANDARD の場合、ARN はクラスターが属するアカウントと同じ、または異なる AWS アカウントでもかまいません。

    • アクセスエントリの作成後に IAM プリンシパルを変更することはできません。

    • この ARN を含む IAM プリンシパルを削除しても、アクセスエントリは自動的に削除されません。削除する IAM プリンシパルの ARN を含むアクセスエントリを削除することをお勧めします。アクセスエントリを削除せず、IAM プリンシパルを再作成すると、同じ ARN があっても、アクセスエントリは機能しません。これは再作成された IAM プリンシパルの ARN は同じですが、再作成された IAM プリンシパルの roleID または userID (aws sts get-caller-identity AWS CLI コマンドで確認できます) は元の IAM プリンシパルの ARN とは異なるためです。アクセスエントリの IAM プリンシパルの roleID または userID が表示されない場合でも、アマゾン EKS はそれをアクセスエントリとともに保存します。

  • 各アクセスエントリにはタイプがあります。EC2_LINUX (リナックス または Bottlerocket のセルフマネージド型ノードで使用される IAM ロールの場合)、EC2_Windows (Windows のセルフマネージド型ノードで使用される IAM ロールの場合)、FARGATE_LINUX (AWS Fargate (Fargate で使用される IAM ロールの場合)、HYBRID_LINUX (ハイブリッドノードで使用される IAM ロールの場合)、または STANDARD をタイプとして指定できます。タイプを指定しない場合、アマゾン EKS は自動的にタイプを STANDARD に設定します。マネージドノードグループまたは Fargate プロファイルに使用される IAM ロールのアクセスエントリを作成する必要はありません。EKS はアクセス エントリを作成するか (有効な場合)、認証構成マップを更新します (アクセス エントリが利用できない場合)。

    アクセスエントリの作成後にタイプを変更することはできません。

  • アクセスエントリのタイプが STANDARD の場合、アクセスエントリのユーザー名を指定できます。ユーザー名の値を指定しない場合、アマゾン EKS はアクセスエントリのタイプと、指定した IAM プリンシパルが IAM ロールか IAM ユーザーかに応じて、以下のいずれかの値を設定します。独自のユーザー名を指定する特別な理由がない限り、ユーザー名を指定せず、アマゾン EKS に自動生成させることをお勧めします。独自のユーザー名を指定する場合:

    • system:、eks:、aws:、amazon:、または iam: で始めることはできません。

    • ユーザー名が IAM ロール用の場合はユーザー名の末尾に {{SessionName}} を追加することをお勧めします。ユーザー名に {{SessionName}} を追加する場合、ユーザー名の {{SessionName}} の前にコロンを含める必要があります。このロールを引き受けると、ロールを引き受けるときに指定されたセッションの名前が自動的にクラスターに渡され、クラウドTrail ログに表示されます。例えば、john{{SessionName}} というユーザー名にはできません。ユーザー名は :john{{SessionName}} または jo:hn{{SessionName}} でなければなりません。コロンは {{SessionName}} の前になければいけません。次の表の アマゾン EKS によって生成されたユーザー名には ARN が含まれています。ARN にはコロンが含まれているため、この要件を満たしています。ユーザー名に {{SessionName}} を含めなければ、コロンは不要です。セッション名では特殊文字「@」が「-」に置き換えられることに注意してください。

      IAM プリンシパルタイプ タイプ アマゾン EKS が自動的に設定するユーザー名の値

      ユーザー

      STANDARD

      ユーザーの ARN。例： arn:aws:iam::<111122223333>:user/<my-user>

      ロール

      STANDARD

      想定されるロールの STS ARN。アマゾン EKS では{{SessionName}} がロールに追加されます。

      例： arn:aws:sts::<111122223333>:assumed-role/<my-role>/{{SessionName}}

      指定したロールの ARN にパスが含まれている場合、アマゾン EKS は生成されたユーザー名からそのパスを削除してください。

      ロール

      EC2_LINUX、または EC2_Windows

      system:node:{{EC2PrivateDNSName}}

      ロール

      FARGATE_LINUX

      system:node:{{SessionName}}

      ロール

      HYBRID_LINUX

      system:node:{{SessionName}}

      アクセスエントリの作成後にユーザー名を変更することができます。

  • アクセスエントリのタイプが STANDARD で、Kubernetes RBAC 認可を使用する場合はアクセスエントリに 1 つ以上のグループ名を追加できます。アクセスエントリを作成したら、グループ名を追加および削除できます。IAM プリンシパルがクラスター上の Kubernetes オブジェクトにアクセスできるようにするにはKubernetes ロールベース認可 (RBAC) オブジェクトを作成して管理する必要があります。クラスター上に Kubernetes RoleBinding または ClusterRoleBinding を作成し、グループ名を kind: Group の subject として指定します。Kubernetes はバインディングの roleRef でも指定した Kubernetes Role または ClusterRole オブジェクトで指定したすべてのクラスターオブジェクトにアクセスすることを IAM プリンシパルに許可します。グループ名を指定する場合はKubernetes ロールベース認可 (RBAC) オブジェクトについて理解しておくことをお勧めします。詳細についてはKubernetes ドキュメントの「RBAC 認証の使用」を参照してください。

    重要

    アマゾン EKS はクラスターに存在する Kubernetes RBAC オブジェクトに、指定したグループ名が含まれていることを確認しません。たとえば、現在存在しないグループのアクセス エントリを作成すると、EKS はエラーを返す代わりにグループを作成します。

    クラスター上の Kubernetes オブジェクトに IAM プリンシパルがアクセスするのを許可する Kubernetes の代わりに、またはそれに加えて、アマゾン EKS アクセスポリシーをアクセスエントリに関連付けることができます。アマゾン EKS はIAM プリンシパルがアクセスポリシーのアクセス許可を使用してクラスター上の Kubernetes オブジェクトにアクセスすることを許可します。アクセスポリシーのアクセス許可の範囲は指定した Kubernetes 名前空間に限定できます。アクセスポリシーを使用する場合、Kubernetes RBAC オブジェクトを管理する必要はありません。詳細については「アクセスポリシーをアクセスエントリに関連付ける」を参照してください。

  • タイプが EC2_LINUX または EC2_Windows のアクセスエントリを作成する場合、アクセスエントリを作成する IAM プリンシパルには iam:PassRole アクセス許可が必要です。詳細については「IAM ユーザーガイド」の「AWS サービスにロールを渡す許可をユーザーに付与する」を参照してください。

  • 標準的な IAM 動作と同様に、アクセスエントリの作成と更新は最終的には一貫性があり、最初の API コールが正常に戻ってから有効になるまでに数秒かかる場合があります。発生する可能性のあるこれらの遅延を考慮して、アプリケーションを設計する必要があります。アプリケーションの重要で高可用性のコードパスにはアクセスエントリの作成や更新を含めないことをお勧めします。代わりに、実行頻度が低い別の初期化またはセットアップルーチンに の変更を加えます。また、本番稼働ワークフローが依存する前に、変更が伝達済みであることを確認します。

  • アクセスエントリはサービスリンクロールをサポートしていません。プリンシパル ARN がサービスリンクロールである場合、アクセスエントリを作成することはできません。サービスリンクロールは arn:aws:iam::*:role/aws-service-role/* 形式の ARN によって識別できます。

AWS Management Console または AWS CLI を使用してアクセスエントリを作成できます。

AWS Management Console

  1. アマゾン EKS コンソールを開きます。

  2. アクセスエントリを作成するクラスターの名前を選択してください。

  3. [リモートアクセス] タブを選択してください。

  4. [アクセスエントリの作成] を選択してください。

  5. IAM プリンシパルには既存の IAM ロールまたはユーザーを選択してください。IAM のベストプラクティスでは長期認証情報を持つ IAM ユーザーではなく、短期認証情報を持つ IAM ロールを使用してクラスターにアクセスすることを推奨しています。詳細は「IAM ユーザーガイド」の「人間のユーザーが一時的な認証情報を使用して AWS にアクセスするにはID プロバイダーとのフェデレーションの使用が必要です」を参照してください。

  6. [タイプ] で、アクセスエントリがセルフマネージド型の アマゾン EC2 ノードに使用されるノードロール用のものである場合は[EC2 リナックス] または [EC2 Windows] を選択してください。それ以外の場合はデフォルト (標準) をそのまま使用します。

  7. 選択した タイプが標準で、ユーザー名を指定する場合はユーザー名を入力します。

  8. 選択したタイプが標準で、IAM プリンシパルに Kubernetes RBAC 認可を使用したい場合はグループに 1 つ以上の名前を指定します。グループ名を指定せず、アマゾン EKS 認可を使用する場合は後のステップで、またはアクセスエントリの作成後にアクセスポリシーを関連付けることができます。

  9. (オプション) [タグ] ではアクセスエントリにラベルを割り当てます。例えば、同じタグを持つすべてのリソースを検索しやすくするためです。

  10. [ 次へ] を選択してください。

  11. [アクセスポリシーの追加] ページで、選択したタイプが標準で、アマゾン EKS が IAM プリンシパルにクラスター上の Kubernetes オブジェクトへのアクセス許可を与えることを許可する場合は次のステップを実行してください。それ以外の場合は[次へ] を選択してください。

    1. [ポリシー名] にはアクセスポリシーを選択してください。アクセスポリシーのアクセス許可は表示できませんが、Kubernetes ユーザー向け ClusterRole オブジェクトと同様のアクセス許可が含まれています。詳細についてはKubernetes ドキュメントの「ユーザー向けロール」を参照してください。

    2. 以下のオプションのいずれかを選択してください：

      • クラスター — アマゾン EKS が IAM プリンシパルに、クラスター上のすべての Kubernetes オブジェクトのアクセスポリシー内のアクセス許可があるように承認する場合はこのオプションを選択してください。

      • Kubernetes 名前空間 — アマゾン EKS が IAM プリンシパルに、クラスター上の特定の Kubernetes 名前空間のすべての Kubernetes オブジェクトのアクセスポリシー内のアクセス許可があるように承認する場合はこのオプションを選択してください。[名前空間]にはクラスター上の Kubernetes 名前空間の名前を入力します。名前空間をさらに追加する場合は[新しい名前空間を追加する] を選択し、名前空間名を入力します。

    3. ポリシーを追加するには[ポリシーを追加] を選択してください。ポリシーごとに異なる範囲を設定できますが、各ポリシーは 1 回しか追加できません。

    4. [ 次へ] を選択してください。

  12. アクセスエントリの設定を確認してください。何かが正しくないと思われる場合は[戻る] を選択してステップに戻り、エラーを修正します。設定が正しければ、[作成] を選択してください。

AWS CLI

  1. AWS コマンドラインインターフェイスユーザーガイドの「インストール」の説明に従って、AWS CLI をインストールします。

  2. アクセスエントリを作成するには以下のいずれかの例を使用してアクセスエントリを作成できます：

    • セルフマネージド型 アマゾン EC2 リナックス ノードグループのアクセスエントリを作成します。マイクラスター はクラスターの名前、111122223333 は自分の AWS アカウント ID に、EKS-マイクラスター-self-managed-ng-1 はノード IAM ロールの名前に置き換えます。ノードグループが Windows ノードグループの場合はEC2_リナックス を EC2_Windows に置き換えてください。

      aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 --type EC2_LINUX

      STANDARD 以外のタイプを指定する場合、--kubernetes-groups オプションは使用できません。タイプが STANDARD 以外の値であるため、このアクセスエントリにアクセスポリシーを関連付けることはできません。

    • アマゾン EC2 セルフマネージド型ノードグループには使用されていない IAM ロールを許可するアクセスエントリを作成し、Kubernetes にクラスターへのアクセスを許可してもらいます。マイクラスター をクラスターの名前に、111122223333 を AWS アカウント ID に、my-role を IAM ロールの名前に置き換えます。Viewers はクラスター上の Kubernetes RoleBinding または ClusterRoleBinding オブジェクトで指定したグループの名前に置き換えます。

      aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role --type STANDARD --user Viewers --kubernetes-groups Viewers

    • IAM ユーザーがクラスターに対して認証できるようにするアクセスエントリを作成します。これも可能であるためこの例が示されていますが、IAM のベストプラクティスでは長期認証情報を持つ IAM ユーザーではなく、短期認証情報を持つ IAM ロールを使用してクラスターにアクセスすることを推奨しています。詳細は「IAM ユーザーガイド」の「人間のユーザーが一時的な認証情報を使用して AWS にアクセスするにはID プロバイダーとのフェデレーションの使用が必要です」を参照してください。

      aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:user/my-user --type STANDARD --username my-user

      このユーザーに Kubernetes API ディスカバリーロールのアクセス許可よりも多くのクラスターへのアクセスを許可したい場合は--kubernetes-groups オプションが使用されていないため、アクセスエントリにアクセスポリシーを関連付ける必要があります。詳細については「アクセスポリシーをアクセスエントリに関連付ける」と Kubernetes ドキュメントの「API ディスカバリーロール」を参照してください。