概要

Amazon EKS（Elastic Kubernetes Service）のクラスタアクセス管理をめぐり、AWSが非推奨とした旧来の認証方式「aws-auth ConfigMap」が、依然として業界で圧倒的なシェアを占めている実態が明らかになった。セキュリティ企業Wizが公表した「Kubernetes Security Report 2025」によれば、調査対象のEKSクラスタのうち実に81%が、AWSのセキュリティベストプラクティスに反して非推奨のConfigMap認証方式を使い続けているという。AWSはEKS 1.23以降、IAMネイティブでAPI駆動型の新方式「アクセスエントリー（Access Entries）」を提供し、こちらへの移行を推奨してきたが、大規模な運用現場での切り替えは大きく遅れている状況が浮き彫りになった。

背景：aws-auth ConfigMapが抱える課題

aws-auth ConfigMapは、AWSのIAMプリンシパル（ユーザーやロール）をKubernetesクラスタ内の権限にマッピングするための仕組みで、クラスタ内のConfigMapリソースを手動で編集して管理する必要があった。この方式には運用・セキュリティ上のいくつかの構造的な課題が指摘されている。まず、どのIDがクラスタへのアクセス権を持つかを把握するには、クラスタごとに個別にConfigMapを解析する必要があり、大規模なフリート環境では可視性の確保が困難だった。さらに深刻な問題として、EKSクラスタを作成したAWSアイデンティティには自動的に「system:masters」という管理者権限が付与され、この権限は後から削除できず、追跡が困難な「シャドー管理者」を生み出す原因となっていた。加えて、EKSのIAMはネイティブなAWS IAMの仕組みとは別系統で管理されているため、AWSアカウントの管理者権限を持つIAMプリンシパルであっても、自動的にEKSクラスタへアクセスできるわけではないという分かりにくさもあった。

新方式アクセスエントリーの仕組みと移行手順

これらの課題を解消するため、AWSはアクセスエントリーというAPIベースの新しい管理レイヤーを導入した。アクセスエントリーは、AWSプリンシパルごとにクラスタ単位で作成され、AWSが管理するアクセスポリシー（AmazonEKSClusterAdminPolicyやAmazonEKSViewPolicyなど）またはKubernetesグループのいずれか、あるいは両方にマッピングできる。両方にマッピングされた場合、実効権限は両者の権限の和集合となる。認証モードには、ConfigMapのみを使う従来の「CONFIG_MAP」、両方式が共存する「API_AND_CONFIG_MAP」、ConfigMapを無視してアクセスエントリーのみを使う「API」の3種類が用意されており、AWSは既存クラスタに対して、まず「API_AND_CONFIG_MAP」モードを有効化し、ConfigMap内の各プリンシパルに対応するアクセスエントリーを作成した上で適切なポリシーやグループをマッピングし、最終的に「API」モードへ切り替えるという段階的な移行を推奨している。なお、API専用モードへの切り替えは一方向の操作であり、後戻りはできない点に注意が必要だ。

今後の展望

AWSはaws-auth ConfigMapについて、将来のEKSバージョンで廃止する方針を示しており、後方互換性のために当面は残されるものの、新規クラスタやアクセス設定については一貫してアクセスエントリーの利用が推奨されている。しかし今回の調査結果は、非推奨化のアナウンスだけでは大規模な運用環境での移行が進まない現実を示している。特に多数のクラスタを抱える組織にとっては、ConfigMapの編集履歴や既存の自動化パイプラインとの整合性を取りながら移行作業を進める必要があり、コストと手間が移行の障壁となっている可能性がある。今後、AWSが廃止時期を具体的に打ち出した場合、移行の遅れているクラスタでは急激な対応を迫られるリスクがあり、フリート全体のアクセス管理を可視化した上で計画的な移行を進めることが、セキュリティと運用の両面から重要になりそうだ。