**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# ConfigMap を使用して IAM ユーザーに Kubernetes へのアクセスを許可する
**重要**
`aws-auth ConfigMap` は非推奨になりました。Kubernetes API へのアクセスを管理する推奨手段については、「[EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する](access-entries.md)」を参照してください。
[IAM プリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal)を使用してクラスターにアクセスします。プリンシパルは、Amazon EKS コントロールプレーンで実行される [AWS IAM Authenticator for Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme) によって有効になります。オーセンティケーターは、その設定情報を `aws-auth` `ConfigMap` から取得します。すべての `aws-auth` `ConfigMap` 設定については、GitHub の [Full Configuration Format](https://github.com/kubernetes-sigs/aws-iam-authenticator#full-configuration-format) を参照してください。
## Amazon EKS クラスターに IAM プリンシパルを追加する
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` を作成します。
**注記**
Kubernetes のロールベースアクセスコントロール (RBAC) 設定の詳細については、Kubernetes ドキュメントの「[RBAC 認可を使用する](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)」を参照してください。
1. クラスターへのアクセスに `kubectl` が使用している認証情報を判別します。使用中のコンピュータ上で、次のコマンドを使用して、`kubectl` が使用する認証情報を判別できます。デフォルトのパスを使用しない場合は、*\$1/.kube/config* を `kubeconfig` ファイルへのパスに置き換えます。
```
cat ~/.kube/config
```
出力例は次のとおりです。
```
[...]
contexts:
- context:
cluster: my-cluster.region-code.eksctl.io
user: admin@my-cluster.region-code.eksctl.io
name: admin@my-cluster.region-code.eksctl.io
current-context: admin@my-cluster.region-code.eksctl.io
[...]
```
前述の出力例では、*admin* という名前のユーザーの認証情報が *my-cluster* という名前のクラスター用に設定されています。このユーザーがクラスターを作成したユーザーである場合は、すでにそのクラスターにアクセスできます。クラスターを作成したユーザーでない場合は、以降の手順を実行して、他の IAM プリンシパルのクラスターへのアクセスを有効にする必要があります。[IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)では、ユーザーではなくロールに許可を付与することが推奨されています。次のコマンドを使用すると、現在クラスターへのアクセスが可能な、他のプリンシパルを確認できます。
```
kubectl describe -n kube-system configmap/aws-auth
```
出力例は次のとおりです。
```
Name: aws-auth
Namespace: kube-system
Labels:
Annotations:
Data
====
mapRoles:
----
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam::111122223333:role/my-node-role
username: system:node:{{EC2PrivateDNSName}}
BinaryData
====
Events:
```
前の例は、デフォルトの `aws-auth` `ConfigMap` です。ノードインスタンスのロールだけがクラスターにアクセスできます。
1. IAM プリンシパルをマッピングできる既存の Kubernetes `roles` と `rolebindings` または `clusterroles` と `clusterrolebindings` があることを確認してください。これらのリソースの詳細については、Kubernetes ドキュメントの「[RBAC 認可を使用する](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)」を参照してください。
1. 既存の Kubernetes の `roles` または `clusterroles` を表示します。`Roles` は `namespace` スコープされ、`clusterroles` はクラスターにスコープされます。
```
kubectl get roles -A
```
```
kubectl get clusterroles
```
1. 前の出力で返された `role` または `clusterrole` の詳細を表示します。クラスター内で IAM プリンシパルに必要となる許可 (`rules`) があることを確認します。
前のコマンド出力で返された *role-name* を、`role` の名前に置き換えます。*kube-system* を、`role` の名前空間に置き換えます。
```
kubectl describe role role-name -n kube-system
```
*cluster-role-name* を、前のコマンドの出力で返された `clusterrole` 名に置き換えます。
```
kubectl describe clusterrole cluster-role-name
```
1. 既存の Kubernetes の `rolebindings` または `clusterrolebindings` を表示します。`Rolebindings` は `namespace` スコープされ、`clusterrolebindings` はクラスターにスコープされます。
```
kubectl get rolebindings -A
```
```
kubectl get clusterrolebindings
```
1. `rolebinding` または `clusterrolebinding` の詳細を表示して、前のステップで `roleRef` としてリストされた `role` または `clusterrole`、そして `subjects` にリストされたグループ名があることを確認します。
*role-binding-name* を、前のコマンドの出力で返された `rolebinding` の名前に置き換えます。*kube-system* は、`rolebinding` の `namespace` で置き換えます。
```
kubectl describe rolebinding role-binding-name -n kube-system
```
出力例は次のとおりです。
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: eks-console-dashboard-restricted-access-role-binding
namespace: default
subjects:
- kind: Group
name: eks-console-dashboard-restricted-access-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: eks-console-dashboard-restricted-access-role
apiGroup: rbac.authorization.k8s.io
```
*cluster-role-binding-name* は、前のコマンドの出力で返された `clusterrolebinding` の名前で置き換えます。
```
kubectl describe clusterrolebinding cluster-role-binding-name
```
出力例は次のとおりです。
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: eks-console-dashboard-full-access-binding
subjects:
- kind: Group
name: eks-console-dashboard-full-access-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: eks-console-dashboard-full-access-clusterrole
apiGroup: rbac.authorization.k8s.io
```
1. `aws-auth` `ConfigMap` を編集します。`eksctl` のようなツールにより `ConfigMap` を更新することができます。あるいは、手動で編集しての更新も可能です。
**重要**
`ConfigMap` の編集には、`eksctl` や、その他のツールを使用することをお勧めします。使用できる他のツールについては、Amazon EKS ベストプラクティスガイドの「[ツールを使用して aws-authConfigMap を変更する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#use-tools-to-make-changes-to-the-aws-auth-configmap)」を参照してください。`aws-auth` `ConfigMap` の形式が不適切な場合、クラスターへのアクセスが失われる場合があります。
+ [eksctl で configmap を編集する](#configmap-eksctl)ステップを表示します。
+ [configmap を手動で編集する](#configmap-manual)ステップを表示します。
### Eksctl で Configmap を編集する
1. デバイスまたは AWS CloudShell にインストールされている `eksctl` コマンドラインツールのバージョン `0.215.0` 以降が必要です。`eksctl` をインストールまたはアップグレードするには`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。
1. `ConfigMap` に現在のマッピングを表示します。*マイクラスター* の部分は自分のクラスター名に置き換えます。*region-code* を、クラスターのある AWS リージョンに置き換えます。
```
eksctl get iamidentitymapping --cluster my-cluster --region=region-code
```
出力例は次のとおりです。
```
ARN USERNAME GROUPS ACCOUNT
arn:aws:iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
```
1. ロールのマッピングを追加します。*my-role* を実際のロールの名前に置き換えます。*eks-console-dashboard-full-access-group* を、Kubernetes の `RoleBinding` または `ClusterRoleBinding` オブジェクトで指定されたグループの名前に置き換えます。*111122223333* は、ご自分のアカウント ID に置き換えます。*管理者*を任意の名前に置き換えることができます。
```
eksctl create iamidentitymapping --cluster my-cluster --region=region-code \
--arn arn:aws:iam::111122223333:role/my-role --username admin --group eks-console-dashboard-full-access-group \
--no-duplicate-arns
```
**重要**
ロールの ARN には、`role/my-team/developers/my-role` などのパスを含めることはできません。ロールの ARN は、` arn:aws:iam::111122223333:role/my-role ` のような形式にする必要があります。この例では、`my-team/developers/` を削除する必要があります。
出力例は次のとおりです。
```
[...]
2022-05-09 14:51:20 [ℹ] adding identity "{arn-aws}iam::111122223333:role/my-role" to auth ConfigMap
```
1. ユーザーのマッピングを追加します。[IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)では、ユーザーではなくロールに許可を付与することが推奨されています。*my-user* を、ご自身のユーザー名に置き換えます。*eks-console-dashboard-restricted-access-group* を、Kubernetes `RoleBinding` または `ClusterRoleBinding` オブジェクトで指定されたグループの名前に置き換えます。*111122223333* は、ご自分のアカウント ID に置き換えます。*my-user* を任意の名前に置き換えることができます。
```
eksctl create iamidentitymapping --cluster my-cluster --region=region-code \
--arn arn:aws:iam::111122223333:user/my-user --username my-user --group eks-console-dashboard-restricted-access-group \
--no-duplicate-arns
```
出力例は次のとおりです。
```
[...]
2022-05-09 14:53:48 [ℹ] adding identity "arn:aws:iam::111122223333:user/my-user" to auth ConfigMap
```
1. `ConfigMap` のマッピングを再度表示します。
```
eksctl get iamidentitymapping --cluster my-cluster --region=region-code
```
出力例は次のとおりです。
```
ARN USERNAME GROUPS ACCOUNT
arn:aws:iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
arn:aws:iam::111122223333:role/admin my-role eks-console-dashboard-full-access-group
arn:aws:iam::111122223333:user/my-user my-user eks-console-dashboard-restricted-access-group
```
### Configmap を手動で編集する
1. 編集する `ConfigMap` を開きます。
```
kubectl edit -n kube-system configmap/aws-auth
```
**注記**
「`Error from server (NotFound): configmaps "aws-auth" not found`」というエラーが表示された場合は、「[aws-auth ConfigMap をクラスターに適用する](#aws-auth-configmap)」の手順を使用して、ストック `ConfigMap` を適用します。
1. IAM プリンシパルを `ConfigMap` に追加します。IAM グループは IAM プリンシパルではないため、`ConfigMap` に追加できません。
+ **IAM ロールを (たとえば、[フェデレーティッドユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)に) 追加するには**、`ConfigMap` の `mapRoles` セクションの `data` の下にロールの詳細を追加します。ファイルに存在しない場合は、このセクションを追加します。各エントリは、次のパラメータをサポートしています。
+ **rolearn**: 追加する IAM ロールの ARN。この値にパスを含めることはできません。例えば、` arn:aws:iam::111122223333:role/my-team/developers/role-name ` のような ARN を指定することはできません。ARN は、` arn:aws:iam::111122223333:role/role-name ` のようにする必要があります。
+ **username**: IAM ロールにマッピングする Kubernetes 内のユーザー名。
+ **groups**: ロールをマップする Kubernetes グループのグループまたはリスト。グループには、デフォルトグループか、`clusterrolebinding` または `rolebinding` で指定されたグループを使用します。詳細については、Kubernetes ドキュメントの「[デフォルト Role と ClusterRoleBinding](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings)」を参照してください。
+ **IAM ユーザーを追加するには:** [IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)では、ユーザーではなくロールに許可を付与することが推奨されています。`ConfigMap` の `mapUsers` セクション (`data` の下) にユーザーの詳細を追加します。ファイルに存在しない場合は、このセクションを追加します。各エントリは、次のパラメータをサポートしています。
+ **userarn**: 追加する IAM ユーザーの ARN。
+ **username**: IAM ユーザーにマッピングする Kubernetes 内のユーザー名。
+ **groups**: ユーザーをマップする Kubernetes グループのグループまたはリスト。グループには、デフォルトグループか、`clusterrolebinding` または `rolebinding` で指定されたグループを使用します。詳細については、Kubernetes ドキュメントの「[デフォルト Role と ClusterRoleBinding](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings)」を参照してください。
1. 例えば、次の YAML ブロックには次が含まれます。
+ ノードがそれ自体をクラスターに登録できるように、`my-console-viewer-role` IAM ノードインスタンスを Kubnetes グループにマッピングしている `mapRoles` セクション。および、すべてのクラスターですべての Kubernetes リソースを表示することが可能な、Kubernetes グループにマッピングされた IAM ロール。`my-console-viewer-role` IAM ロールに必要な IAM と Kubernetes グループのアクセス許可のリストについては、「[必要なアクセス許可](view-kubernetes-resources.md#view-kubernetes-resources-permissions)」を参照してください。
+ デフォルトの AWS アカウントからの `admin` IAM ユーザーを `system:masters` Kubernetes グループにマッピングする `mapUsers` セクション。および、特定の名前空間で Kubernetes リソースを表示することが可能な、Kubernetes グループにマッピングされた、他の AWS アカウントからの `my-user` ユーザー。`my-user` IAM ユーザーに必要な IAM と Kubernetes グループのアクセス許可のリストについては、「[必要なアクセス許可](view-kubernetes-resources.md#view-kubernetes-resources-permissions)」を参照してください。
必要に応じて行を追加または削除し、すべての値の例を、実際の値で置き換えます。
```
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam::111122223333:role/my-role
username: system:node:{{EC2PrivateDNSName}}
- groups:
- eks-console-dashboard-full-access-group
rolearn: arn:aws:iam::111122223333:role/my-console-viewer-role
username: my-console-viewer-role
mapUsers: |
- groups:
- system:masters
userarn: arn:aws:iam::111122223333:user/admin
username: admin
- groups:
- eks-console-dashboard-restricted-access-group
userarn: arn:aws:iam::444455556666:user/my-user
username: my-user
```
1. ファイルを保存し、テキストエディタを終了します。
## `aws-auth` `ConfigMap` をクラスターに適用する
マネージド型ノードグループを作成するとき、または `aws-auth` を使用してノードグループを作成するときに、`ConfigMap` `eksctl` が自動的に作成され、クラスターに適用されます。これはノードをクラスターに追加するために当初作成されたものですが、この `ConfigMap` を使用して、ロールベースアクセスコントロール (RBAC) アクセスを IAM プリンシパルに追加することもできます。セルフマネージド型ノードが起動済みで、クラスターに `aws-auth` `ConfigMap` を適用していない場合は、次の手順に従って適用できます。
1. `aws-auth` `ConfigMap` が適用済みであるかどうかを確認します。
```
kubectl describe configmap -n kube-system aws-auth
```
「`Error from server (NotFound): configmaps "aws-auth" not found`」というエラーが表示された場合は、以下のステップを実行してストック `ConfigMap` を適用します。
1. AWS オーセンティケーター設定マップをダウンロード、編集、適用します。
1. 設定マップをダウンロードします。
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml
```
1. `aws-auth-cm.yaml` ファイルで、ノードに関連付けられている IAM ロールの Amazon リソースネーム (ARN) に `rolearn` を設定します。これを行うには、テキストエディタを使用するか、*my-node-instance-role* を置き換えて次のコマンドを実行します。
```
sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml
```
このファイルの他の行は変更しないでください。
**重要**
ロールの ARN には、`role/my-team/developers/my-role` などのパスを含めることはできません。ロールの ARN は、` arn:aws:iam::111122223333:role/my-role ` のような形式にする必要があります。この例では、`my-team/developers/` を削除する必要があります。
ノードグループの AWS CloudFormation スタック出力を検査し、次の値を探すことができます。
+ **InstanceRoleARN** – `eksctl` で作成されたノードグループ用
+ **NodeInstanceRole** – AWS マネジメントコンソール で、Amazon EKS で発行された AWS CloudFormation テンプレートで作成されたノードグループ用
1. 設定を適用します。このコマンドが完了するまで数分かかることがあります。
```
kubectl apply -f aws-auth-cm.yaml
```
**注記**
認可またはリソースタイプのエラーが発生した場合はトラブルシューティングトピックの「[許可されていないか、アクセスが拒否されました (`kubectl`)](troubleshooting.md#unauthorized)」を参照してください。
1. ノードのステータスを監視し、`Ready` ステータスになるまで待機します。
```
kubectl get nodes --watch
```
`Ctrl`\$1`C` を入力して、シェルプロンプトに戻ります。