はじめに

こんにちは、エンジニアのFeelです。
先日、SaaSシステムに利用するアプリのテストのためにAmazon EKSを使用する機会があり、スムーズに進むと予想した私の考えとは異なり、以下のようなエラーが発生しました。

『現在のユーザーまたはロールには、この EKS クラスター上の Kubernetes オブジェクトへのアクセス権がありません
これは現在のユーザーまたはロールがクラスターリソースを記述するための Kubernetes RBAC アクセス許可を持っていないか、クラスターの認証設定マップにエントリがないことが原因である可能性があります。』

単純にクラスターにアクセスする権限がないという内容でしたが、EKS作業用ユーザーには、確かEKS使用に必要なIAMロールを設定をしたと思っていました。正しく設定更新ができていなかったのか、または設定の不備があるのかと考えましたが、IAM設定にAmazonEKSAdminPolicyなどAdmin権限を付与したため、特に問題があるようには見えませんでした。 EKS は特にコアがAWSサービスではなくオープンソースであるKubernetes であり、EKS はこれを管理するマネージメントサービスであるため、IAM ユーザーがサービスを使用するには、単にIAMロールを追加するだけではノード等を利用できない上に、このようなケースがしばしば発生するようなので、今回エラーの解決手順をまとめておけば、再び当該エラーが発生した際にRT（Resolution Time）を節約できると考え調査をしました。そして当然、複数の作業者が存在するクラスターを利用するケースがこれからSaaSビジネスを行うNHN テコラスでも多く発生すると考え、そういった場合にも必ず役立つので、本ブログではその調査内容をまとめました。

前提：同じアカウント内でクラスターの作成者と作業者が違う

• アカウント(860391XXXXXX)
• クラスターの作成者
  • IAMユーザー:2049
  • IAMロール：ekscluster
• クラスターの作業者
  • IAMユーザー:6248
  • IAMロール：eks6248

解決までの道のり

aws-auth ConfigMapにIAMユーザーとロールを追加したら問題が解決しました。
その解決策にたどり着いた経緯や考え方について、ご説明していきます。

1. クラスタ作成者の識別

ほとんどのサービスがそうですが、作成者がサービス利用に対する許可の権限を持っているため、上記のような権限関連エラーが発生した場合、その作成者のアイデンティティーを把握して作成者に権限の委任や追加などを要請することが、問題解決への最も早い近道ではないかと思います。そのためEKSのクラスターに関しても、まず作成者を特定する必要があります。特定方法のひとつとして、AWS CloudTrail のログを見ることです。AWS CloudTrail は、AWS Management Console、SDK、および CLI によって発信された全ての AWS API コールを記録しています。そのため、アカウントで CloudTrail を有効にしている場合は、EKS クラスターを作成したユーザーの ID を見つけることができるはずです。

 ※確認手順は下記のとおりです。

①AWS Management ConsoleからCloudTrailに移動します。※作業対象のクラスター名は上記の「testcluster」でした。
②CloudTrailダッシュボードのサイドバーから「イベント履歴」を選択します。
③[Event history] ページの上部にフィルタが表示されます。 「イベント名」フィルタを下記イメージの様に「CreateCluster」に設定します。これは、新しい EKS クラスターを作成する API コールです。EKSクラスターの名前がわかっている場合は、「リソース名」でフィルタリングして、クラスター名を指定することもできます。④フィルタを適用すると、「CreateCluster」イベントのリストが表示されます。 イベントをクリックすると、下記イメージの様に詳細が表示されます。詳細の中の「ユーザー名」は、EKSクラスターを作成したユーザーのIDです。

上記のアプローチは、通常デフォルトで有効になっている EKS クラスターの作成中に 、AWS アカウントで CloudTrail が有効になっている場合にのみ有効です。 ただし、その時点で CloudTrail がアクティブになっていない場合、EKS クラスターの作成者を特定することはできません。その場合は、AWS管理者や作業責任者に確認することが一番早い方法だと思います。

2. IAM資格情報ARNの識別

作成者が誰なのか確認出来たら、次はコンソールへのアクセスに使用する IAM ユーザーまたはロールを識別します。下記のように コマンドを実行してIAM資格のARNを確認できます。過剰な権限設定や誤った権限設定などがエラーの原因となる場合もあるため、ARNを確認してリソースについて権限の検討と理解をすると、さらにサービスのアプローチするユーザーや作業者を追加する際に役立ちます。下記の画像は、Cloud9を利用するためにEC2用として設定したIAMロール(eks-admin)ですが、

以下のように「Administrator Access」を付与したため、特にEC2上の権限の問題ではないように見えました。

3. aws-auth ConfigMap に IAM ユーザーまたはロールを追加

最後に確認する部分が「aws-auth ConfigMap」です。序論部分で説明したように、EKSはIAM一つでは権限コントロールができないため、IAMとユーザーおよび役割とKubernetes RBAC(Role-Based Access Control)間のマッピングを定義するファイルが必要ですが、それが「aws-auth ConfigMap」です。 通常、Kubernetesクラスター内の作業者ノード(worker nodes)は、クラスターとの通信のためにAWS IAMロールを持ち、このロールはクラスターのKubernetes Service Accountとマッピングされます。
「aws-auth Config Map」には、このようなマッピング情報が含まれており、クラスターに認証されたAWS IAMユーザーまたは、その役割にKubernetesリソースへのアクセス権限を付与することもあります。それなら、このファイルに新しい作業者を追加すれば問題ないと考え、コンソールでは作業が難しいので CLI環境を利用する必要があります。しかし、KubernetesがAWSのオリジナルサービスではないため、下記のような連動方法が最善の策ではないかと考えます。そして、作業を遂行できるコマンドは、Kubernetesで提供するkubectlとAWSのEKSで提供するeksctlの2つが存在します。

