EKSの権限管理、まだ複雑にしていますか？🤔 Pod Identityに切り替えるべき理由

こんにちは！今日は、AWS EKSでコンテナ（Pod）の権限を管理する方法について深く掘り下げていきたいと思います。アプリケーションがS3やDynamoDBのようなAWSサービスにアクセスする必要があるとき、どのように安全かつ効率的に権限を付与していますか？

多くの方がIRSA (IAM Roles for Service Accounts)を使用していることでしょう。しかし、IRSAを設定する際に、複雑なIAM信頼ポリシーに頭を悩ませた経験が一度はありますよね？🤯

最近、AWSはこの問題を解決するためにEKS Pod Identityという新しい機能を発表しました。今日は、既存の強者IRSAと新しい挑戦者EKS Pod Identityをすっきりと比較し、どのような状況でどちらを選択すべきかを明確に整理していきます！

---

🧐 IRSA: 慣れているが扱いにくい友人

IRSAは、Kubernetesのサービスアカウント(Service Account)とAWSのIAMロールを直接接続する方式です。EKSクラスターが持つOIDC(OpenID Connect)情報を活用し、IAMロールが特定のサービスアカウントを信頼するように設定します。

✨ IRSAはどのように機能しますか？

1. OIDC IDプロバイダーの設定: EKSクラスターを作成すると、固有のOIDCプロバイダー(Provider) URLが生成されます。これは、AWS IAMが私たちのクラスターを識別できるようにする身分証明書のようなものです。🆔
2. IAMロールの作成と信頼ポリシーの設定: Podに付与する権限を持つIAMロールを作成します。ここで重要なのは信頼ポリシー(Trust Policy)です。「このロールはEKSクラスターのOIDCプロバイダーを信頼し、my-appネームスペースにあるmy-service-accountというサービスアカウントにのみ一時的な認証情報を発行する！」と非常に具体的に明記する必要があります。
3. サービスアカウントへのアノテーション追加: アプリケーションが使用するKubernetesサービスアカウントに、どのアノテーション(eks.amazonaws.com/role-arn)でどのIAMロールを使用するかを明確に指定します。
4. 認証情報の取得: Podが実行されると、内部のAWS SDKがこの情報に基づいてAWSに一時的な認証情報を要求し、発行されたキーでAWS APIを呼び出します。🚀

🔧 IRSA設定例

最も厄介な部分であるIAMロールの信頼ポリシーから見ていきましょう。本当に長くて複雑です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.ap-northeast-2.amazonaws.com/id/EXAMPLED539D4633E53BF441"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "oidc.eks.ap-northeast-2.amazonaws.com/id/EXAMPLED539D4633E53BF441:sub": "system:serviceaccount:my-namespace:my-app-sa",
                    "oidc.eks.ap-northeast-2.amazonaws.com/id/EXAMPLED539D4633E53BF441:aud": "sts.amazonaws.com"
                }
            }
        }
    ]
}

この長いポリシーでOIDCアドレス、ネームスペース、サービスアカウント名のいずれか一つでも間違っていると、権限エラーが発生します。😭

そして、Kubernetesサービスアカウントは次のように設定します。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: my-namespace
  annotations:
    # ここにIAMロールのARNを直接入力する必要があります！
    eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-app-s3-access-role

👍 IRSAの利点

• エージェント不要: ノードに別途エージェントをインストールする必要がなく、構成がすっきりしています。
• 標準技術ベース: OIDCというオープン標準を使用しており、原理が明確です。
• 明示的な設定: すべての権限接続情報がKubernetesマニフェストにコードとして管理されます（GitOpsに有利）。

👎 IRSAの欠点

• 複雑すぎる信頼ポリシー: IAM信頼ポリシーが長くて複雑なため、ミスしやすく管理が難しいです。
• 強い結合(Tight Coupling): IAMロールのARNがサービスアカウントのYAMLにハードコーディングされます。ロールを変更するには、Kubernetesリソースを再デプロイする必要があります。
• 管理ポイントの分散: ロールが増えるにつれて、管理すべきIAM信頼ポリシーも比例して増え、管理が煩雑になります。

---

😎 EKS Pod Identity: シンプルさが武器の新しい解決策

EKS Pod Identityは、IRSAの複雑さを解決するために登場した救世主です。核心は、権限設定の中心をKubernetesからAWSに移したという点です。

✨ EKS Pod Identityはどのように機能しますか？

