このページの改善にご協力ください
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。
ConfigMap を使用して IAM ユーザーに Kubernetes へのアクセスを許可する
重要
aws-auth ConfigMap は非推奨になりました。Kubernetes API へのアクセスを管理する推奨手段については、「EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する」を参照してください。
IAM プリンシパルを使用してクラスターにアクセスします。プリンシパルは、Amazon EKS コントロールプレーンで実行される AWS IAM Authenticator for Kubernetesaws-auth ConfigMap から取得します。すべての aws-auth ConfigMap 設定については、GitHub の Full Configuration Format
Amazon EKS クラスターに IAM プリンシパルを追加する
Amazon EKS クラスターを作成すると、このクラスターを作成する IAM プリンシパルには、Amazon EKS コントロールプレーンのクラスターロールベースアクセスコントロール (RBAC) 設定で、system:masters 許可が自動的に付与されます。このプリンシパルは表示可能な設定の中には表示されません。したがって、どのプリンシパルが最初にクラスターを作成したのかを追跡する必要があります。追加の IAM プリンシパルがクラスターとインタラクションできるようにするには Kubernetes 内の aws-auth ConfigMap を編集し、aws-auth ConfigMap で指定した group の名前を使用して、Kubernetes rolebinding または clusterrolebinding を作成します。
注記
Kubernetes のロールベースアクセスコントロール (RBAC) 設定の詳細については、Kubernetes ドキュメントの「RBAC 認可を使用する
-
クラスターへのアクセスに
kubectlが使用している認証情報を判別します。使用中のコンピュータ上で、次のコマンドを使用して、kubectlが使用する認証情報を判別できます。デフォルトのパスを使用しない場合は、~/.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 のベストプラクティスでは、ユーザーではなくロールに許可を付与することが推奨されています。次のコマンドを使用すると、現在クラスターへのアクセスが可能な、他のプリンシパルを確認できます。kubectl describe -n kube-system configmap/aws-auth出力例は次のとおりです。
Name: aws-auth Namespace: kube-system Labels: <none> Annotations: <none> Data ==== mapRoles: ---- - groups: - system:bootstrappers - system:nodes rolearn: arn:aws:iam::111122223333:role/my-node-role username: system:node:{{EC2PrivateDNSName}} BinaryData ==== Events: <none>
前の例は、デフォルトの
aws-authConfigMapです。ノードインスタンスのロールだけがクラスターにアクセスできます。 -
IAM プリンシパルをマッピングできる既存の Kubernetes
rolesとrolebindingsまたはclusterrolesとclusterrolebindingsがあることを確認してください。これらのリソースの詳細については、Kubernetes ドキュメントの「RBAC 認可を使用する」を参照してください。 -
既存の Kubernetes の
rolesまたはclusterrolesを表示します。Rolesはnamespaceスコープされ、clusterrolesはクラスターにスコープされます。kubectl get roles -Akubectl get clusterroles -
前の出力で返された
roleまたはclusterroleの詳細を表示します。クラスター内で IAM プリンシパルに必要となる許可 (rules) があることを確認します。前のコマンド出力で返された
role-nameを、roleの名前に置き換えます。kube-systemを、roleの名前空間に置き換えます。kubectl describe role role-name -n kube-systemcluster-role-nameを、前のコマンドの出力で返されたclusterrole名に置き換えます。kubectl describe clusterrole cluster-role-name -
既存の Kubernetes の
rolebindingsまたはclusterrolebindingsを表示します。Rolebindingsはnamespaceスコープされ、clusterrolebindingsはクラスターにスコープされます。kubectl get rolebindings -Akubectl get clusterrolebindings -
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.iocluster-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
-
-
aws-authConfigMapを編集します。eksctlのようなツールによりConfigMapを更新することができます。あるいは、手動で編集しての更新も可能です。重要
ConfigMapの編集には、eksctlや、その他のツールを使用することをお勧めします。使用できる他のツールについては、Amazon EKS ベストプラクティスガイドの「ツールを使用して aws-authConfigMap を変更する」を参照してください。 aws-authConfigMapの形式が不適切な場合、クラスターへのアクセスが失われる場合があります。-
eksctl で configmap を編集するステップを表示します。
-
configmap を手動で編集するステップを表示します。
-
Eksctl で Configmap を編集する
-
デバイスまたは AWS CloudShell にインストールされている
eksctlコマンドラインツールのバージョン0.212.0以降が必要です。eksctlをインストールまたはアップグレードするにはeksctlドキュメントの「インストール」を参照してください。 -
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 -
ロールのマッピングを追加します。
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-rolemy-team/developers/を削除する必要があります。出力例は次のとおりです。
[...] 2022-05-09 14:51:20 [ℹ] adding identity "{arn-aws}iam::111122223333:role/my-role" to auth ConfigMap -
ユーザーのマッピングを追加します。IAM のベストプラクティスでは、ユーザーではなくロールに許可を付与することが推奨されています。
my-userを、ご自身のユーザー名に置き換えます。eks-console-dashboard-restricted-access-groupを、KubernetesRoleBindingまたは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 -
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 を手動で編集する
-
編集する
ConfigMapを開きます。kubectl edit -n kube-system configmap/aws-auth注記
「
Error from server (NotFound): configmaps "aws-auth" not found」というエラーが表示された場合は、「aws-auth ConfigMap をクラスターに適用する」の手順を使用して、ストックConfigMapを適用します。 -
IAM プリンシパルを
ConfigMapに追加します。IAM グループは IAM プリンシパルではないため、ConfigMapに追加できません。-
IAM ロールを (たとえば、フェデレーティッドユーザーに) 追加するには、
ConfigMapのmapRolesセクションのdataの下にロールの詳細を追加します。ファイルに存在しない場合は、このセクションを追加します。各エントリは、次のパラメータをサポートしています。-
rolearn: 追加する IAM ロールの ARN。この値にパスを含めることはできません。例えば、
arn:aws:iam::のような ARN を指定することはできません。ARN は、111122223333:role/my-team/developers/role-namearn:aws:iam::のようにする必要があります。111122223333:role/role-name -
username: IAM ロールにマッピングする Kubernetes 内のユーザー名。
-
groups: ロールをマップする Kubernetes グループのグループまたはリスト。グループには、デフォルトグループか、
clusterrolebindingまたはrolebindingで指定されたグループを使用します。詳細については、Kubernetes ドキュメントの「デフォルト Role と ClusterRoleBinding」を参照してください。
-
-
IAM ユーザーを追加するには: IAM のベストプラクティスでは、ユーザーではなくロールに許可を付与することが推奨されています。
ConfigMapのmapUsersセクション (dataの下) にユーザーの詳細を追加します。ファイルに存在しない場合は、このセクションを追加します。各エントリは、次のパラメータをサポートしています。-
userarn: 追加する IAM ユーザーの ARN。
-
username: IAM ユーザーにマッピングする Kubernetes 内のユーザー名。
-
groups: ユーザーをマップする Kubernetes グループのグループまたはリスト。グループには、デフォルトグループか、
clusterrolebindingまたはrolebindingで指定されたグループを使用します。詳細については、Kubernetes ドキュメントの「デフォルト Role と ClusterRoleBinding」を参照してください。
-
-
-
例えば、次の YAML ブロックには次が含まれます。
-
ノードがそれ自体をクラスターに登録できるように、
my-console-viewer-roleIAM ノードインスタンスを Kubnetes グループにマッピングしているmapRolesセクション。および、すべてのクラスターですべての Kubernetes リソースを表示することが可能な、Kubernetes グループにマッピングされた IAM ロール。my-console-viewer-roleIAM ロールに必要な IAM と Kubernetes グループのアクセス許可のリストについては、「必要なアクセス許可」を参照してください。 -
デフォルトの AWS アカウントからの
adminIAM ユーザーをsystem:mastersKubernetes グループにマッピングするmapUsersセクション。および、特定の名前空間で Kubernetes リソースを表示することが可能な、Kubernetes グループにマッピングされた、他の AWS アカウントからのmy-userユーザー。my-userIAM ユーザーに必要な IAM と Kubernetes グループのアクセス許可のリストについては、「必要なアクセス許可」を参照してください。必要に応じて行を追加または削除し、すべての
値の例を、実際の値で置き換えます。# 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
-
-
ファイルを保存し、テキストエディタを終了します。
aws-auth ConfigMap をクラスターに適用する
マネージド型ノードグループを作成するとき、または aws-auth を使用してノードグループを作成するときに、ConfigMap eksctl が自動的に作成され、クラスターに適用されます。これはノードをクラスターに追加するために当初作成されたものですが、この ConfigMap を使用して、ロールベースアクセスコントロール (RBAC) アクセスを IAM プリンシパルに追加することもできます。セルフマネージド型ノードが起動済みで、クラスターに aws-auth ConfigMap を適用していない場合は、次の手順に従って適用できます。
-
aws-authConfigMapが適用済みであるかどうかを確認します。kubectl describe configmap -n kube-system aws-auth「
Error from server (NotFound): configmaps "aws-auth" not found」というエラーが表示された場合は、以下のステップを実行してストックConfigMapを適用します。 -
AWS オーセンティケーター設定マップをダウンロード、編集、適用します。
-
設定マップをダウンロードします。
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml -
aws-auth-cm.yamlファイルで、ノードに関連付けられている IAM ロールの Amazon リソースネーム (ARN) にrolearnを設定します。これを行うには、テキストエディタを使用するか、my-node-instance-roleを置き換えて次のコマンドを実行します。sed -i.bak -e 's|<ARN of instance role (not instance profile)>|my-node-instance-role|' aws-auth-cm.yamlこのファイルの他の行は変更しないでください。
重要
ロールの ARN には、
role/my-team/developers/my-roleなどのパスを含めることはできません。ロールの ARN は、arn:aws:iam::のような形式にする必要があります。この例では、111122223333:role/my-rolemy-team/developers/を削除する必要があります。ノードグループの AWS CloudFormation スタック出力を検査し、次の値を探すことができます。
-
InstanceRoleARN –
eksctlで作成されたノードグループ用 -
NodeInstanceRole – AWS Management Console で、Amazon EKS で発行された AWS CloudFormation テンプレートで作成されたノードグループ用
-
-
設定を適用します。このコマンドが完了するまで数分かかることがあります。
kubectl apply -f aws-auth-cm.yaml注記
認可またはリソースタイプのエラーが発生した場合はトラブルシューティングトピックの「許可されていないか、アクセスが拒否されました (kubectl)」を参照してください。
-
-
ノードのステータスを監視し、
Readyステータスになるまで待機します。kubectl get nodes --watchCtrl+Cを入力して、シェルプロンプトに戻ります。