KIAMとAWS IAMロールによるサービスアカウント（IRSA）

Kubernetesの採用がクラウドネイティブ環境で増加する中、Kubernetesクラスター内でAWS IAMロールを安全に管理することは、インフラ管理の重要な側面となっています。KIAMとサービスアカウント用のAWS IAMロール（IRSA）は、この要件を処理するための2つの人気のあるアプローチです。

この記事では、両方のツールのニュアンスを議論し、その機能、アーキテクチャ、利点、欠点を比較して、Kubernetes環境に適した情報に基づいた決定を下す手助けをします。

導入

• KIAM: AWSの認証情報をポッド内に保存することなく、KubernetesポッドにAWS IAMロールを動的に割り当てるために設計されたオープンソースソリューションです。KIAMは、AWSメタデータAPIリクエストを傍受するためにプロキシベースのアーキテクチャを使用します。AWS IAM
• IRSA: KubernetesサービスアカウントとOpenID Connect（OIDC）を利用して、IAMロールをKubernetesポッドに安全に関連付けるAWSの公式ソリューションです。IRSAは外部プロキシの必要性を排除します。

アーキテクチャとワークフロー

KIAM

コンポーネント

• エージェント – ワーカーノード上でDaemonSetとして実行され、ポッドからのAWSメタデータAPI呼び出しを傍受します。
• サーバー – IAMロールの検証とAWS APIとの相互作用を処理する中央集権的なコンポーネントです。

ワークフロー

1. ポッドのメタデータにはIAMロールのアノテーションが含まれています。
2. エージェントはメタデータAPIコールを傍受し、それをサーバーに転送します。
3. サーバーは役割を検証し、STSを介して一時的なAWS資格情報を取得します。
4. エージェントは資格情報をポッドのメタデータ応答に注入します。

IRSA

コンポーネント

• IAMロールARNで注釈が付けられたKubernetesサービスアカウント。
• AWS IAMに設定されたOIDCアイデンティティプロバイダー。

ワークフロー

1. サービスアカウントにIAMロールが注釈されます。
2. サービスアカウントを使用するポッドには、投影されたサービスアカウントトークンが発行されます。
3. AWS STSはOIDCアイデンティティプロバイダーを介してトークンを検証します。
4. ポッドは関連するIAMロールを引き受けます。

機能比較

利点と欠点

KIAMの利点

1. 柔軟性。非EKS Kubernetesクラスターで動作します。
2. 実績のあるユーティリティ。IRSAが導入される前から広く使用されていました。

KIAMの欠点

1. パフォーマンスのボトleneck。メタデータのインターセプトは、特に大規模クラスターで遅延の問題を引き起こす可能性があります。
2. スケーラビリティの制限。集中型サーバーがボトleneckになる可能性があります。
3. セキュリティリスク。追加のプロキシ層が攻撃面を広げます。
4. メンテナンスのオーバーヘッド。KIAMコンポーネントの管理と更新が必要です。

IRSAの利点

1. AWSネイティブ統合。シームレスな操作のために、ネイティブのAWS機能を活用します。
2. セキュリティの向上。認証情報は中間者なしでAWS STSを介して直接発行されます。
3. パフォーマンスの向上。プロキシのオーバーヘッドがなく、直接的なSTSインタラクションがあります。
4. スケーラブル。分散型の特性により、大規模クラスターに理想的です。

IRSAの欠点

1. AWS専用。マルチクラウドやハイブリッド環境には適していません。
2. 初期学習曲線。OIDCおよびサービスアカウントの設定を理解する必要があります。

ユースケース

KIAMを使用するタイミング

• 非EKS Kubernetesクラスター。
• レガシーシステムがKIAMの特定の機能に依存するシナリオ。

IRSAの使用時期

• AWS上で実行されているEKSクラスターまたはKubernetes環境。
• スケーラビリティ、高パフォーマンス、メンテナンスオーバーヘッドの削減を必要とするユースケース。
• 攻撃対象面を最小限に抑えることを求められるセキュリティに敏感な環境。

KIAMからIRSAへの移行

現在KIAMを使用していてIRSAに移行したい場合、以下のステップバイステップのアプローチを参考にしてください：

1. クラスターにOIDCを有効にする

EKSで、AWS Management ConsoleまたはCLIを使用してOIDCプロバイダーを有効にします。

2. サービスアカウントを注釈付けする

ポッド内のIAMロール注釈をサービスアカウント内の注釈に置き換えます。

3. IAMロールを更新する

OIDCアイデンティティプロバイダーをIAMロールの信頼ポリシーに追加します。

4. テストと確認

テストワークロードをデプロイして、ロールがIRSAを介して正しく引き受けられることを確認します。

5. KIAMを廃止する

移行が成功した後、KIAMコンポーネントを段階的に廃止します。

移行のベストプラクティス

• 重要でないワークロードから始めて、段階的に移行を行います。
• 変更を本番環境に適用する前に、ステージング環境で検証します。
• AWS CloudWatchのメトリクスとログを監視して、移行中の潜在的な問題を特定します。
• TerraformやAWS CDKのような自動化ツールを活用して、セットアップと構成を効率化しましょう。

実世界の例

KIAMの実績

• レガシーシステム – KIAMがさまざまな環境との互換性により関連性を持つ非EKSクラスターを使用する組織
• ハイブリッドワークロード – オンプレミスとクラウドプラットフォームにまたがってワークロードを実行している企業

IRSAの成功事例

• モダンアプリケーション – AWS EKS環境でシームレスなスケーリングと強化されたセキュリティのためにIRSAを活用するスタートアップ
• エンタープライズ導入 – メンテナンスのオーバーヘッドが削減され、AWSとのネイティブ統合が利益をもたらす大規模Kubernetesクラスターを持つ企業

結論

KIAMはその当時、画期的なツールでしたが、AWS上で稼働するKubernetes環境におけるIAMロール管理のための好ましい解決策としてAWS IAM Roles for Service Accounts (IRSA)が登場しました。IRSAはネイティブサポート、優れたパフォーマンス、改善されたセキュリティ、およびスケーラビリティを提供し、モダンなクラウドネイティブアーキテクチャにとって優れた選択肢となっています。

AWS上のKubernetesクラスターにおいては、IRSAが最適な選択肢であるべきです。ただし、AWS外で運用する場合やハイブリッド環境においては、KIAMや代替ツールが依然として関連性を持つかもしれません。

インフラストラクチャアーキテクト、DevOpsエンジニア、Kubernetes愛好者の皆様へ、この比較分析は、彼らの環境に最適なソリューションを選ぶために必要な洞察を提供することを目的としています。より深い技術的洞察や実用的なガイドが必要な場合は、お気軽にお問い合わせください。