サービスアカウントの IAM ロール - Amazon EKS

このページの改善にご協力ください

本ユーザーガイドの改善にご協力いただけませんか? このページの下部までスクロールし、[GitHub でこのページの編集] を選択します。皆さまにご協力いただくことで、あらゆる人々に使いやすいユーザーガイドになります。

サービスアカウントの IAM ロール

Pod のコンテナ内のアプリケーションは AWS SDK または AWS CLI で、AWS のサービス (IAM) アクセス許可を使用した AWS Identity and Access Management への API リクエストを行うことができます。アプリケーションは AWS 認証情報で AWS API リクエストに署名する必要があります。サービスアカウントの IAM ロールには、Amazon EC2 インスタンスプロファイルから Amazon EC2 インスタンスに認証情報を提供する場合と同じような方法で、アプリケーションの認証情報を管理する機能があります。AWS 認証情報を作成してコンテナに配布したり、Amazon EC2 インスタンスのロールを使用したりする必要はありません。IAM ロールを Kubernetes サービスアカウントと関連付けて、サービスアカウントを使用するように Pods を設定できます。AWS Outposts の Amazon EKS 用ローカルクラスターで、サービスアカウントに IAM ロールを使用することはできません。

サービスアカウントの IAM ロールには、次の利点があります。

  • 最小特権 – IAM アクセス許可の範囲をサービスアカウントに設定すると、そのサービスアカウントを使用する Pods のみにそのアクセス許可を付与できます。また、この機能により、kiamkube2iam などのサードパーティーのソリューションが不要になります。

  • 認証情報の分離 – Pod's のコンテナは、そのコンテナが使用するサービスアカウントに関連付けられた IAM ロールの認証情報のみを取得できます。コンテナは、他の Pods のコンテナで使われている認証情報にアクセスすることはできません。サービスアカウントの IAM ロールを使用する場合、Pod's コンテナには Amazon EKS ノード IAM ロール に割り当てられたアクセス許可も付与されます (Amazon EC2 インスタンスメタデータサービス (IMDS) への Pod のアクセスをブロックしていない場合)。詳細については、「ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する」を参照してください。

  • 監査性 - 遡及的な監査を確実に行うため、AWS CloudTrail を介してアクセスとイベントのロギングを利用できます。

以下の手順を実行してサービスアカウントの IAM ロールを有効にします。

  1. クラスターの IAM OIDC プロバイダーを作成する — この手順は、クラスタごとに 1 回だけ実行します。

    注記

    EKS VPC エンドポイントを有効にすると、その VPC 内から EKS OIDC サービスエンドポイントにアクセスできなくなります。そのため、VPC で eksctl を使用して OIDC プロバイダーを作成するなどの操作は機能せず、https://oidc.eks.region.amazonaws.com をリクエストしようとするとタイムアウトになります。エラーメッセージの例は次のとおりです。

    ** server can't find oidc.eks.region.amazonaws.com: NXDOMAIN

    このステップを完了するには、VPC の外部、たとえばインターネットに接続された AWS CloudShell 内またはコンピューター上でコマンドを実行します。または、Route 53 Resolver などのスプリットホライズン条件付きリゾルバーを VPC に作成して、OIDC 発行者 URL のために別のリゾルバーを使用し、VPC DNS は使用しないようにすることもできます。CoreDNS での条件付き転送の例については、GitHub の「Amazon EKS feature request」を参照してください。

  2. Kubernetes サービスアカウントへの IAM ロールの割り当て — この手順は、アプリケーションに付与する固有の権限セットごとに実行します。

  3. Kubernetes サービスアカウントを使用するように Pods を設定するには — この手順は、AWS のサービス へのアクセスが必要な Pod ごとに実行します。

  4. AWS SDK で IRSA を使用する — ワークロードがサポートされているバージョンの AWS SDK を使用していること、およびワークロードがデフォルトの認証情報チェーンを使用していることを確認します。

IAM、Kubernetes、および OpenID Connect (OIDC) の背景情報

2014 年に、AWS Identity and Access Management は OpenID Connect (OIDC) を使用したフェデレーティッドアイデンティティのサポートを追加しました。この機能により、サポートされている ID プロバイダーで AWS API コールを認証し、有効な OIDC JSON ウェブトークン (JWT) を受け取ることができます。このトークンを AWS STS AssumeRoleWithWebIdentity の API オペレーションに渡し、一時的な IAM ロールの認証情報を受け取ることができます。これらの認証情報を使用して、Amazon S3 や DynamoDB などの任意の AWS のサービスとやり取りできます。

各 JWT トークンは署名キーペアによって署名されます。キーは Amazon EKS が管理する OIDC プロバイダーで提供され、プライベートキーは 7 日ごとにローテーションされます。Amazon EKS はパブリックキーの有効期限が切れるまで保持します。外部 OIDC クライアントに接続する場合は、パブリックキーが期限切れになる前に、キーを更新する必要があることに注意してください。「OIDC トークンを検証するための署名キーを取得する」ではその方法を説明しています。

Kubernetes は、独自の内部アイデンティティシステムとして長い間、サービスアカウントを使用してきました。Pods は、Kubernetes API サーバーのみが検証できる自動マウントトークン (OIDC JWT ではない) を使用して Kubernetes API サーバーで認証できます。これらのレガシーサービスアカウントトークンは期限切れにならず、署名キーの更新は難しいプロセスです。Kubernetes バージョン 1.12 では、新しい ProjectedServiceAccountToken 機能のサポートが追加されました。この機能は、サービスアカウントアイデンティティを含む OIDC JSON ウェブトークンで、設定可能なオーディエンスをサポートします。

Amazon EKS は、ProjectedServiceAccountToken JSON ウェブトークンの署名キーを含むクラスターごとにパブリック OIDC 検出エンドポイントをホストするため、IAM などの外部システムで、Kubernetes によって発行された OIDC トークンを検証して受け入れることができます。