IRSA（IAM Roles for Service Accounts）について調べてみた

こんばんは。
今回は、IRSA（IAM Roles for Service Accounts）について整理していきます。

IRSAとは

IRSA（IAM Roles for Service Accounts）は、Amazon EKS 上で動作する Pod ごとに IAM ロールを付与できる仕組みです。

従来は、Amazon EKS のノード（EC2 インスタンス）に IAM ロールを付与していましたが、この方法では同じノード上で動作するすべての Pod が同じ IAM 権限を利用することになります。

IRSA を利用することで、Kubernetes のサービスアカウント単位で IAM ロールを割り当てられるため、Pod ごとに必要最小限の権限を付与できます。

従来の課題

EC2 ノードに IAM ロールを付与した場合、

EC2 Node（IAM Role）
        │
 ┌──────┼──────┐
 ▼      ▼      ▼
Pod A  Pod B  Pod C

すべての Pod が同じ IAM ロールを利用します。

例えば、

• Pod A：Amazon S3 にアクセス
• Pod B：Amazon SNS にアクセス
• Pod C：Amazon DynamoDB にアクセス

という構成でも、3つの Pod が同じ権限を持ってしまいます。
これは、**最小権限の原則（Principle of Least Privilege）**の観点から望ましくありません。

IRSA の仕組み

IRSA を利用すると、Pod ごとに異なる IAM ロールを利用できます。

Pod A
 │
 ▼
ServiceAccount A
 │
 ▼
IAM Role A
 │
 ▼
Amazon S3


Pod B
 │
 ▼
ServiceAccount B
 │
 ▼
IAM Role B
 │
 ▼
Amazon SNS


Pod C
 │
 ▼
ServiceAccount C
 │
 ▼
IAM Role C
 │
 ▼
Amazon DynamoDB

このように、それぞれの Pod が必要な AWS リソースにのみアクセスできるようになります。

OIDC が必要な理由

IRSA では、OpenID Connect（OIDC） を利用して Kubernetes のサービスアカウントと IAM ロールを関連付けます。

流れは次のようになります。

1. EKS クラスターに OIDC プロバイダーを登録する
2. IAM ロールの信頼ポリシーに OIDC プロバイダーを設定する
3. Kubernetes のサービスアカウントに IAM ロールを関連付ける
4. Pod はサービスアカウントを利用して一時的な認証情報を取得する

長期間有効なアクセスキーを管理する必要がなく、安全に AWS リソースへアクセスできます。

IRSA の認証の流れ

IRSA では、EKSのPod Identity Webhook が対象の Pod に対して必要な情報を自動で設定します。

具体的には、Pod に以下の情報が注入されます。

• AWS_ROLE_ARN
• AWS_WEB_IDENTITY_TOKEN_FILE

Pod 内の AWS SDK は、このトークンファイル（JWT）を利用して AWS Security Token Service（STS）の AssumeRoleWithWebIdentity API を呼び出します。

その結果、一時的な認証情報（アクセスキー・シークレットキー・セッショントークン）が発行され、Pod は AWS リソースへ安全にアクセスできます。

この仕組みにより、アクセスキーを Pod 内に保持する必要がありません。

IAM 信頼ポリシー

IRSA では、IAM ロールの信頼ポリシー（Trust Policy）に OIDC プロバイダーを設定します。

さらに、Condition を利用することで、

• 特定の Namespace
• 特定の ServiceAccount

だけがその IAM ロールを利用できるよう制限できます。

これにより、Pod 単位でより細かなアクセス制御を実現できます。

IRSA のメリット

Pod ごとに権限を分離できる

各 Pod が必要な AWS リソースだけにアクセスできます。

セキュリティが向上する

アクセスキーを Pod 内に保存する必要がありません。

IAM ロールの一時的な認証情報を利用するため、漏えいリスクを低減できます。

最小権限の原則を実現できる

必要最低限の IAM 権限だけを付与できます。

IAM アクセスキーの管理が不要

アクセスキーの発行やローテーションが不要になります。

IRSA と EC2 インスタンスロールの違い

項目	EC2 インスタンスロール	IRSA
権限の単位	EC2 インスタンス	Pod（サービスアカウント）
IAM ロール	1つ	Pod ごとに設定可能
最小権限の実現	△	◎
OIDC	不要	必要
推奨	小規模構成	Amazon EKS のベストプラクティス

EKS Pod Identity との違い

2023 年には Amazon EKS Pod Identity も登場しました。

こちらは IRSA をより簡単に利用できるようにした仕組みで、OIDC プロバイダーの手動登録が不要になるなど、設定が簡素化されています。

ただし、IRSA は現在でも広く利用されており、AWS 認定試験や実務でも頻繁に登場する重要な仕組みです。

まとめ

IRSA（IAM Roles for Service Accounts）は、Amazon EKS 上で動作する Pod ごとに IAM ロールを付与する仕組みです。

特徴をまとめると、

• Pod ごとに IAM 権限を分離できる
• Kubernetes サービスアカウントと IAM ロールを関連付ける
• OIDC を利用して安全に認証する
• STS の AssumeRoleWithWebIdentity により一時的な認証情報を取得する
• IAM アクセスキーを管理する必要がない
• Amazon EKS のベストプラクティスとして推奨されている
• 後継として Amazon EKS Pod Identity も提供されている