はじめに
これまで、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 を使うことを推奨しています。