1. EKS Pod Identity Agentのインストール: クラスターにEKSアドオンとしてエージェントをインストールします。このエージェントが各ノードで実行され、魔法をかける主体となります。🪄
2. シンプルなIAMロールの作成: これにより、IAMロールの信頼ポリシーが驚くほどシンプルになります。「EKS Pod Identityサービスは私を信頼してもいい！」の一行で終わりです。
3. Pod Identity Associationの作成: AWSコンソールまたはCLIを通じて、IAMロールとKubernetesサービスアカウントをマッピング(Association)します。この作業はKubernetesの外部、つまりAWSで行われます。
4. 認証情報の取得: PodがAWS認証情報を要求すると、ノードにいるエージェントがその要求を傍受します。そして、AWSに設定されたマッピング情報を確認した後、正しいIAMロールの一時的な認証情報をPodの代わりに取得し、Podに渡します。

🔧 EKS Pod Identity設定例

IRSAと比較して、IAM信頼ポリシーがどれほど簡単になったか見てください。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

はい、これだけです。OIDC URLも、ネームスペースも、サービスアカウント名も必要ありません！✨

IAMロールとサービスアカウントの接続は、AWS CLIを通じてこのように一行で完了できます。

aws eks create-pod-identity-association 
    --cluster-name my-eks-cluster 
    --namespace my-namespace 
    --service-account my-app-sa 
    --role-arn arn:aws:iam::111122223333:role/my-app-s3-access-role

これで開発者は、サービスアカウントのYAMLファイルに複雑なアノテーションを入れる必要がなくなり、単にserviceAccountName: my-app-saを指定するだけでよくなります。

👍 EKS Pod Identityの利点

• 革新的なシンプルさ: 複雑な信頼ポリシーがなくなり、IAMロールの管理が非常に簡単になります。
• 中央管理と役割分離: インフラチームはAWSで権限マッピングを管理し、開発チームはアプリケーションコードにのみ集中できます。役割と責任が明確になります！
• 柔軟性と再利用性: 一つのIAMロールを複数のネームスペース、複数のサービスアカウントに簡単にマッピングできるため、ロールの再利用性が最大限に高まります。
• 設定とコードの分離: IAMロール情報がKubernetesマニフェストから分離されるため、権限変更時にアプリケーションを再デプロイする必要がありません。

👎 EKS Pod Identityの欠点

• エージェント依存性: すべてのノードにEKS Pod Identityエージェントアドオンをインストールして管理する必要があります。
• 比較的新しい機能: IRSAに比べて、まだコミュニティの使用事例やトラブルシューティング情報が少ない可能性があります。

---

🆚 IRSA vs EKS Pod Identity: 一目で比較

区分	IRSA (IAM Roles for Service Accounts)	EKS Pod Identity
動作方式	K8sサービスアカウント ↔️ IAMロール (OIDC直接接続)	Pod ➡️ エージェント ➡️ IAMロール (マッピングベース)
設定の中心	Kubernetes (サービスアカウントアノテーション)	AWS (Pod Identity Association)
IAM信頼ポリシー	非常に複雑 😭 (OIDC、ネームスペース、SA条件を明示)	非常にシンプル 😊 (“Service”: “pods.eks.amazonaws.com”)
管理の容易さ	低い (個別のポリシー管理が煩雑)	高い (マッピング情報を中央で管理)
柔軟性	低い (IAMロールとサービスアカウントの1:1の強い結合)	高い (ロールとSAの分離、N:Mマッピングが容易)

—

🎯 さて、あなたの選択は？

さあ、どちらを選択すべきか明確になったことでしょう。

🚀 EKS Pod Identityを選択してください！

• 新しいEKSクラスターを構築している、または権限設定を始めたばかりの場合（強く推奨！）
• 多数のマイクロサービスを運用しており、IAMロール管理を簡素化したい場合
• インフラチームと開発チームの役割と責任を明確に分離したい場合
• 一つの共通ロールを複数のアプリケーションで再利用したい場合

🤔 IRSAを継続して使用するか、検討することもできます。

• すでにIRSAベースで全てのシステムが安定して運用されており、移行する余裕がない場合
• セキュリティポリシーなどの理由で、ノードに追加のエージェントをインストールするのが難しい場合
• すべての権限設定をKubernetesマニフェスト内でコードとして明示的に管理(GitOps)する方式を好む場合

✨ 結論

EKS Pod IdentityはIRSAの複雑さを解決し、クラウドネイティブ環境により適した権限管理パラダイムを提示します。設定のシンプルさ、管理の一元化、柔軟な再利用性は、もはや無視できない魅力的な利点です。

もちろん、IRSAが悪い技術だという意味ではありません。しかし、より簡単で効率的な道が開かれたのであれば、その道を避ける理由はないでしょう？現在EKSの権限管理について悩んでいるのであれば、EKS Pod Identityを積極的に検討してみることをお勧めします！

---