サービスアカウントのIAMロール(IRSA)
IRSAを使用して細かく権限を設定したIAMロールをKubernetesサービスアカウントに関連付け、ノードレベルの権限なしでポッドからAWSサービスにアクセスできるようにします。
「サービスアカウントのIAMロール(IRSA)」はCoddyKit上の無料Cloud & IT Cert Prepレッスンです。 これはレッスン4/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはCloud & IT Cert Prep学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Cloud & IT Cert Prepコースには全4レッスンが含まれています。
Pod IAMの問題
EKSで実行されているPodがAWS APIを呼び出す場合、たとえばS3から読み取ったりDynamoDBに書き込んだりするには、AWS認証情報が必要です。単純な方法は、IAMユーザーを作成し、そのアクセスキーを環境変数としてハードコードすることです。しかし、これは安全ではなく、最小権限の原則にも反します。同じノード上のすべてのPodが認証情報を共有してしまうためです。IAM Roles for Service Accounts (IRSA)を使うと、きめ細かく設定したIAMロールをKubernetesのサービスアカウントに直接関連付けることで、この問題を解決できます。
IRSAの仕組み:OIDCフェデレーション
IRSAはOpenID Connect (OIDC)フェデレーションを通じて機能します。EKSはクラスター用のOIDCプロバイダーを作成します。PodがIAMロールARNでアノテーションされたサービスアカウントを参照すると、EKSは署名済みの投影サービスアカウントトークンをPodに注入します。Pod内のAWS SDKは、このトークンをAWS STSのAssumeRoleWithWebIdentity APIで一時的なAWS認証情報と交換します。長期間有効なキーは必要ありません。
# View the OIDC issuer URL for your cluster
aws eks describe-cluster \
--name my-cluster \
--query 'cluster.identity.oidc.issuer' \
--output text
# Example output:
# https://oidc.eks.us-east-1.amazonaws.com/id/EXAMPLEIDSTRINGステップ1:OIDCプロバイダーを関連付ける
IRSAを使用する前に、EKS OIDC発行者をAWSアカウント内の信頼されたアイデンティティプロバイダーとして関連付ける必要があります。これにより、AWS STSが認識するIAM OIDCプロバイダーリソースが作成されます。eksctlコマンドを使えば、この処理を自動的に実行できます。作成後は、IAMコンソールの「Identity Providers」で確認できます。
# Associate the OIDC provider using eksctl (simplest method)
eksctl utils associate-iam-oidc-provider \
--region us-east-1 \
--cluster my-cluster \
--approve
# Verify the provider was created
aws iam list-open-id-connect-providers \
--query 'OpenIDConnectProviderList[].Arn'ステップ2:IAMロールを作成する
IRSA用のIAMロールには、OIDCプロバイダーによるロールの引き受けを許可する信頼ポリシーが必要です。このポリシーは、特定のKubernetes名前空間とサービスアカウントに対象を限定します。条件ではOIDCトークンのsubクレームを使用します。この値はsystem:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAMEに設定されます。これにより、その特定のサービスアカウントを使用するPodだけがロールを引き受けられ、クラスター内のすべてのPodが引き受けられる状態を防げます。
# Trust policy for the IRSA role (JSON)
# {
# "Version": "2012-10-17",
# "Statement": [{
# "Effect": "Allow",
# "Principal": {
# "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLEID"
# },
# "Action": "sts:AssumeRoleWithWebIdentity",
# "Condition": {
# "StringEquals": {
# "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLEID:sub":
# "system:serviceaccount:production:s3-reader"
# }
# }
# }]
# }ステップ3:サービスアカウントにアノテーションを付ける
対象の名前空間にKubernetesのServiceAccountを作成し、IAMロールARNでアノテーションを付けます。Podがこのサービスアカウントを参照すると、EKSはOIDCトークンと2つの環境変数(AWS_WEB_IDENTITY_TOKEN_FILEおよびAWS_ROLE_ARN)を自動的に注入します。AWS SDKはこれらを自動的に検出し、STSを呼び出して一時的な認証情報を取得します。アプリケーションのコードを変更する必要はありません。
# Create and annotate the Kubernetes service account
kubectl create serviceaccount s3-reader -n production
kubectl annotate serviceaccount s3-reader \
-n production \
eks.amazonaws.com/role-arn=arn:aws:iam::111122223333:role/S3ReaderRole
# Verify the annotation
kubectl describe serviceaccount s3-reader -n productionステップ4:Podでサービスアカウントを参照する
Podまたはデプロイメントの仕様で、serviceAccountNameにアノテーション済みのサービスアカウントを設定します。EKSがPodをスケジュールすると、OIDCトークンが/var/run/secrets/eks.amazonaws.com/serviceaccount/tokenに自動的にマウントされ、必要な環境変数も設定されます。Pod内からAWS SDKを呼び出すと、明示的な認証情報の設定なしで、マッピングされたIAMロールの認証情報が透過的に使用されます。
# Pod spec using IRSA service account
apiVersion: v1
kind: Pod
metadata:
name: s3-app
namespace: production
spec:
serviceAccountName: s3-reader
containers:
- name: app
image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/my-app:latest
# AWS SDK auto-detects IRSA — no credential config needed
# AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN are injectedIRSAとノードIAMロールの違い
ノードIAMロールを使用すると、ノード上のすべてのPodが同じ権限を継承します。そのため、侵害されたPodから、ノードに許可されたすべてのAWSサービスへアクセスできてしまいます。一方、IRSAでは、各Podがサービスアカウントを介して必要なロールだけを引き受けます。これはPod単位で最小権限の原則に従う方法であり、セキュリティインシデントが発生した場合の影響範囲を限定できます。AWSは、すべての新しいEKSデプロイメントでノードレベルのロールよりIRSAを推奨しています。
eksctlを使用したIRSAロールの作成
eksctlを使うと、create iamserviceaccountを使用した1つのコマンドで、OIDCの関連付け、IAMロール、信頼ポリシー、Kubernetes ServiceAccountのアノテーションを作成できます。信頼ポリシーのJSONを手動で記述せずにIRSAを設定できる、最も簡単な方法です。名前空間、サービスアカウント名、アタッチするIAMポリシーARNを指定すれば、残りの処理はeksctlが実行します。
# Create everything needed for IRSA in one command
eksctl create iamserviceaccount \
--name s3-reader \
--namespace production \
--cluster my-cluster \
--attach-policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
--approve \
--override-existing-serviceaccountsAWSアドオンでのIRSA
多くのEKSアドオンやコントローラーは、動作にIRSAを必要とします。Cluster AutoscalerにはEC2 Auto Scaling APIを呼び出す権限が、AWS Load Balancer ControllerにはELBリソースを作成・管理する権限が、external-dnsにはRoute 53への書き込みアクセス権が、EBS CSI driverにはEBSボリュームを作成してアタッチする権限が必要です。これらのシステムコンポーネントには必ずIRSAを使用し、ノードIAMロールのレベルで権限を付与しないでください。
# Create IRSA for the EBS CSI driver
eksctl create iamserviceaccount \
--name ebs-csi-controller-sa \
--namespace kube-system \
--cluster my-cluster \
--attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
--approve \
--role-name AmazonEKS_EBS_CSI_DriverRoleトークンの更新と認証情報のローテーション
IRSAトークンは有効期間が短く、期限切れになる前にKubernetesのトークンプロジェクションコントローラーによって自動的にローテーションされます。デフォルトのトークンオーディエンスはsts.amazonaws.comで、有効期限は24時間ですが、コントローラーは有効期間の80%が経過した時点で更新します。IRSAで取得するAWS STS認証情報も一時的なもので、通常は1時間有効です。この自動ローテーションにより、長期間有効なIAMアクセスキーに伴う認証情報ローテーションの負担がなくなります。
# Inspect the projected service account token inside a pod
kubectl exec -n production s3-app -- \
cat /var/run/secrets/eks.amazonaws.com/serviceaccount/token
# Decode the JWT header and payload to see expiry and audience
# jwt.io or: base64 -d <<< "PAYLOAD_SECTION"CloudTrailによるIRSAの利用状況の監査
PodがIRSAを介してIAMロールを引き受けるたびに、AWS CloudTrailはAssumeRoleWithWebIdentityイベントを記録します。このイベントには、引き受けたロールARN、OIDCトークンのサブジェクト(system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT)、送信元IPが含まれます。これにより、どのPodがどのAWSサービスにいつアクセスしたかを完全に追跡できます。規制対象の環境におけるコンプライアンス対応やインシデント調査に不可欠です。
# Search CloudTrail for IRSA calls
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRoleWithWebIdentity \
--start-time '2024-01-01T00:00:00Z' \
--query 'Events[].{Time:EventTime,Role:CloudTrailEvent}' \
--output tableクイックチェック
このレッスンで扱ったAWS Solutions Architect (SAA-C03)の概念について、理解度を確認しましょう。
レッスンのまとめ
このレッスンでは、IRSAがOIDCフェデレーションを使用してKubernetesサービスアカウントトークンを一時的なAWS認証情報と交換すること、IAMロールの信頼ポリシーによって特定の名前空間とサービスアカウントにアクセスを限定できること、そしてIRSAがノードレベルのIAMロールよりもはるかに優れたPod単位の最小権限を実現することを学びました。次は、AWSリソースを監視するためのCloudWatchのメトリクス、名前空間、ディメンションについて学びます。
よくある質問
「サービスアカウントのIAMロール(IRSA)」レッスンは無料ですか?
はい。「サービスアカウントのIAMロール(IRSA)」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、Cloud & IT Cert Prepコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Cloud & IT Cert Prepコースには全4レッスンが含まれています。
「サービスアカウントのIAMロール(IRSA)」で何を学びますか?
IRSAを使用して細かく権限を設定したIAMロールをKubernetesサービスアカウントに関連付け、ノードレベルの権限なしでポッドからAWSサービスにアクセスできるようにします。 ブラウザで直接実行するハンズオンコードでCloud & IT Cert Prepを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
Cloud & IT Cert Prepを始めるのに経験は必要ですか?
事前経験は必要ありません。CoddyKitのCloud & IT Cert Prepは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン4/4です。
「サービスアカウントのIAMロール(IRSA)」レッスンにはどのくらい時間がかかりますか?
ほとんどのCoddyKitレッスンは約5~10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このCloud & IT Cert Prepレッスンでコードを書いて実行できますか?
はい。すべてのCloud & IT Cert Prepレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。
このコースのすべてのレッスン
- EKSコントロールプレーンとワーカーノード
- サーバーレスポッド向けFargateプロファイル
- EKSネットワーキング:VPC CNIとロードバランシング
- サービスアカウントのIAMロール(IRSA)