3-1.  kubectl

①まず、kubectlを利用して現在の ConfigMap をを確認してみます。

②ここに新しい作業者IAMユーザーとロールを追加します。（kubectl edit configmap aws-auth -n kube-system）

③簡単です。上記と同時に追加の作業者の情報入力が完了すれば、新しいConfigMapを適用します。

 kubectl apply -f aws-auth-configmap.yam

3-2. eksctl

kubectl がKubernetes クラスターを管理する一般的なコマンドであるとすれば、eksctl はAWS の EKS サービスと相互作用するのに使われるAWS とKubernetes の連動コマンドであると考えれば容易です。上記のようにAWSのIAMユーザーとロールを追加するマッピングが必要なので、当然kubectlだけではなく、下記のイメージのようにeksctlの使用も可能です。

①IAMユーザーの追加

②IAMロールの追加

ちなみに、上記のregionやARNのようなオプションとは異なり、groupは見慣れないオプションかもしれませんが、 Kubernetesにおいてグループは同じ権限を持つユーザーの集合を指します。以下は基本グループの一部です。

system:authenticated: これには、認証されたすべてのユーザーが含まれます。

system:unauthenticated: これには、認証されていないすべてのユーザーが含まれます。

system:masters: このグループは、クラスタに完全なアクセス権を持ち、 クラスタ内の任意のアクションを実行できます。 通常は、クラスタ作成者の役割に関連付けられています。

system:serviceaccounts:<namespace>: これには、<namespace> 名前空間内のすべてのサービス アカウントが含まれます。

system:masters groupは、クラスタ内のすべてのリソースを作成、読み取り、更新、および削除する機能を含む、 クラスタへのフル アクセスを提供します。 このため、このグループにユーザーまたはロールを追加する場合は注意が必要です。 信頼できるユーザーまたはロールだけをこのグループに追加し、常に最小特権の原則を適用する必要があります。 このテストはユーザーと役割の追加にフォーカスを合わせていて、グループの設定などによる時間の浪費ができないのでsystem:mastersで実行しました。 この概念は、タスクを実行するために必要なレベルのアクセスまたは権限だけをユーザーまたはロールに付与するという概念です。 この原則は、攻撃対象を減らすことによって、悪意のある活動や侵害のリスクを減らすために使用されます。

4.継続してエラーが発生した場合

aws-auth Config Mapを更新しても問題が発生した場合、IAMポリシーがアップデートされていなかったり、Kubernetes RBACが変更事項を認識できなかったためかもしれません。 前述したように、IAM権限はKubernetes権限とは別であり、ユーザーがKubernetes APIと相互作用できるように、両方とも正しく設定する必要があります。 以下の次のような箇所を確認してください。

①kube-systemネームスペースのaws-auth ConfigMapが正しくアップデートされたか確認します。

 kubectl-n kube-system describe configmap aws-auth 

outputは、mapRolesまたはmapUsersの下のIAMユーザーまたはロールを表示しなければなりません。そうでない場合、ConfigMapが正しくアップデートされていないか、間違っていることを意味します。KubernetesのConfigMapが間違って構成されると、まるで削除されたかのようになり、クラスター作成者を除くすべての作業者の使用が不能になる可能性があります。
②IAMユーザーまたはロールを確認して、aws-auth ConfigMapに追加されたロールかを確認します。IAMユーザーまたはロールARNの入力をミスすると時間のロスになるので、注意深くチェックが必要であり、意外に見落としやすい部分になるかと思います。
③ IAMユーザーまたはロールに必要なAWS権限があることを確認します。これは、ユーザーまたはロールに付与されたIAMポリシーが権限を遂行するため非常に重要な役割を持っているからです。例えばEKSクラスタおよびノードを管理する必要がある場合、AmazonEKSClusterPolicyおよびAmazonEKSWorkerNodePolicyが必須なので、該当するポリシーがないと作業を実行できません。

5.結論

複数の作業者がいる会社の場合、AWS EKSエラーのうち特に多く発生しているユーザーの権限の問題についてソリューションを確認してみました。簡単にまとめると、最終的に、Kubernetes オブジェク トへのアクセス権に関するエラーが出た場合は、まず、クラスタ作成者の識別をし、次にIAM資格情報ARNの識別をして、aws-auth ConfigMap に IAM ユーザーまたはロールを追加すれば解決できました。問題解決に必要なAWS-auth ConfigMap のニュアンスをすべて理解することは、容易ではありませんでしたが、 上のアーキテクチャの流れにより、ある程度意図を理解することができました。これからSaaS サービスのマルチテナント導入において、 AWS EKS のようなマイクロサービスの管理システムの役割が重要であり、今後の使用頻度が高くなるのは当然であるため、本ブログで説明したこのような簡単な問題対応は、RT（Resolution Time）を大幅に減らすことができて運営サービスの質を高める上で大きな役割を果たすことは間違いないと考えます。