このページの改善にご協力ください
本ユーザーガイドの改善にご協力いただけませんか? このページの下部までスクロールし、[GitHub でこのページの編集] を選択します。皆さまにご協力いただくことで、あらゆる人々に使いやすいユーザーガイドになります。
ConfigMap を使用して Kubernetes へのアクセスを IAM ユーザーに許可する
重要
aws-auth
ConfigMap は廃止されました。Kubernetes API へのアクセスを管理する際は、アクセスエントリを使用することをお勧めします。
IAM プリンシパルを使用してクラスターにアクセスします。プリンシパルは、Amazon EKS コントロールプレーンで実行される AWS IAM Authenticator for Kubernetesaws-auth
ConfigMap
から取得します。すべての aws-auth
ConfigMap
設定については、GitHub の「完全な設定形式
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 承認の使用
IAM プリンシパルを Amazon EKS クラスターに追加するには
-
クラスターへのアクセスに
kubectl
が使用している認証情報を判別します。使用中のコンピュータ上で、次のコマンドを使用して、kubectl
が使用する認証情報を判別できます。デフォルトのパスを使用しない場合は、
を~/.kube/config
kubeconfig
ファイルへのパスに置き換えます。cat
~/.kube/config
出力例は次のとおりです。
[...] contexts: - context: cluster:
my-cluster.
user:region-code
.eksctl.ioadmin@my-cluster.
name:region-code
.eksctl.ioadmin@my-cluster.
current-context:region-code
.eksctl.ioadmin@my-cluster.
[...]region-code
.eksctl.io前述の出力例では、
という名前のユーザーの認証情報がadmin
という名前のクラスター用に設定されています。このユーザーがクラスターを作成したユーザーである場合は、すでにそのクラスターにアクセスできます。クラスターを作成したユーザーでない場合は、以降の手順を実行して、他の IAM プリンシパルのクラスターへのアクセスを有効にする必要があります。IAM のベストプラクティスでは、ユーザーではなくロールに許可を付与することが推奨されています。次のコマンドを使用すると、現在クラスターへのアクセスが可能な、他のプリンシパルを確認できます。my-cluster
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-auth
ConfigMap
です。ノードインスタンスのロールだけがクラスターにアクセスできます。 -
IAM プリンシパルをマッピングできる既存の Kubernetes
roles
とrolebindings
またはclusterroles
とclusterrolebindings
があることを確認してください。これらのリソースの詳細については、Kubernetes ドキュメント の「RBAC 認可の使用」を参照してください。 -
既存の Kubernetes
roles
またはclusterroles
を表示します。Roles
はnamespace
にスコープされますが、clusterroles
はクラスターにスコープされます。kubectl get roles -A
kubectl get clusterroles
-
前の出力で返された
role
またはclusterrole
の詳細を表示します。クラスター内で IAM プリンシパルに必要となる許可 (rules
) があることを確認します。
を、前のコマンド出力で返されたrole-name
role
の名前に置き換えます。
をkube-system
role
の名前空間に置き換えます。kubectl describe role
role-name
-nkube-system
を、前のコマンド出力で返されたcluster-role-name
clusterrole
の名前に置き換えます。kubectl describe clusterrole
cluster-role-name
-
既存の Kubernetes
rolebindings
またはclusterrolebindings
を表示します。Rolebindings
はnamespace
にスコープされますが、clusterrolebindings
はクラスターにスコープされます。kubectl get rolebindings -A
kubectl get clusterrolebindings
-
rolebinding
またはclusterrolebinding
の詳細を表示して、前のステップでroleRef
としてリストされたrole
またはclusterrole
、そしてsubjects
にリストされたグループ名があることを確認します。
を、前のコマンド出力で返されたrole-binding-name
rolebinding
の名前に置き換えます。
をkube-system
rolebinding
のnamespace
に置き換えます。kubectl describe rolebinding
role-binding-name
-nkube-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
-
-
aws-auth
ConfigMap
を編集します。eksctl
のようなツールによりConfigMap
を更新することができます。あるいは、手動で編集しての更新も可能です。重要
ConfigMap
の編集には、eksctl
や、その他のツールを使用することをお勧めします。使用できる他のツールについては、Amazon EKS ベストプラクティスガイドの「ツールを使用してaws-auth
ConfigMap
を変更する」を参照してください。 aws-auth
ConfigMap
の形式が不適切な場合、クラスターへのアクセスが失われる場合があります。
aws-auth
ConfigMap
をクラスターに適用する
マネージド型ノードグループを作成するとき、または aws-auth
を使用してノードグループを作成するときに、ConfigMap
eksctl
が自動的に作成され、クラスターに適用されます。これはノードをクラスターに追加するために当初作成されたものですが、この ConfigMap
を使用して、ロールベースアクセスコントロール (RBAC) アクセスを IAM プリンシパルに追加することもできます。セルフマネージド型ノードが起動済みで、クラスターに aws-auth
ConfigMap
を適用していない場合は、次の手順に従って適用できます。
aws-auth
ConfigMap
をクラスターに適用するには
-
aws-auth
ConfigMap
が適用済みであるかどうかを確認します。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
-
ファイルで、ノードに関連付けられている IAM ロールの Amazon リソースネーム (ARN) にaws-auth-cm.yaml
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-role
my-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 --watch
Ctrl
+C
を入力して、シェルプロンプトに戻ります。