【EKS × IRSA × OIDC】シーケンス図で理解する仕組み解説

サムネイル

1. はじめに
2. 全体像（シーケンス図）
3. 各ステップの解説
4. ポイントまとめ
- 4-1. 勘違いしやすいポイント
5. おわりに
6. ネットワークグループ NRE メンバー募集中！

1. はじめに

こんにちは。ITインフラ本部ネットワークグループの松野です。
私はネットワークグループの NRE（Network Reliability Engineering） チームに所属しています。

NRE は、ネットワークの信頼性を高めつつ、自動化やソフトウェア的なアプローチを積極的に取り込むことを目指しています。

従来のネットワーク運用にとどまらず、インフラをコード化して改善を素早く回す文化を取り入れています。

今回紹介するのは、その取り組みの一環である EKS × IRSA × OIDC です。

実際に触って「難しい」と感じたので、EKS 上の Pod が AWS サービス（S3 / Secrets Manager など）にアクセスする仕組みを、IRSA と OIDC の観点からシーケンス図ベースで解説していきます。

2. 全体像（シーケンス図）

IRSA OIDC Flowchart

3. 各ステップの解説

3-1. Pod マニフェスト (YAML) → ServiceAccount

Pod を定義するマニフェストファイル（例: deploy.yaml）の spec.serviceAccountName で、利用する ServiceAccount を指定します。

3-2. Pod マニフェスト (YAML) → Kubernetes API Server

ユーザーが kubectl apply などで Pod を作成すると、Pod 定義が Kubernetes API Server に送られます。

3-3. Kubernetes API Server → IRSA Mutating Webhook

Pod 作成リクエストは Admission Controlの流れに入り、EKS に組み込まれている IRSA 用 Mutating Admission Webhook が呼ばれます。

Admission Webhook とは？
Kubernetes で Pod や Deployment などを作成・更新するときに、そのリクエストを一度フックして 検証したり、自動的に設定を追加できる仕組み です。
IRSA ではこの仕組みを利用して、Pod に必要な設定を自動で注入しています。

3-4. IRSA Mutating Webhook → Kubernetes API Server

Webhook は Pod マニフェストの spec: に IRSA 用のフィールドを追加 し（上書きではなく volumes / volumeMounts / env などを差し込み）、IRSA が動作するための設定を注入します。

具体的には次の 2 点です：

OIDC トークンの投影（aud=sts.amazonaws.com）
→ Kubernetes API Server が ServiceAccount に基づいて発行した OIDC サービスアカウントトークン を、Projected Volume として Pod 内に配置します。
aud=sts.amazonaws.com は「このトークンは AWS STS 向け」という印で、STS に受理されるために必須です。
環境変数の追加（AWS_ROLE_ARN, AWS_WEB_IDENTITY_TOKEN_FILE など）
→ Pod 内の AWS SDK/CLI が IRSA を自動検出し、sts:AssumeRoleWithWebIdentity を正しく呼び出すために利用されます。
開発者が手動で設定する必要はありません。

この処理により Pod は 「どの IAM ロールを使うか」 と 「それを証明するための OIDC トークン」 を持ち、AWS 側に信頼される形で一時クレデンシャルを取得できるようになります。

3-5. Kubernetes API Server → Pod

IRSA 用の設定が組み込まれた Pod マニフェストをもとに、Pod が作成されます。
この時点で Pod は ServiceAccount と紐付けられ、IRSA 用の設定が反映されています。

3-6. Pod → AWS STS

Pod 内の AWS SDK/CLI は、注入された設定を自動で検出し、sts:AssumeRoleWithWebIdentity を呼び出します。
この際、OIDC トークンを添付します。

3-7. AWS STS → IAM ロール

STS は IAM ロールの 信頼ポリシー に基づいてトークンを検証します。

issuer（発行者 URL が IAM に登録済みか）
aud（= sts.amazonaws.com）
sub（system:serviceaccount:<namespace>:<sa>）

3-8. IAM ロール → AWS STS

IAM ロールの 信頼ポリシー 条件を満たしていれば検証が OK になります。
（例：issuer が登録済み OIDC、aud=sts.amazonaws.com、sub=system:serviceaccount:<ns>:<sa> など）

3-9. AWS STS → Pod

STS は一時的な認証情報（AccessKeyId / SecretAccessKey / SessionToken）を発行します。
この一時クレデンシャルの有効期限は デフォルトで 1 時間。
DurationSeconds を指定すると 15 分〜 IAM ロールに設定された MaxSessionDuration（最大 12 時間） の範囲で調整できます。

3-10. Pod → AWS サービス

Pod は受け取った一時クレデンシャルを使い、Amazon S3 やAWS Secrets Manager などの AWS サービス API を呼び出します。

3-11. AWS サービス → Pod

AWS サービスはリクエストを処理し、レスポンスを Pod に返却します。
（例：S3 からオブジェクトを取得、Secrets Manager からシークレットを取得など）

4. ポイントまとめ

ServiceAccount 自体には AWS 権限は無い
- 最初に誤解しやすいのは「ServiceAccount に IAM 権限を付与する」というイメージ。
- 実際は ServiceAccount はただの Kubernetes オブジェクトで、IAM 権限は一切持たない。
- 代わりに「IAM Role との紐づけ設定（アノテーション）」を持つだけ。
Admission Webhook が IRSA の設定を Pod に注入する
- Pod 作成時、Mutating Admission Webhook が「IAM Role と関連付けられた ServiceAccount を使う Pod」に追加設定を注入。
- これにより Pod 内から OIDC 経由で認証できる仕組みが渡される。
- （知らないと「どうやって Pod が IAM に繋がるの？」が謎のままになる）
OIDC トークンは短期利用の証明書
- 誤解しがちなのは「Pod が IAM Role を直接持つ」こと。
- 実際には Pod は OIDC トークン（JWT）を発行してもらい、それを使って AWS とやり取りする。
- トークンの有効期限は短く、漏洩リスクを抑制。Pod が必要なたびに新しいトークンを取得。
STS 検証を通して初めて一時クレデンシャルを得る
- Pod が持つ OIDC トークンを AWS STS に渡すと、STS が「EKS クラスター由来の正当なトークンか」を検証。
- 検証に成功すると、IAM Role に基づいた一時的な AWS クレデンシャル（アクセスキー/シークレットキー/セッショントークン）が発行される。
- この時点で初めて AWS リソースにアクセス可能となる。