AWS EKSの「Kubernetesオブジェクトにアクセスできません」エラー解決法

Amazon Elastic Kubernetes Service(EKS)を使用していて、「Your current user or role does not have access to Kubernetes objects on this EKS cluster」というエラーに遭遇したことはありませんか?グローバルのスーパー管理者なのに権限がないと表示されると、戸惑ってしまうものです。本記事では、このエラーの意味と解決手順を順を追って解説します。

access

AWSコンソールUIでの表示例

AWS

EKSクラスターに対してkubectl CLIを実行した場合の例

エラーの背景を理解する

AWS Management Console上でKubernetesリソースを表示するには、AWS IAMユーザーまたはロールがEKSクラスターのaws-auth``ConfigMapにマッピングされている必要があります。このマッピングが重要なのは、EKSクラスターを作成したIAMユーザー/ロールには、クラスターのRBAC(ロールベースアクセス制御)構成においてsystem:masters権限が自動的に付与される仕組みになっているためです。これにより、EKSコンソールでKubernetesリソースを参照できるだけでなく、Kubernetes内のaws-auth``ConfigMapを編集して、他のAWSユーザーやロールにもクラスターを操作する権限を与えることができます。

クラスターを作成したAWS IAMユーザー/ロールは、デフォルトではAWSコンソールとkubectlの両方を独占的に使える状態にあります。意外に思われるかもしれませんが、AWSコンソール上でリソースが表示されない原因は、KubernetesのRBAC権限とIAMを結びつけるマッピング設定がaws-auth``ConfigMapに存在しないことにあるのです。

問題の解決手順

クラスター作成者を特定する

まず、EKSクラスターを誰が作成したのかを特定する必要があります。手段の一つはAWS CloudTrailのログを確認することです。AWS CloudTrailは、AWS Management Console、SDK、CLIから発行されたものを含め、すべてのAWS API呼び出しを記録します。アカウントでCloudTrailが有効化されていれば、EKSクラスターを作成したユーザーを特定できます。

具体的な手順は以下のとおりです。

AWS Management Consoleにログインします。
AWS Management ConsoleからCloudTrailに移動します。サービス検索バーに「CloudTrail」と入力し、ドロップダウンから選択します。
CloudTrailダッシュボードのサイドバーから「Event history(イベント履歴)」を選択します。
イベント履歴ページの上部に表示されるフィルターで、「Event name(イベント名)」を「CreateCluster」(新しいEKSクラスターを作成するAPI呼び出し)に設定します。
EKSクラスター名がわかっている場合は、「Resource name(リソース名)」でフィルタリングし、クラスター名を指定することもできます。
フィルターを適用すると「CreateCluster」イベントの一覧が表示されます。イベントをクリックして詳細を開き、「User name(ユーザー名)」フィールドを確認すれば、EKSクラスターを作成したユーザーが特定できます。

なお、この方法が使えるのは、EKSクラスターを作成した時点でAWSアカウントのCloudTrailが有効になっていた場合に限られます(通常はデフォルトで有効です)。当時CloudTrailが有効化されていなかった場合は、EKSクラスターの作成者を特定することはできません。その場合は、組織内のAWS管理者、DevOps、SRE、もしくはこの分野に詳しい担当者に相談し、クラスター作成者の特定について助言を求めることをおすすめします。

IAMアイデンティティのARNを特定する

コンソールへのアクセスに使用しているIAMユーザーまたはロールを特定します。次のAWS CLIコマンドを実行すると、IAMアイデンティティのARNを取得できます。

aws sts get-caller-identity --query Arn

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

EKSクラスターへのアクセスを許可するには、クラスター作成者が aws-auth``ConfigMap にIAMユーザーまたはロールを追加します。これにより、対象のユーザーまたはロールがクラスターをスムーズに操作できるようになります。以下に、 kubectl と eksctl のそれぞれを使った実施例を示します。

kubectl

現在のConfigMapを取得します。

kubectl get -n kube-system configmap/aws-auth -o yaml

このコマンドで、現在の aws-auth``ConfigMap が出力されます。出力例は次のとおりです。

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::11122223333:role/EKS-Worker-NodeInstanceRole-1I00GBC9U4U7B
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes

新しいIAMユーザーまたはロールを追加するには、このYAMLを編集し、 mapRoles または mapUsers の下に新しいエントリを記述します。例は次のようになります。

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::11122223333:role/EKS-Worker-NodeInstanceRole-1I00GBC9U4U7B
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
    - rolearn: arn:aws:iam::11122223333:role/YourNewRole
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:masters
  mapUsers: |
    - userarn: arn:aws:iam::11122223333:user/YourNewUser
      username: YourNewUser
      groups:
        - system:masters

この例では、 arn:aws:iam::11122223333:role/YourNewRole を新しいIAMロールのARNに、 arn:aws:iam::11122223333:user/YourNewUser を新しいIAMユーザーのARNにそれぞれ置き換えてください。 YourNewUser は新しいIAMユーザー名に置き換えます。

3. 編集が完了したら、次のコマンドで新しいConfigMapを適用します。

kubectl apply -f aws-auth-configmap.yaml

