EKS の IRSA と Pod Identity

# はじめに

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

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

# EKS IRSA

https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html

![irsa.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705806/4de1d997-e2f1-4909-81a6-5d3c0f2a3aab.png)

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

## 認証フロー

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

IRSA の詳細な仕組みについては、[こちら](https://www.ren510.dev/blog/gcp-workload-identity-federation) で詳しく説明しています。

https://www.ren510.dev/blog/gcp-workload-identity-federation

# メリット

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

# 制限

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

# EKS Pod Identity

https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html

![eks-pod-identity.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/705806/5ea55587-37b1-4e81-a641-221001509da0.png)

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

## 認証フロー

1. Pod Identity Association を作成して、IAM ロールと Kubernetes Namespace および Service Account をマッピング
2. EKS が内部的に [Pod Identity Agent](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html) をノードにインストール
3. 対応する Pod は Pod Identity を使って自動的に IAM ロールを引き受ける
4. EKS はノード上に権限管理のインフラを提供して、Web Identity Token や STS を呼び出すことなく、適切な IAM ロールの Credentials を提供
5. 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 へ移行する必要は無いのかなと思います。

https://aws.amazon.com/jp/about-aws/whats-new/2023/11/amazon-eks-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 を使うことを推奨しています。

https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html#_identities_and_credentials_for_eks_pods