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

考慮事項

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

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

• アクセスエントリには、1 つだけの既存の IAM プリンシパルの Amazon リソースネーム (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 が表示されない場合でも、Amazon EKS はそれをアクセスエントリとともに保存します。

• 各アクセスエントリにはタイプがあります。EC2 Linux (Linux または Bottlerocket のセルフマネージド型ノードで使用される IAM ロールの場合)、EC2 Windows (Windows のセルフマネージド型ノードで使用される IAM ロールの場合)、FARGATE_LINUX (AWS Fargate で使用される IAM ロールの場合)、またはSTANDARD をタイプとして指定できます。タイプを指定しない場合、Amazon EKS は自動的にタイプを STANDARD に設定します。マネージド型ノードグループや Fargate プロファイルに使用される IAM ロールのアクセスエントリを作成する必要はありません。Amazon EKS は、クラスターのプラットフォームバージョンに関係なくこれらのロールのエントリを aws-auth ConfigMap に追加するためです。

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

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

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

  • ユーザー名が IAM ロール用の場合は、ユーザー名の末尾に {{SessionName}} を追加することをお勧めします。ユーザー名に {{SessionName}} を追加する場合、ユーザー名の {{SessionName}} の前にコロンを含める必要があります。このロールを引き受けると、ロールを引き受けるときに指定されたセッションの名前が自動的にクラスターに渡され、CloudTrail ログに表示されます。例えば、john{{SessionName}} というユーザー名にはできません。ユーザー名は :john{{SessionName}} または jo:hn{{SessionName}} でなければなりません。コロンは {{SessionName}} の前になければいけません。次の表の Amazon EKS によって生成されたユーザー名には ARN が含まれています。ARN にはコロンが含まれているため、この要件を満たしています。ユーザー名に {{SessionName}} を含めなければ、コロンは不要です。

  IAM プリンシパルタイプ	タイプ	Amazon EKS が自動的に設定するユーザー名の値
  ユーザー	STANDARD	ユーザーの ARN。例：arn:aws:iam::111122223333:user/my-user
  ロール	STANDARD	想定されるロールの STS ARN。Amazon EKS では、{{SessionName}} がロールに追加されます。 例：arn:aws:sts::111122223333:assumed-role/my-role/{{SessionName}} 指定したロールの ARN にパスが含まれている場合、Amazon EKS は生成されたユーザー名からそのパスを削除します。
  ロール	EC2 Linux、または EC2 Windows	system:node:{{EC2PrivateDNSName}}
  ロール	FARGATE_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 認証の使用」を参照してください。

  重要

  Amazon EKS は、クラスターに存在する Kubernetes RBAC オブジェクトに、指定したグループ名が含まれていることを確認しません。

  クラスター上の Kubernetes オブジェクトに IAM プリンシパルがアクセスするのを許可する Kubernetes の代わりに、またはそれに加えて、Amazon EKS アクセスポリシーをアクセスエントリに関連付けることができます。Amazon 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 によって識別できます。