上記コマンドの aws-auth-configmap.yaml は、編集したConfigMapのファイル名に置き換えてください。

eksctl

IAMユーザーを追加する場合:

eksctl create iamidentitymapping --region region-code --cluster cluster-name --arn arn:aws:iam::11122223333:user/YourNewUser --group system:masters

IAMロールを追加する場合:

eksctl create iamidentitymapping --region region-code --cluster cluster-name --arn arn:aws:iam::11122223333:role/YourNewRole --group system:masters

上記の例では、以下のように置き換えます。

region-code はAWSリージョンコード(例: us-west-2 )に置き換えます。
cluster-name はEKSクラスターの名前に置き換えます。
arn:aws:iam::11122223333:role/YourNewRole は新しいIAMロールのARN、 arn:aws:iam::11122223333:user/YourNewUser は新しいIAMユーザーのARNに置き換えます。
system:masters は適切なKubernetesグループに置き換えます。詳しくは下の「Kubernetesグループ」セクションを参照してください。

Kubernetesグループ

Kubernetesにおけるグループとは、同じ権限を持つユーザーの集合を指します。代表的なデフォルトグループは次のとおりです。

system:authenticated: 認証済みのすべてのユーザーが含まれます。
system:unauthenticated: 認証されていないすべてのユーザーが含まれます。
system:masters: クラスターへのフルアクセス権を持ち、あらゆる操作を実行できるグループです。一般的にはクラスター作成者のロールに関連付けられます。
system:serviceaccounts:<namespace>: <namespace> 名前空間内のすべてのサービスアカウントが含まれます。

system:masters グループはクラスターへのフルアクセス権を付与し、クラスター内のあらゆるリソースの作成・読み取り・更新・削除を可能にします。そのため、このグループへのユーザーやロールの追加は慎重に行う必要があります。追加するのは信頼できるユーザーやロールに限定し、必ず最小権限の原則を適用してください。最小権限の原則とは、業務遂行に必要なアクセス権や権限のみをユーザーまたはロールに付与するという考え方です。攻撃対象領域を縮小することで、悪意ある操作や情報漏洩のリスクを抑える狙いがあります。

アクセス問題が解決しない場合

aws-auth ConfigMap を更新しても問題が解消しない場合は、IAMポリシーが更新されていない、もしくはKubernetes RBACに変更が反映されていない可能性があります。前述のとおり、IAMの権限とKubernetesの権限は別物であり、ユーザーがKubernetes APIを操作するには両方を正しく設定する必要があります。

トラブルシューティングの手順は次のとおりです。

kube-system名前空間のaws-auth ConfigMapが正しく更新されているか確認します。

kubectl -n kube-system describe configmap aws-auth

出力で、IAMユーザーまたはロールが mapRoles または mapUsers の下に表示されているはずです。表示されていない場合は、 ConfigMap が正しく更新されていないか、書式に問題がある可能性があります。 ConfigMap の書式が崩れていると、削除されたのと同じ状態になり、クラスター作成者以外の全員がロックアウトされる恐れがあります。そのため、慎重に作業を進め、YAML LintなどのツールでYAMLの構文チェック(linting)を行うことが大切です。

2. aws-auth``ConfigMap に追加したIAMユーザーまたはロールが正しいものであることを確認します。IAMユーザーやロールのARNの入力ミスはよくあるトラブルです。

3. IAMユーザーまたはロールに必要なAWS権限が付与されていることを確認します。これは、対象のユーザーやロールにアタッチされているIAMポリシーをチェックすることで行えます。EKSクラスターとノードを管理する必要がある場合は、 AmazonEKSClusterPolicy と AmazonEKSWorkerNodePolicy のポリシーを付与すれば必要な権限がそろいます。詳細はAWS managed policies for Amazon Elastic Kubernetes Serviceを参照してください。

また、 eks:Describe* と eks:List* アクションへの読み取り専用権限を含むカスタムIAMポリシーを作成することもできます。これにより、ユーザーまたはロールはEKSリソースの情報を閲覧できるようになります。

4. IAMエンティティにマッピングされたKubernetesユーザーおよびグループが、Kubernetes側で必要な権限を持っていることを確認します。詳しくはKubernetes RBACのロールとバインディングのユーザーガイドを参照してください。

権限を付与する際は、AWSとKubernetesの両方において、最小権限の原則を常に守ってください。ユーザーまたはロールが業務を遂行するために必要な権限のみを付与するようにします。

もう一点、強調しておきたいのは、 aws-auth ConfigMap が削除されたり、構文エラーや書式の不備があったりすると、クラスター作成者を除くすべてのユーザーがアクセスできなくなるという点です。この状態を復旧できるのはクラスター作成者だけです。

AWS EKSのエラーをめぐる複雑な状況をひも解くのは決して簡単ではありませんが、適切な知識・ツール・実践的な視点を組み合わせれば、こうした壁は乗り越えられます。IAMとKubernetesのアイデンティティがどのように絡み合っているかを理解することはパズルの重要なピースであり、 aws-auth ConfigMap を扱う際の細かな勘所を押さえることも同じくらい大切です。本ガイドが、EKSを長く使ってきた方にも、これから触れる方にも、お役に立てば幸いです。