はじめに

これまで、Kubernetes のワークロードから AWS のリソースにアクセスする際の OIDC 認証手法として、IRSA（IAM Roles for Service Accounts）が広く利用されていましたが、昨今では、別の認証手段として EKS Pod Identity と呼ばれる仕組みが登場しました。

IRSA と Pod Identity は、どちらも EKS クラスタ上で稼働する Pod が AWS リソースにアクセスするための認証・認可メカニズムですが、認証手続きや仕組みに違いがあります。

EKS IRSA

EKS IRSA は、Kubernetes の Service Account（KSA）に IAM ロールを関連付けて、Pod が AWS リソースにアクセスする仕組みです。

認証フロー

開発者は、EKS に OIDC Provider を設定
IAM ロールを作成し、信頼ポリシに OIDC Provider と対象の Kubernetes Service Account を指定
Kubernetes で Service Account を作成し、アノテーションに IAM ロール ARN を付与
Pod が起動する際、対応する Service Account を用いる
Pod 内の AWS SDK や CLI は自動的に Web Identity Token（JWT）を取得して /var/run/secrets/eks.amazonaws.com/serviceaccount/token にマウント
SDK は Web Identity Token を用いて STS AssumeRoleWithWebIdentity を呼び出し、IAM ロールの一時的な Credentials を取得
一時的な Credentials を用いて、Pod から AWS リソースにアクセス

IRSA の詳細な仕組みについては、こちらで詳しく説明しています。

メリット

明確な IAM ロール毎の Pod アクセス管理
セキュアかつスケーラブル

制限

Web Identity Token のサポートが必要（IAM の制限）
STS 呼び出しによる多少のオーバヘッド・遅延が発生

EKS Pod Identity

EKS Pod Identity は、IRSA よりもシンプルなセットアップかつ STS 呼び出し不要の IAM ロール付与機能を提供します。

認証フロー

Pod Identity Association を作成して、IAM ロールと Kubernetes Namespace および Service Account をマッピング
EKS が内部的に Pod Identity Agent をノードにインストール
対応する Pod は Pod Identity を使って自動的に IAM ロールを引き受ける
EKS はノード上に権限管理のインフラを提供して、Web Identity Token や STS を呼び出すことなく、適切な IAM ロールの Credentials を提供
Pod 内の AWS SDK や CLI は、IMDS（Instance Metadata Service）を利用して直接一時的な Credentials を取得

メリット

最小特権：Pod 毎に限定された最小権限を IAM に設定できる
認証情報の分離：Pod やコンテナ毎に IAM 認証情報を分離できる
IMDS 経由の権限遮断：EC2 ノードの IAM ロール権限を制御できる
監査対応：AWS CloudTrail で IAM 使用履歴を記録・追跡できる
シンプルな認証機構：OIDC Provider の設定が不要、IRSA より導入・運用が容易
運用責任の分離：IAM と KSA をロール毎に明確に分割できる
IAM ロールの再利用性：クラスタ毎の OIDC 設定が不要で、IAM プリンシパルの定義が簡素で使い回しもできる

制限

AWS Outposts 上の EKS で使用できない
Amazon EKS Anywhere（オンプレミス）をサポートしていない
Amazon EC2 上に手動で構築した Kubernetes クラスタで使用できない

比較

項目	EKS IRSA	EKS Pod Identity
GA	2019 年 9 月	2023 年 11 月
認証方式	Web Identity → STS AssumeRole	Pod Identity Agent 経由
認証情報の取得手段	Pod 内の JWT → STS	EKS が自動的に Credentials を供給
AWS SDK 設定	自動または手動で設定	IMDS 経由で自動
STS 呼び出し	必要	不要
導入の容易さ	中程度（OIDC 設定等）	簡単（Pod Identity Association のみ）
セキュリティ	IAM + Kubernetes RBAC を兼ねる	EKS ネイティブでより安全な設計
OIDC Provider	必要	不要

どちらを使うのか

結論：

現時点ではどちらが良い悪いというのは無く、利用する用途によって使い分けます。

ただし、IRSA の場合は、クラスタ毎に Control-Plane の OIDC Provider を使用して IAM ロールの委任（AssumeRoleWithWebIdentity）が必要なため、マルチクラスタの場合は、各 OIDC Provider に対応するように、IAM ロールの信頼ポリシを明示的に変更する必要があります。

その点、Pod Identity の方が融通が効くかと思います。

とは言え、慣れしたしんだ IRSA を引き続き使用することも可能ではあるため、現時点で無理やり Pod Identity へ移行する必要は無いのかなと思います。

Pod Identity の推奨化

2024 年 12 月に発表された EKS Auto Mode では、KSA と IAM ロールを紐付ける方法として Pod Identity がネイティブにサポートされています。

従来の EKS では、Pod Identity を使用するために Addon で Pod Idenitity Agent を追加する必要がありましたが、EKS Auto Mode ではクラスタを作成した時点で DaemonSet（ノード毎に一つの Agent）として追加されます。

AWS は、今後 Pod Identity をデフォルトとして、Pod Identity が使用できない場面で IRSA を使うことを推奨しています。