目次
はじめに
今年も、アドベントカレンダー担当としてブログを執筆する牛山です。
今回は、Amazon EKS作成後、EKSクラスターのコンソール画面で権限エラーと思わしきエラーメッセージに遭遇した方の参考となればと思い解決方法をご紹介します。
公式サイトに記載されている内容で設定すれば解決するのですが敢えて教訓として記載します。
実際のエラー画面
エラー例①
EKSクラスター作成後、AWSマネージメントコンソールからEKSクラスターの画面にいくと次のように権限エラーとなる旨のメッセージになりクラスター内で稼働しているPod等の情報が確認できません。
画面上「このクラスターには ポッド がないか、表示する許可がありません。」になっていますが、ポッドが存在しないとき等このような表示になりますが、赤枠で囲った部分のメッセージが出ていると確認できません。
このメッセージはRBAC認可がクラスター側に設定されていない為に出ます。
- RBAC認可を使用する | Kubernetes
Role Based Access Control(RBAC)は、組織内の個々のユーザーのRoleをベースに、コンピューターまたはネットワークリソースへのアクセスを制御する方法です。
エラー例②
RBAC認可に加えIAMプリンシパルによる許可が不足している旨のメッセージが出るパターンです。
これは文字通り、ログインしているIAMユーザもしくはロールに対して、Kubernetesリソースを表示するために必要な許可が割当たっていない場合に出ます。
または
対処
エラー例①、②を解決する方法を次の通り紹介していきます。
エラーへの対処をまとめて説明します。
IAMプリンシパルへの対応
ログインしている、IAMユーザまたはIAMロールに対して次に記載のポリシー権限を付与することで解決可能です。
キャプチャ画像では、IAMのインラインポリシーとしてeks-access(適当な名前)で、上記リンク先にあります、「必要なアクセス許可」項目の「1. eks:AccessKubernetesApi、および Kubernetes リソースを表示するために必要なその他の IAM アクセス許可...」にあるポリシー設定を設定します。
RBAC認可への対応
Kubernetesリソースを表示するために必要な許可を割り当てる必要があります。
適用には、Kubernetesを操作するツールである「kubectl」をクライアント端末にインストールする必要があります。
kubectlセットアップ
- kubectl および eksctl のセットアップ - Amazon EKS
- こちらから、各OS、Kubernetesバージョンに対応したツールがダウンロード可能です。
windowsの場合、winget install kubectlコマンドでインストールすることも可能です。
AWSから提供されているkubectlコマンドを極力使用することをオススメします。
kubectlからEKSにアクセスする場合、事前にAWS CLIにて、AWS アクセスキー ID とシークレットキーを設定しておく必要がございますのでご注意ください。
- AWS CLIでの認証情報ファイルの設定 AWS CLI - AWS Command Line Interface
- AWS アクセスキー ID とシークレットキーを設定についてはこちらのリンクを参考ください。
- リンク先ページ内にあります「Long-term credentials」で設定します。
EKSクラスターへのアクセス認証情報設定
EKSクラスターに対して、操作するために認証情報を次のコマンドで設定します。
aws eks update-kubeconfig --region {EKSクラスターが存在するリージョンを指定} --name {対象リージョンに存在するEKSクラスター名を指定}
- Kubernetesにアクセスする為には、クライアント端末側に許可設定が必要ですのでこちらのコマンドで設定します。
- ※例:
aws eks update-kubeconfig --region us-east-1 --name mysystem-primary-cluster
RBAC認可設定
Kubernetesに対して望ましい状態を定義するマニフェストファイルを作成し、設定を適用する流れとなりますので作成していきます。
マニフェストについて気になる方は次のリンクを参考ください。
eks-console-full-access.yamlのファイル名で、全てのリソースに対して読み取りアクセスを許可する設定を次の通り記述します。
- eks-console-full-access.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: eks-console-dashboard-full-access-clusterrole
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs:
- get
- list
- watch
---
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
→すべてのリソースタイプにアクセスを許可する。(読み取りアクセスのみ)
kubectlコマンドを使用し設定を適用します。
kubectl apply -f eks-console-full-access.yaml
clusterrole.rbac.authorization.k8s.io/eks-console-dashboard-full-access-clusterrole created
clusterrolebinding.rbac.authorization.k8s.io/eks-console-dashboard-full-access-binding created
ConfigMapの変更
先ほど作成しました、RBAC認可に含まれるグループに対してIAMユーザまたはIAMロールからアクセス可能な設定をaws-authと呼ばれるIAMユーザやロールを使ってアクセス制御をおこなう既存設定に追記します。
kubectl edit -n kube-system configmap/aws-auth
# 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
- system:node-proxier
rolearn: arn:aws:iam::{AWSアカウントID12桁}:role/{Fargateプロファイル実行ロール}
username: system:node:{{SessionName}}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ロールとユーザへのアクセス許可
ロールまたはユーザへのアクセス許可設定をおこなう場合次の箇所を設定します。
ここから
- groups:
- eks-console-dashboard-full-access-group
rolearn: arn:aws:iam::{AWSアカウントID12桁}:role/hoge
username: hoge-role
mapUsers: |
- groups:
- eks-console-dashboard-full-access-group
userarn: arn:aws:iam::{AWSアカウントID12桁}:user/huga
username: huga
ここまで
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kind: ConfigMap
metadata:
creationTimestamp: "2024-11-18T03:22:26Z"
name: aws-auth
namespace: kube-system
resourceVersion: "44241"
uid: f837bbb6-c7c1-42d2-a1d5-2f1eae3cc24a
→適用後、「configmap/aws-auth edited」となれば問題ないです。
次のような形で出力されれば問題ありません。
kubectl describe -n kube-system configmaps aws-auth
Name: aws-auth
Namespace: kube-system
Labels: <none>
Annotations: <none>
Data
====
mapRoles:
----
- groups:
- system:bootstrappers
- system:nodes
- system:node-proxier
rolearn: arn:aws:iam::{AWSアカウントID12桁}:role/{Fargateプロファイル実行ロール}
username: system:node:{{SessionName}}
- groups:
- eks-console-dashboard-full-access-group
rolearn: arn:aws:iam::{AWSアカウントID12桁}:role/hoge
username: hoge-role
mapUsers:
----
- groups:
- eks-console-dashboard-full-access-group
userarn: arn:aws:iam::{AWSアカウントID12桁}:user/huga
username: huga
BinaryData
====
Events: <none>
対処後確認
ConfigMapに設定した対象ユーザまたはロールからEKSクラスターの画面にいき、冒頭のエラーメッセージがないことかつリソース確認できます。
まとめ
いかかでしたでしょうか、意外と設定すべき所がおおく考慮事項が多い印象かと思います。
キャプチャ画像に示している画面からはリソースの変更はおこなえず閲覧のみの権限で設定していますので安心です。
kubectlからのアクセスはリソース変更等が可能な為、注意して操作が必要です。
プロフィール
AWSの設計・構築をメインにおこなっています。
運用・保守をおこなう部署におりましたが、最近、アーキテクト課に異動しました。
日々精進しております。
LINK
クラウドベリージャム:プロフィールページ