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

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

# アクセスエントリを作成する
<a name="creating-access-entries"></a>

アクセスエントリを作成する前に、次の点を考慮してください：
+ 適切に設定された認証モード。「[アクセスエントリを使用するように認証モードを変更する](setting-up-access-entries.md)」を参照してください。
+ アクセスエントリには1 つだけの既存の IAM プリンシパルの Amazon リソースネーム (ARN) が含まれます。IAM プリンシパルは複数のアクセスエントリに含めることはできません。指定する ARN に関するその他の考慮事項
  + IAM のベストプラクティスでは長期認証情報を持つ IAM ユーザーではなく、短期認証情報を持つ IAM ロールを使用してクラスターにアクセスすることを推奨しています。詳細は「*IAM ユーザーガイド*」の「[人間のユーザーが一時的な認証情報を使用して AWS にアクセスするにはID プロバイダーとのフェデレーションの使用が必要です](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。
  + ARN が IAM ロール用の場合はパスを含めることができます。`aws-auth` `ConfigMap` エントリの ARN にはパスを含めることはできません。例えば、ARN は ` arn:aws:iam::<111122223333>:role/<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 はそれをアクセスエントリとともに保存します。
+ 各アクセスエントリには*タイプ*があります。アクセスエントリの種類は関連付けられているリソースの種類によって異なり、アクセス許可を定義しません。タイプを指定しない場合、Amazon EKS は自動的にタイプを `STANDARD` に設定します。
  +  `EC2_LINUX` - Linux または Bottlerocket セルフマネージド型ノードで使用される IAM ロール用
  +  `EC2_WINDOWS` - Windows セルフマネージドノードで使用される IAM ロール用
  +  `FARGATE_LINUX` - AWS Fargate (Fargate) で使用される IAM ロール用
  +  `HYBRID_LINUX` - ハイブリッドノードで使用される IAM ロール用
  +  `STANDARD` - 指定しない場合のデフォルトタイプ
  +  `EC2` - EKS Auto Mode カスタムノードクラス用。詳細については、「[ノードクラスのアクセスエントリを作成する](create-node-class.md#auto-node-access-entry)」を参照してください。
  + アクセスエントリの作成後にタイプを変更することはできません。
+ マネージドノードグループまたは Fargate プロファイルに使用される IAM ロールのアクセスエントリを作成する必要はありません。EKS はアクセス エントリを作成するか (有効な場合)、認証構成マップを更新します (アクセス エントリが利用できない場合)。
+ アクセスエントリのタイプが `STANDARD` の場合、アクセスエントリのユーザー名を指定できます。ユーザー名の値を指定しない場合、Amazon EKS はアクセスエントリのタイプと、指定した IAM プリンシパルが IAM ロールか IAM ユーザーかに応じて、以下のいずれかの値を設定します。独自のユーザー名を指定する特別な理由がない限り、ユーザー名を指定せず、Amazon EKS に自動生成させることをお勧めします。独自のユーザー名を指定する場合:
  + `system:`、`eks:`、`aws:`、`amazon:`、または `iam:` で始めることはできません。
  + ユーザー名が IAM ロール用の場合は、ユーザー名の末尾に `{{SessionName}}` または `{{SessionNameRaw}}` を追加することをお勧めします。ユーザー名に `{{SessionName}}` または `{{SessionNameRaw}}` を追加する場合、ユーザー名の \$1\$1SessionName\$1\$1 の*前*にコロンを含める必要があります。このロールを引き受けると、ロールを引き受けるときに指定された AWS STS セッションの名前が自動的にクラスターに渡され、CloudTrail ログに表示されます。例えば、`john{{SessionName}}` というユーザー名にはできません。ユーザー名は `:john{{SessionName}}` または `jo:hn{{SessionName}}` でなければなりません。コロンは `{{SessionName}}` の前になければいけません。次の表の Amazon EKS によって生成されたユーザー名には ARN が含まれています。ARN にはコロンが含まれているため、この要件を満たしています。ユーザー名に `{{SessionName}}` を含めなければ、コロンは不要です。`{{SessionName}}` の場合、セッション名の特殊文字「@」は「-」に置き換えられます。`{{SessionNameRaw}}` の場合、セッション名の特殊文字はすべて保持されます。    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/creating-access-entries.html)

    アクセスエントリの作成後にユーザー名を変更することができます。
+ アクセスエントリのタイプが `STANDARD` で、Kubernetes RBAC 認可を使用する場合はアクセスエントリに 1 つ以上の*グループ名*を追加できます。アクセスエントリを作成したら、グループ名を追加および削除できます。IAM プリンシパルがクラスター上の Kubernetes オブジェクトにアクセスできるようにするには Kubernetes ロールベース認可 (RBAC) オブジェクトを作成して管理する必要があります。クラスター上で Kubernetes `RoleBinding` または `ClusterRoleBinding` オブジェクトを作成し、`kind: Group` の `subject` としてグループ名を指定します。Kubernetes は、Kubernetes `Role` で指定したクラスターオブジェクト、またはバインディングの `roleRef` でも指定した `ClusterRole` オブジェクトへの IAM プリンシパルアクセスを許可します。グループ名を指定する場合は、Kubernetes ロールベース認可 (RBAC) オブジェクトについて理解しておくことをお勧めします。詳細についてはKubernetes ドキュメントの「[RBAC 認可を使用する](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)」を参照してください。
**重要**  
Amazon EKS はクラスターに存在する Kubernetes RBAC オブジェクトに、指定したグループ名が含まれていることを確認しません。例えば、現時点で存在しないグループのアクセス エントリを作成すると、EKS はエラーを返す代わりにグループを作成します。

  クラスター上の Kubernetes オブジェクトに IAM プリンシパルがアクセスするのを許可する Kubernetes の代わりに、またはそれに加えて、Amazon EKS *アクセスポリシー*をアクセスエントリに関連付けることができます。Amazon EKS はIAM プリンシパルがアクセスポリシーのアクセス許可を使用してクラスター上の Kubernetes オブジェクトにアクセスすることを許可します。アクセスポリシーのアクセス許可の範囲は指定した Kubernetes 名前空間に限定できます。アクセスポリシーを使用する場合、Kubernetes RBAC オブジェクトを管理する必要はありません。詳細については、「[アクセスポリシーをアクセスエントリに関連付ける](access-policies.md)」を参照してください。
+ タイプが `EC2_LINUX` または `EC2_Windows` のアクセスエントリを作成する場合、アクセスエントリを作成する IAM プリンシパルには `iam:PassRole` アクセス許可が必要です。詳細については「*IAM ユーザーガイド*」の「[AWS サービスにロールを渡す許可をユーザーに付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html)」を参照してください。
+ 標準的な [IAM 動作](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency)と同様に、アクセスエントリの作成と更新は最終的には一貫性があり、最初の API コールが正常に戻ってから有効になるまでに数秒かかる場合があります。発生する可能性のあるこれらの遅延を考慮して、アプリケーションを設計する必要があります。アプリケーションの重要で高可用性のコードパスにはアクセスエントリの作成や更新を含めないことをお勧めします。代わりに、実行頻度が低い別の初期化またはセットアップルーチンに の変更を加えます。また、本番稼働ワークフローが依存する前に、変更が伝達済みであることを確認します。
+ アクセスエントリは[サービスリンクロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html)をサポートしていません。プリンシパル ARN がサービスリンクロールである場合、アクセスエントリを作成することはできません。サービスリンクロールは` arn:aws:iam::*:role/aws-service-role/*` 形式の ARN によって識別できます。

AWS マネジメントコンソール または AWS CLI を使用してアクセスエントリを作成できます。

## AWS マネジメントコンソール
<a name="access-create-console"></a>

1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。

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

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

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

1. **IAM プリンシパル**には既存の IAM ロールまたはユーザーを選択してください。IAM のベストプラクティスでは長期認証情報を持つ IAM ユーザーではなく、短期認証情報を持つ IAM ロールを使用してクラスターにアクセスすることを推奨しています。詳細は「*IAM ユーザーガイド*」の「[人間のユーザーが一時的な認証情報を使用して AWS にアクセスするにはID プロバイダーとのフェデレーションの使用が必要です](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。

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

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

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

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

1. [**次へ**] を選択します。

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

   1. **[ポリシー名]** にはアクセスポリシーを選択してください。アクセスポリシーのアクセス許可は表示できませんが、Kubernetes ユーザー向け `ClusterRole` オブジェクトと同様のアクセス許可が含まれています。詳細については、Kubernetes ドキュメントの「[ユーザー向け Role](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)」を参照してください。

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

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

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

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

## AWS CLI
<a name="access-create-cli"></a>

1. AWS コマンドラインインターフェイスユーザーガイドの「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」の説明に従って、AWS CLI をインストールします。

1. アクセスエントリを作成するには以下のいずれかの例を使用してアクセスエントリを作成できます：
   + セルフマネージド型 Amazon EC2 Linux ノードグループのアクセスエントリを作成します。*マイクラスター* はクラスターの名前、*111122223333* は自分の AWS アカウント ID に、*EKS-マイクラスター-self-managed-ng-1* は[ノード IAM ロール](create-node-role.md)の名前に置き換えます。ノードグループが Windows ノードグループの場合は *EC2\$1LINUX* を `EC2_Windows` に置き換えてください。

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

     `STANDARD` 以外のタイプを指定する場合、`--kubernetes-groups` オプションは使用できません。タイプが `STANDARD` 以外の値であるため、このアクセスエントリにアクセスポリシーを関連付けることはできません。
   + Amazon EC2 セルフマネージド型ノードグループには使用されていない IAM ロールを許可するアクセスエントリを作成し、Kubernetes にクラスターへのアクセスを許可してもらいます。*マイクラスター* をクラスターの名前に、*111122223333* を AWS アカウント ID に、*my-role* を IAM ロールの名前に置き換えます。*Viewers* はクラスター上の Kubernetes `RoleBinding` または `ClusterRoleBinding` オブジェクトで指定したグループの名前に置き換えます。

     ```
     aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role --type STANDARD --user Viewers --kubernetes-groups Viewers
     ```
   + IAM ユーザーがクラスターに対して認証できるようにするアクセスエントリを作成します。これも可能であるためこの例が示されていますが、IAM のベストプラクティスでは長期認証情報を持つ IAM ユーザーではなく、短期認証情報を持つ IAM ロールを使用してクラスターにアクセスすることを推奨しています。詳細は「*IAM ユーザーガイド*」の「[人間のユーザーが一時的な認証情報を使用して AWS にアクセスするにはID プロバイダーとのフェデレーションの使用が必要です](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。

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

     このユーザーに Kubernetes API ディスカバリーロールのアクセス許可よりも多くのクラスターへのアクセスを許可したい場合は `--kubernetes-groups` オプションが使用されていないため、アクセスエントリにアクセスポリシーを関連付ける必要があります。詳細については、「[アクセスポリシーをアクセスエントリに関連付ける](access-policies.md)」と Kubernetes ドキュメントの「[APIディスカバリーロール](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#discovery-roles)」を参照してください。