[アドカレ2024] EKSクラスターのコンソール画面から権限エラーになる場合の対処

はじめに

今年も、アドベントカレンダー担当としてブログを執筆する牛山です。

今回は、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セットアップ

windowsの場合、winget install kubectlコマンドでインストールすることも可能です。

AWSから提供されているkubectlコマンドを極力使用することをオススメします。

kubectlからEKSにアクセスする場合、事前にAWS CLIにて、AWS アクセスキー ID とシークレットキーを設定しておく必要がございますのでご注意ください。

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からのアクセスはリソース変更等が可能な為、注意して操作が必要です。

返信を残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA