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

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。

# サービスアカウントの IAM ロール
<a name="iam-roles-for-service-accounts"></a>

**ヒント**  
 今後開催予定の Amazon EKS ワークショップに[登録](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)してください。

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

サービスアカウントの IAM ロールには、次の利点があります。
+  **最小特権** – IAM アクセス許可の範囲をサービスアカウントに設定すると、そのサービスアカウントを使用する Pod にのみそのアクセス許可を付与できます。また、この機能により、`kiam` や `kube2iam` などのサードパーティーのソリューションが不要になります。
+  **認証情報の分離** – [Amazon EC2 インスタンスメタデータサービス (IMDS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) へのアクセスが制限されている場合、ポッド内のコンテナは、そのコンテナが使用するサービスアカウントに関連付けられている IAM ロールの認証情報のみを取得できます。コンテナは、他の Pod 内のコンテナで使われている認証情報にアクセスすることはできません。IMDS が制限されていない場合、ポッドのコンテナは「[Amazon EKS ノード IAM ロール](create-node-role.md)」にもアクセスでき、コンテナは同じノード上にある他のポッドの IAM ロールの認証情報にアクセスできる可能性があります。詳細については「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html#_identities_and_credentials_for_eks_pods_recommendations)」を参照してください。

**注記**  
`hostNetwork: true` で設定されたポッドは常に IMDS アクセスできますが、AWS SDK および CLI は有効にすると IRSA 認証情報が使用されます。
+  **監査性** – AWS CloudTrail にアクセスしイベントのログ記録を利用することで、遡及的な監査を確実に行えます。

**重要**  
コンテナはセキュリティ境界ではなく、サービスアカウントに IAM ロールを使用してもこの点は変更されません。同じノードに割り当てられたポッドはカーネルを共有し、ポッド設定によっては他のリソースも共有される可能性があります。別々のノードで実行されているポッドはコンピューティングレイヤーで分離されますが、Kubernetes API に対し個別のインスタンスの範囲を超えて追加のアクセス許可を持つノードアプリケーションがあります。例としては `kubelet`、`kube-proxy`、CSI ストレージドライバー、ユーザー独自の Kubernetes アプリケーションなどがあります。

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

1.  [クラスターの IAM OIDC プロバイダーを作成する](enable-iam-roles-for-service-accounts.md) – この手順は、クラスターごとに 1 回だけ実行する必要があります。
**注記**  
EKS VPC エンドポイントを有効にすると、その VPC 内から EKS OIDC サービスエンドポイントにアクセスできなくなります。そのため、VPC で `eksctl` を使用して OIDC プロバイダーを作成するなどの操作は機能せず、`https://oidc.eks.region.amazonaws.com` をリクエストしようとするとタイムアウトになります。エラーメッセージの例は次のとおりです。  

   ```
   server cant find oidc.eks.region.amazonaws.com: NXDOMAIN
   ```
このステップを完了するには、VPC の外部、たとえばインターネットに接続された AWS CloudShell 内またはコンピューター上でコマンドを実行します。または、Route 53 Resolver などのスプリットホライズン条件付きリゾルバーを VPC に作成して、OIDC 発行者 URL のために別のリゾルバーを使用し、VPC DNS は使用しないようにすることもできます。CoreDNS での条件付き転送の例については、GitHub の「[Amazon EKS feature request](https://github.com/aws/containers-roadmap/issues/2038)」を参照してください。

1.  [Kubernetes サービスアカウントに IAM ロールを割り当てる](associate-service-account-role.md) - この手順は、アプリケーションに付与する固有のアクセス許可のセットごとに実行します。

1.  [Kubernetes サービスアカウントを使用するように Pod を設定する](pod-configuration.md) – この手順は、AWS サービスへのアクセスを必要とする Pod ごとに実行します。

1.  [AWS SDK で IRSA を使用する](iam-roles-for-service-accounts-minimum-sdk.md) – ワークロードがサポートされているバージョンの AWS SDK を使用していること、およびワークロードがデフォルトの認証情報チェーンを使用していることを確認します。

## IAM、Kubernetes、OpenID Connect (OIDC) の背景情報
<a name="irsa-oidc-background"></a>

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

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

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

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

# クラスターの IAM OIDC プロバイダーを作成するには
<a name="enable-iam-roles-for-service-accounts"></a>

クラスターには、[OpenID Connect](https://openid.net/connect/) (OIDC) 発行者の URL が関連付けられています。サービスアカウントで AWS Identity and Access Management (IAM) ロールを使用するには、クラスターの OIDC 発行者 URL に対して IAM OIDC プロバイダーが存在している必要があります。

## 前提条件
<a name="_prerequisites"></a>
+ 既存の Amazon EKS クラスター。デプロイするには「[Amazon EKS の使用を開始する](getting-started.md)」を参照してください。
+ ご使用のデバイスまたは AWS CloudShell で、バージョン `2.12.3` 以降、または AWS コマンドラインインターフェイス (AWS CLI) のバージョン `1.27.160` 以降がインストールおよび設定されていること。現在のバージョンを確認するには「`aws --version | cut -d / -f2 | cut -d ' ' -f1`」を参照してください。`yum`、`apt-get`、macOS 用の Homebrew などのパッケージマネージャーは、多くの場合 AWS CLI の最新バージョンより数バージョン古くなっています。最新バージョンをインストールするには「*AWS コマンドラインインターフェイスユーザーガイド*」の「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」および「[aws configure を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。AWS クラウドシェル にインストールされている AWS CLI バージョンも最新バージョンより数バージョン遅れることがあります。更新するには、「*AWS CloudShell ユーザーガイド*」の「[ホームディレクトリへの AWS CLI のインストール](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)」を参照してください。
+ デバイスまたは AWS クラウドシェル に、`kubectl` コマンドラインツールがインストールされていること。バージョンはご使用のクラスターの Kubernetes バージョンと同じか、1 つ前のマイナーバージョン以前、あるいはそれより新しいバージョンが使用できます。例えば、クラスターのバージョンが `1.29` である場合、`kubectl` のバージョン `1.28`、`1.29`、または `1.30` が使用できます。`kubectl` をインストールまたはアップグレードする方法については「[`kubectl` および `eksctl` のセットアップ](install-kubectl.md)」を参照してください。
+ クラスター構成を含む既存の `kubectl` `config` ファイル。`kubectl` `config` ファイルの作成については、「[kubeconfig ファイルを作成して kubectl を EKS クラスターに接続する](create-kubeconfig.md)」を参照してください。

`eksctl` または AWS マネジメントコンソール を使用して、クラスターの IAM OIDC プロバイダーを作成できます。

## OIDC プロバイダーの作成 (eksctl)
<a name="_create_oidc_provider_eksctl"></a>

1. デバイスまたは AWS CloudShell にインストールされている `eksctl` コマンドラインツールのバージョン `0.215.0` 以降。`eksctl` をインストールまたはアップグレードするには`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。

1. クラスターの OIDC 発行者 ID を決定します。

   クラスターの OIDC 発行者 ID を取得し、変数に格納します。`<my-cluster>` を独自の値に置き換えます。

   ```
   cluster_name=<my-cluster>
   oidc_id=$(aws eks describe-cluster --name $cluster_name --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5)
   echo $oidc_id
   ```

1. クラスターの発行者 ID を持つ IAM OIDC プロバイダーが既にアカウントにあるかどうかを確認します。

   ```
   aws iam list-open-id-connect-providers | grep $oidc_id | cut -d "/" -f4
   ```

   出力が返された場合は、既にクラスター用の IAM OIDC プロバイダーが存在するため、次の手順をスキップできます。出力が返されない場合はクラスター用の IAM OIDC プロバイダーを作成する必要があります。

1. 次のコマンドを使用して、クラスターの IAM OIDC ID プロバイダーを作成します。

   ```
   eksctl utils associate-iam-oidc-provider --cluster $cluster_name --approve
   ```
**注記**  
EKS VPC エンドポイントを有効にすると、その VPC 内から EKS OIDC サービスエンドポイントにアクセスできなくなります。そのため、VPC で `eksctl` を使用して OIDC プロバイダーを作成するなどの操作は機能せず、タイムアウトします。エラーメッセージの例は次のとおりです。  

   ```
   ** server cant find oidc.eks.<region-code>.amazonaws.com: NXDOMAIN
   ```

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

## OIDC プロバイダーの作成 (AWS コンソール)
<a name="create_oidc_provider_shared_aws_console"></a>

1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)を開きます。

1. 左側ペインで、**[クラスター]** を選択し、**[クラスター]** ページでご自身のクラスターの名前を選択します。

1. **[概要]** タブの **[詳細]** セクションで、**[OpenID Connect プロバイダーの URL]** の値を書き留めます。

1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

1. 左のナビゲーションペインの **[アクセス管理]** で **[ID プロバイダー]** を選択します。[**プロバイダー**] がクラスターの URL と一致するリストに表示されている場合は、クラスターのプロバイダーがすでに存在します。クラスターの URL に一致するプロバイダーがリストにない場合、プロバイダーを作成する必要があります。

1. プロバイダーを作成するには、**[プロバイダーを追加]** を選択します。

1. **[プロバイダータイプ]** に、**[OpenID Connect]** を選択します。

1. **[プロバイダー URL]** に、クラスター用の OIDC プロバイダー URL 入力します。

1. **[対象者]** には `sts.amazonaws.com` を入力します。

1. （オプション) 任意のタグ、例えば、このプロバイダーのクラスターを特定するためのタグを追加します。

1. **[プロバイダーを追加]** をクリックします。

次のステップ: [IAM ロールを Kubernetes サービスアカウントに割り当てる](associate-service-account-role.md) 

# IAM ロールを Kubernetes サービスアカウントに割り当てる
<a name="associate-service-account-role"></a>

このトピックでは、AWS Identity and Access Management (IAM) ロール を引き受けるように Kubernetes サービスアカウントを設定する方法について説明します。任意の Pod はサービスアカウントを使用するように設定すると、ロールにアクセス許可がある AWS サービスすべてにアクセスできます。

## 前提条件
<a name="_prerequisites"></a>
+ 既存のクラスター。まだ所有していない場合は、[Amazon EKS の使用を開始する](getting-started.md) でのガイドのいずれかに従って作成できます。
+ クラスターの既存 IAM OpenID Connect (OIDC) プロバイダー 既に所有中かどうかの確認、または作成方法については「[クラスターの IAM OIDC プロバイダーを作成するには](enable-iam-roles-for-service-accounts.md)」を参照してください。
+ ご使用のデバイスまたは AWS CloudShell で、バージョン `2.12.3` 以降、または AWS コマンドラインインターフェイス (AWS CLI) のバージョン `1.27.160` 以降がインストールおよび設定されていること。現在のバージョンを確認するには「`aws --version | cut -d / -f2 | cut -d ' ' -f1`」を参照してください。`yum`、`apt-get`、macOS 用の Homebrew などのパッケージマネージャーは、多くの場合 AWS CLI の最新バージョンより数バージョン古くなっています。最新バージョンをインストールするには「*AWS コマンドラインインターフェイスユーザーガイド*」の「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」および「[aws configure を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。AWS クラウドシェル にインストールされている AWS CLI バージョンも最新バージョンより数バージョン遅れることがあります。更新するには、「*AWS CloudShell ユーザーガイド*」の「[ホームディレクトリへの AWS CLI のインストール](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)」を参照してください。
+ デバイスまたは AWS クラウドシェル に、`kubectl` コマンドラインツールがインストールされていること。バージョンはご使用のクラスターの Kubernetes バージョンと同じか、1 つ前のマイナーバージョン以前、あるいはそれより新しいバージョンが使用できます。例えば、クラスターのバージョンが `1.29` である場合、`kubectl` のバージョン `1.28`、`1.29`、または `1.30` が使用できます。`kubectl` をインストールまたはアップグレードする方法については「[`kubectl` および `eksctl` のセットアップ](install-kubectl.md)」を参照してください。
+ クラスター構成を含む既存の `kubectl` `config` ファイル。`kubectl` `config` ファイルの作成については、「[kubeconfig ファイルを作成して kubectl を EKS クラスターに接続する](create-kubeconfig.md)」を参照してください。

## ステップ 1: IAM ポリシーの作成
<a name="irsa-associate-role-procedure"></a>

既存の IAM ポリシーを IAM ロールに関連付ける場合は、次のステップにスキップします。

1. IAM ポリシーを作成します。ポリシーを自作することも、必要となるアクセス権限のいくつかが既に付与されている AWS 管理ポリシーをコピーし、特定の要件に応じてカスタマイズすることもできます。詳細については、「*IAM ユーザーガイド*」の「[IAM ポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。

1. Pod にアクセスさせる AWS サービスの権限を含むファイルを作成します。すべての AWS サービスに対するアクションの全リストについては、「[サービス認可リファレンス](https://docs.aws.amazon.com/service-authorization/latest/reference/)」を参照してください。

   次のコマンドを実行して、Amazon S3 バケットへの読み取り専用アクセスを許可するサンプルポリシーファイルを作成できます。必要に応じて、このバケットに設定情報またはブートストラップスクリプトを格納すると、Pod 内のコンテナがバケットからファイルを読み取り、アプリケーションにロードできます。このサンプルポリシーを作成する場合は、次のコンテンツをデバイスにコピーします。*my-pod-secrets-bucket* をバケット名に置き換え、コマンドを実行します。

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": "s3:GetObject",
               "Resource": "arn:aws:s3:::my-pod-secrets-bucket"
           }
       ]
   }
   ```

1. IAM ポリシーを作成します。

   ```
   aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json
   ```

## ステップ 2: IAM ロールを作成して関連付ける
<a name="_step_2_create_and_associate_iam_role"></a>

IAM ロールを作成し、Kubernetes サービスアカウントに関連付けます。`eksctl` または AWS CLI を使用できます。

### ロールの作成と関連付け (eksctl)
<a name="_create_and_associate_role_eksctl"></a>

この `eksctl` コマンドは指定された名前空間に Kubernetes サービスアカウントを作成し、指定された名前で (存在しない場合は) IAM ロールを作成し、既存の IAM ポリシー ARN をロールにアタッチし、サービスアカウントに IAM ロール ARN を注釈付けします。このコマンドのサンプルプレースホルダー値は、必ず特定の値に置き換えてください。`eksctl` をインストールまたはアップグレードするには`eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。

```
eksctl create iamserviceaccount --name my-service-account --namespace default --cluster my-cluster --role-name my-role \
    --attach-policy-arn arn:aws:iam::111122223333:policy/my-policy --approve
```

**重要**  
ロールまたはサービスアカウントが既に存在する場合、前のコマンドは失敗する可能性があります。`eksctl` には、そのような状況で使用できるさまざまなオプションがあります。詳細については、`eksctl create iamserviceaccount --help` を実行してください。

### ロールの作成と関連付け (AWS CLI)
<a name="create_and_associate_role_shared_aws_cli"></a>

IAM ロールを引き受ける既存の Kubernetes サービスアカウントがある場合は、この手順を省略できます。

1. Kubernetes サービスアカウントを作成します。次のコンテンツをデバイスにコピーします。*my-service-account* を目的の名前に置き換え、必要に応じて *default* を別の名前空間に置き換えます。*default* を変更する場合、名前空間は既に存在している必要があります。

   ```
   cat >my-service-account.yaml <<EOF
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: my-service-account
     namespace: default
   EOF
   kubectl apply -f my-service-account.yaml
   ```

1. 次のコマンドを使用して、AWS アカウント ID を環境変数に設定します。

   ```
   account_id=$(aws sts get-caller-identity --query "Account" --output text)
   ```

1. 次のコマンドを使用して、クラスターの OIDC ID プロバイダーを環境変数に設定します。*マイクラスター* の部分は自分のクラスター名に置き換えます。

   ```
   oidc_provider=$(aws eks describe-cluster --name my-cluster --region $AWS_REGION --query "cluster.identity.oidc.issuer" --output text | sed -e "s/^https:\/\///")
   ```

1. サービスアカウントの名前空間と名前の変数を設定します。*my-service-account* を、ロールを引き受けさせる Kubernetes サービスアカウントに置き換えます。*default* は、サービスアカウントの名前空間に置き換えます。

   ```
   export namespace=default
   export service_account=my-service-account
   ```

1. IAM ロール用の信頼ポリシーファイルを作成するには、次のコマンドを実行します。名前空間内のすべてのサービスアカウントにロールの使用を許可する場合は、次の内容をデバイスにコピーします。*StringEquals* を `StringLike` に置き換え、*\$1service\$1account* を `*` に置き換えます。以下の `StringEquals` または `StringLike` 条件に複数のエントリを追加して、複数のサービスアカウントまたは名前空間がロールを引き受けられるようにできます。クラスターが属するアカウントとは異なる AWS アカウントのロールがロールを引き受けられるようにする方法については、「[IRSA で別のアカウントに対して認証する](cross-account-access.md)」を参照してください。

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Federated": "arn:aws:iam::123456789012:oidc-provider/$oidc_provider"
         },
         "Action": "sts:AssumeRoleWithWebIdentity",
         "Condition": {
           "StringEquals": {
             "$oidc_provider:aud": "sts.amazonaws.com",
             "$oidc_provider:sub": "system:serviceaccount:$namespace:$service_account"
           }
         }
       }
     ]
   }
   ```

1. ロールを作成します。*my-role* を IAM ロールの名前に置き換え、*my-role-description* をロールの説明に置き換えます。

   ```
   aws iam create-role --role-name my-role --assume-role-policy-document file://trust-relationship.json --description "my-role-description"
   ```

1. IAM ポリシーをロールにアタッチします。*my-role* を IAM ロールの名前に置き換え、*my-policy* を、作成した既存のポリシーの名前に置き換えます。

   ```
   aws iam attach-role-policy --role-name my-role --policy-arn=arn:aws:iam::$account_id:policy/my-policy
   ```

1. サービスアカウントに、サービスアカウントで引き受ける IAM ロールの Amazon リソースネーム (ARN) の注釈を付けます。*my-role* を既存の IAM ロールの名前に置き換えます。前の手順で、クラスターが属するアカウントとは異なる AWS アカウントのロールに、ロールの引き受けを許可したと仮定します。その場合、AWS アカウントおよび他のアカウントからのロールを必ず指定してください。詳細については、「[IRSA で別のアカウントに対して認証する](cross-account-access.md)」を参照してください。

   ```
   kubectl annotate serviceaccount -n $namespace $service_account eks.amazonaws.com/role-arn=arn:aws:iam::$account_id:role/my-role
   ```

1. (オプション) [サービスアカウントの AWS Security Token Service エンドポイントを設定します](configure-sts-endpoint.md)。AWS では、グローバルエンドポイントの代わりにリージョン AWS STS エンドポイントを使用することをお勧めしています。これにより、レイテンシーが減少し、組み込みの冗長性が提供され、セッショントークンの有効性が向上します。

## ステップ 3: 設定を確認する
<a name="irsa-confirm-role-configuration"></a>

1. IAM ロールの信頼ポリシーが正しく設定されていることを確認します。

   ```
   aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
   ```

   出力例は次のとおりです。

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
               },
               "Action": "sts:AssumeRoleWithWebIdentity",
               "Condition": {
                   "StringEquals": {
                       "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account",
                       "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
                   }
               }
           }
       ]
   }
   ```

1. 前の手順でロールにアタッチしたポリシーが、そのロールにアタッチされていることを確認します。

   ```
   aws iam list-attached-role-policies --role-name my-role --query "AttachedPolicies[].PolicyArn" --output text
   ```

   出力例は次のとおりです。

   ```
                  arn:aws:iam::111122223333:policy/my-policy
   ```

1. 使用するポリシーの Amazon リソースネーム (ARN) を保存する変数を設定します。*my-policy* を、アクセス許可を確認するポリシーの名前に置き換えます。

   ```
   export policy_arn=arn:aws:iam::111122223333:policy/my-policy
   ```

1. ポリシーのデフォルトバージョンを確認します。

   ```
   aws iam get-policy --policy-arn $policy_arn
   ```

   出力例は次のとおりです。

   ```
   {
       "Policy": {
           "PolicyName": "my-policy",
           "PolicyId": "EXAMPLEBIOWGLDEXAMPLE",
           "Arn": "arn:aws:iam::111122223333:policy/my-policy",
           "Path": "/",
           "DefaultVersionId": "v1",
           [...]
       }
   }
   ```

1. ポリシーの内容を表示して、Pod で必要な権限がすべて含まれていることを確認します。必要であれば、次のコマンドの *1* を、前の出力で返されたバージョンに置き換えます。

   ```
   aws iam get-policy-version --policy-arn $policy_arn --version-id v1
   ```

   出力例は次のとおりです。

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": "s3:GetObject",
               "Resource": "arn:aws:s3:::my-pod-secrets-bucket"
           }
       ]
   }
   ```

   前の手順でサンプルポリシーを作成した場合、出力は同じになります。別のポリシーを作成した場合、*サンプル*の内容は異なります。

1. Kubernetes サービスアカウントにロールが注釈されていることを確認します。

   ```
   kubectl describe serviceaccount my-service-account -n default
   ```

   出力例は次のとおりです。

   ```
   Name:                my-service-account
   Namespace:           default
   Annotations:         eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-role
   Image pull secrets:  <none>
   Mountable secrets:   my-service-account-token-qqjfl
   Tokens:              my-service-account-token-qqjfl
   [...]
   ```

## 次のステップ
<a name="_next_steps"></a>
+  [Kubernetes サービスアカウントを使用するように Pod を設定するには](pod-configuration.md) 

# Kubernetes サービスアカウントを使用するように Pod を設定するには
<a name="pod-configuration"></a>

Pod が AWS サービスにアクセスする必要がある場合は、Kubernetes サービスアカウントを使用するように設定する必要があります。サービスアカウントは、AWS サービスにアクセスする権限がある AWS Identity and Access Management (IAM) ロールに関連付ける必要があります。
+ 既存のクラスター。まだ所有していない場合は、[Amazon EKS の使用を開始する](getting-started.md) でのガイドのいずれかを参照しながら作成できます。
+ クラスターの既存 IAM OpenID Connect (OIDC) プロバイダー 既に所有中かどうかの確認、または作成方法については「[クラスターの IAM OIDC プロバイダーを作成するには](enable-iam-roles-for-service-accounts.md)」を参照してください。
+ IAM ロールに関連付けられている既存の Kubernetes サービスアカウント。サービスアカウントには、IAM ロールの Amazon リソースネーム (ARN) の注釈を付ける必要があります。ロールには、Pod が AWS サービスを使用するアクセス許可を含む IAM ポリシーが関連付けられている必要があります。サービスアカウントとロールの作成および設定方法については、「[IAM ロールを Kubernetes サービスアカウントに割り当てる](associate-service-account-role.md)」を参照してください。
+ ご使用のデバイスまたは AWS CloudShell で、バージョン `2.12.3` 以降、または AWS コマンドラインインターフェイス (AWS CLI) のバージョン `1.27.160` 以降がインストールおよび設定されていること。現在のバージョンを確認するには「`aws --version | cut -d / -f2 | cut -d ' ' -f1`」を参照してください。`yum`、`apt-get`、macOS 用の Homebrew などのパッケージマネージャーは、多くの場合 AWS CLI の最新バージョンより数バージョン古くなっています。最新バージョンをインストールするには「*AWS コマンドラインインターフェイスユーザーガイド*」の「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」および「[aws configure を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。AWS クラウドシェル にインストールされている AWS CLI バージョンも最新バージョンより数バージョン遅れることがあります。更新するには、「*AWS CloudShell ユーザーガイド*」の「[ホームディレクトリへの AWS CLI のインストール](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software)」を参照してください。
+ デバイスまたは AWS クラウドシェル に、`kubectl` コマンドラインツールがインストールされていること。バージョンはご使用のクラスターの Kubernetes バージョンと同じか、1 つ前のマイナーバージョン以前、あるいはそれより新しいバージョンが使用できます。例えば、クラスターのバージョンが `1.29` である場合、`kubectl` のバージョン `1.28`、`1.29`、または `1.30` が使用できます。`kubectl` をインストールまたはアップグレードする方法については「[`kubectl` および `eksctl` のセットアップ](install-kubectl.md)」を参照してください。
+ クラスター構成を含む既存の `kubectl` `config` ファイル。`kubectl` `config` ファイルの作成については、「[kubeconfig ファイルを作成して kubectl を EKS クラスターに接続する](create-kubeconfig.md)」を参照してください。

  1. 次コマンドを使用して、Pod をデプロイして設定を確認できるデプロイマニフェストを作成します。example の値は独自の値に置き換えます。

     ```
     cat >my-deployment.yaml <<EOF
     apiVersion: apps/v1
     kind: Deployment
     metadata:
       name: my-app
     spec:
       selector:
         matchLabels:
           app: my-app
       template:
         metadata:
           labels:
             app: my-app
         spec:
           serviceAccountName: my-service-account
           containers:
           - name: my-app
             image: public.ecr.aws/nginx/nginx:X.XX
     EOF
     ```

  1. マニフェストをクラスターにデプロイします。

     ```
     kubectl apply -f my-deployment.yaml
     ```

  1. Pod に必要な環境変数が存在することを確認してください。

     1. 前の手順のデプロイ時にデプロイされた Pod を確認します。

        ```
        kubectl get pods | grep my-app
        ```

        出力例は次のとおりです。

        ```
        my-app-6f4dfff6cb-76cv9   1/1     Running   0          3m28s
        ```

     1. Pod が使用している IAM ロールの ARN を確認します。

        ```
        kubectl describe pod my-app-6f4dfff6cb-76cv9 | grep AWS_ROLE_ARN:
        ```

        出力例は次のとおりです。

        ```
        AWS_ROLE_ARN:                 arn:aws:iam::111122223333:role/my-role
        ```

        ロール ARN は、既存のサービスアカウントに注釈を付けたロール ARN と一致する必要があります。サービスアカウントへの注釈付けの詳細については、「[IAM ロールを Kubernetes サービスアカウントに割り当てる](associate-service-account-role.md)」を参照してください。

     1. Pod にウェブ ID トークンファイルのマウントがあることを確認します。

        ```
        kubectl describe pod my-app-6f4dfff6cb-76cv9 | grep AWS_WEB_IDENTITY_TOKEN_FILE:
        ```

        出力例は次のとおりです。

        ```
        AWS_WEB_IDENTITY_TOKEN_FILE:  /var/run/secrets/eks.amazonaws.com/serviceaccount/token
        ```

        `kubelet` が Pod に代わってトークンをリクエストして格納します。デフォルトで `kubelet` は、トークンが合計有効期限の 80% を超えている場合、またはトークンが 24 時間を超えている場合、そのトークンを更新します。Pod 仕様の設定を使用して、デフォルトのサービスアカウントを除くすべてのアカウントの有効期限を変更できます。詳細については、Kubernetes ドキュメントの「[Service Account Token Volume Projection (サービスアカウントトークンボリュームのプロジェクション)](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#serviceaccount-token-volume-projection)」を参照してください。

        クラスターの [Amazon EKS Pod Identity ウェブフック](https://github.com/aws/amazon-eks-pod-identity-webhook#amazon-eks-pod-identity-webhook)は、次の注釈が付いたサービスアカウントを使用している Pod をモニタリングします。

        ```
        eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-role
        ```

        このウェブフックは、そうした Pod に以前の環境変数を適用します。クラスターでは、環境変数とトークンファイルのマウントを設定するために、ウェブフックを使用する必要はありません。これらの環境変数を保持するよう、Pod を手動で設定できます。[AWS SDK のサポートされているバージョン](iam-roles-for-service-accounts-minimum-sdk.md)は、最初に認証情報チェーンプロバイダーでこれらの環境変数を探します。ロールの認証情報は、この条件を満たす Pod で使用されます。

  1. ロールにアタッチされた IAM ポリシーで割り当てたアクセス許可を使用して、Pod が AWS サービスとやり取りできることを確認します。
**注記**  
サービスアカウントに関連付けられた IAM ロールの AWS 認証情報を Pod が使用する場合、AWS CLI またはその Pod のコンテナ内にある他の SDK は、そのロールから提供される認証情報を使用します。[Amazon EKS ノードの IAM ロール](create-node-role.md)に提供された認証情報へのアクセスを制限しない場合、Pod は引き続きこれらの認証情報にアクセスできます。詳細については「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。

     Pod が想定通りにサービスとやり取りできない場合は、次の手順を実行して、すべてが正しく設定されていることを確認してください。

     1. OpenID Connect ウェブアイデンティティトークンファイルを介した IAM ロールの引き受けをサポートする AWS SDK バージョンを Pod が使用していることを確認します。詳細については、「[AWS SDK で IRSA を使用する](iam-roles-for-service-accounts-minimum-sdk.md)」を参照してください。

     1. デプロイがサービスアカウントを使用していることを確認します。

        ```
        kubectl describe deployment my-app | grep "Service Account"
        ```

        出力例は次のとおりです。

        ```
        Service Account:  my-service-account
        ```

     1. それでも Pod がサービスにアクセスできない場合は、「[Kubernetes サービスアカウントに IAM ロールを割り当てる](associate-service-account-role.md)」で説明されている[手順](associate-service-account-role.md#irsa-confirm-role-configuration)を参照して、ロールとサービスアカウントが正しく設定されていることを確認します。

# サービスアカウントの AWS Security Token Service エンドポイントを設定する
<a name="configure-sts-endpoint"></a>

Kubernetes サービスアカウントを[サービスアカウント用の IAM ロール](iam-roles-for-service-accounts.md)と共に使用している場合、そのサービスアカウントで使用される AWS Security Token Service エンドポイントのタイプを設定できます。

 AWS では、グローバルエンドポイントの代わりに地域の AWS STS エンドポイントを使用することを推奨しています。これにより、レイテンシーが減少し、組み込みの冗長性が提供され、セッショントークンの有効性が向上します。Pod が実行中の AWS リージョンで、AWS Security Token Service がアクティブであること。さらに、AWS リージョン内のサービスに障害が発生した場合に別の AWS リージョンを使用できるよう、アプリケーションに冗長性が組み込まれている必要があります。詳細については、IAM ユーザーガイドの「[AWS リージョンでの AWS STS の管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html)」を参照してください。
+ 既存のクラスター。まだ所有していない場合は、[Amazon EKS の使用を開始する](getting-started.md) でのガイドのいずれかを参照しながら作成できます。
+ クラスター用の既存の IAM OIDC プロバイダー。詳細については、「[クラスターの IAM OIDC プロバイダーを作成するには](enable-iam-roles-for-service-accounts.md)」を参照してください。
+ [サービスアカウント用の Amazon EKS IAM](iam-roles-for-service-accounts.md) 機能を使用するように設定された、既存の Kubernetes サービスアカウント。

次の例ではすべて、[Amazon VPC CNI プラグイン](cni-iam-role.md)で使用される aws-node Kubernetes サービスアカウントを使用しています。*example values* は、ご自身のサービスアカウント、ポッド、名前空間、その他のリソースに置き換えることができます。

1. エンドポイントを変更したいサービスアカウントを使用する Pod を選択します。Pod を実行する AWS リージョンを決定します。*aws-node-6mfgv* を Pod 名に置き換え、*kube-system* をポッドの名前空間に置き換えます。

   ```
   kubectl describe pod aws-node-6mfgv -n kube-system |grep Node:
   ```

   出力例は次のとおりです。

   ```
   ip-192-168-79-166.us-west-2/192.168.79.166
   ```

   前の出力では、Pod は us-west-2 AWS リージョンのノードで実行されています。

1. Pod のサービスアカウントが使用しているエンドポイントタイプを確認します。

   ```
   kubectl describe pod aws-node-6mfgv -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
   ```

   出力例は次のとおりです。

   ```
   AWS_STS_REGIONAL_ENDPOINTS: regional
   ```

   現在のエンドポイントがグローバルの場合、この出力には `global` が返されます。出力が返されない場合、デフォルトのエンドポイントタイプが、上書きされないまま使用されています。

1. クラスターまたはプラットフォームのバージョンが表に示されているバージョンと同じかそれ以降の場合は、次のコマンドのいずれかを使用して、サービスアカウントで使用されるエンドポイントタイプをデフォルトタイプから別のタイプに変更できます。*aws-node* は、サービスアカウントの名前に置き換え、*kube-system* は、サービスアカウントの名前空間に置き換えます。
   + デフォルトまたは現在のエンドポイントタイプがグローバルであり、それをリージョン別に変更する場合は、以下の手順を実行します。

     ```
     kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=true
     ```

     Pod のコンテナで実行されているアプリケーションで、事前署名された S3 URL を生成するために[サービスアカウントの IAM ロール](iam-roles-for-service-accounts.md)を使用している場合、リージョン別エンドポイントの URL の形式は、次の例のようになります。

     ```
     https://bucket.s3.us-west-2.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
     ```
   + デフォルトまたは現在のエンドポイントタイプがリージョン別であり、それをグローバルに変更する場合は、次の手順を実行します。

     ```
     kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=false
     ```

     アプリケーションが、AWS STS のグローバルエンドポイントに対し明示的にリクエストを行っており、Amazon EKS クラスターにおいて、リージョン別エンドポイントを使用する際のデフォルトの動作がオーバーライドされていない場合は、リクエストが失敗しエラーが返されます。詳細については、「[ポッドコンテナは次のエラーを受け取ります: `An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region`](security-iam-troubleshoot.md#security-iam-troubleshoot-wrong-sts-endpoint)」を参照してください。

     Pod のコンテナで実行されているアプリケーションで、事前署名された S3 URL を生成するために[サービスアカウントの IAM ロール](iam-roles-for-service-accounts.md)を使用している場合、グローバルエンドポイントの URL の形式は、次の例のようになります。

     ```
     https://bucket.s3.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
     ```

   使用している自動化処理で、事前署名付き URL に特定の形式を想定している場合、または事前署名付き URL を使用するアプリケーションやダウンストリームの依存関係に、ターゲットとして想定する AWS リージョンがある場合、適切な AWS STS エンドポイントを使用するために必要な変更を加えます。

1. 認証情報環境変数を適用するために、サービスアカウントに関連付けられている既存の Pod を削除して再作成します。変更するウェブフックは、既に実行されている Pod には適用されません *Pod*、*kube-system*、および *-l k8s-app=aws-node* を、アノテーションを設定する Pod の情報に置き換えることができます。

   ```
   kubectl delete Pods -n kube-system -l k8s-app=aws-node
   ```

1. Pod がすべて再起動したことを確認します。

   ```
   kubectl get Pods -n kube-system -l k8s-app=aws-node
   ```

1. Pod のいずれかの環境変数を表示します。`AWS_STS_REGIONAL_ENDPOINTS` の値が、以前のステップで設定した値であることを確認します。

   ```
   kubectl describe pod aws-node-kzbtr -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
   ```

   出力例は次のとおりです。

   ```
   AWS_STS_REGIONAL_ENDPOINTS=regional
   ```

# IRSA で別のアカウントに対して認証する
<a name="cross-account-access"></a>

別のアカウントのクラスターから ID プロバイダーを作成するか、連鎖した `AssumeRole` オペレーションを使用することで、クロスアカウントの IAM アクセス許可を設定できます。次の例では、*アカウント A* は、サービスアカウントの IAM ロールをサポートする Amazon EKS クラスターを所有しています。そのクラスターで実行されている Pod は、*アカウント B* の IAM アクセス許可を引き受ける必要があります。
+  **オプション 1** の方がシンプルですが、アカウント B でアカウント A のクラスターの OIDC ID プロバイダーを作成および管理する必要があります。
+  **オプション 2** は、OIDC が常にアカウント A で管理されますが、`AssumeRole` を 2 つ呼び出してロールチェイニングを行う必要があります。

## オプション 1: 別のアカウントのクラスターから ID プロバイダーを作成する
<a name="_option_1_create_an_identity_provider_from_another_accounts_cluster"></a>

この例では、アカウント A はアカウント B にクラスターからの OpenID Connect (OIDC) 発行者 URL を提供します。アカウント B は、アカウント A のクラスターからの OIDC 発行者 URL を使用して、「[クラスターの IAM OIDC プロバイダーを作成する](enable-iam-roles-for-service-accounts.md)」および「[IAM ロールを Kubernetes サービスアカウントに割り当てる](associate-service-account-role.md)」の手順に従います。次に、クラスター管理者は、アカウント A のクラスターのサービスアカウントに、アカウント B (*444455556666*) のロールを使用するように注釈を付けます。

```
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::444455556666:role/account-b-role
```

## オプション 2: 連鎖された `AssumeRole` オペレーションを使用する
<a name="_option_2_use_chained_assumerole_operations"></a>

このアプローチでは、アカウントごとに IAM ロールが作成されます。アカウント B のロールは、アカウント A を信頼します。アカウント A のロールは、OIDC フェデレーションを使用して、クラスターから認証情報を取得します。ポッドは、AWS CLI プロファイルを使用して、2 つのロールを連鎖させます。

### ステップ 1: アカウント B にターゲットロールを作成する
<a name="_step_1_create_the_target_role_in_account_b"></a>

アカウント B (*444455556666*) は、アカウント A のクラスター内のポッドで必要になるアクセス許可と共に IAM ロールを作成します。アカウント B は、このロールに目的のアクセス許可ポリシーをアタッチし、次の信頼ポリシーを追加します。

 **アカウント B のロール用の信頼ポリシー** — アカウント A の特定の IRSA ロールがこのロールを引き受けることを許可します。

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}
```

**重要**  
最小特権の場合、アカウントルート (`arn:aws:iam::111122223333:root`) を使用するのではなく、`Principal` ARN をアカウント A の特定のロール ARN に置き換えます。アカウントルートを使用すると、アカウント A の*いずれの* IAM プリンシパルもこのロールを引き受けることができます。

### ステップ 2: アカウント A に IRSA ロールを作成する
<a name="_step_2_create_the_irsa_role_in_account_a"></a>

アカウント A (*111122223333*) では信頼ポリシーを定義したロールを作成し、その信頼ポリシーではクラスターの OIDC 発行者アドレスで作成された ID プロバイダーから認証情報を取得することを許可します。

 **アカウント A のロール (OIDC フェデレーション) 用の信頼ポリシー** — EKS クラスターの OIDC プロバイダーがこのロールの認証情報を発行することを許可します。

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}
```

**重要**  
最小特権の場合、`sub` クレームの `StringEquals` 条件を追加して、このロールを特定の Kubernetes サービスアカウントに制限します。`sub` 条件がない場合、クラスター内のいずれのサービスアカウントもこのロールを引き受けることができます。`sub` 値では、`system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME ` という形式を使用します。例えば、`default` 名前空間で `my-service-account` という名前のサービスアカウントに制限するには、次のようにします。  

```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account"
```

### ステップ 3: アカウント A のロールに AssumeRole アクセス許可をアタッチする
<a name="_step_3_attach_the_assumerole_permission_to_account_as_role"></a>

アカウント A は、ステップ 2 で作成されたロールにアクセス許可ポリシーをアタッチします。このポリシーにより、ロールがアカウント B のロールを引き受けることが許可されます。

 **アカウント A のロール用のアクセス許可ポリシー** — アカウント B のターゲットロールに `sts:AssumeRole` を付与します。

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::444455556666:role/account-b-role"
        }
    ]
}
```

### ステップ 4: ロールを連鎖するようにポッドを設定する
<a name="_step_4_configure_the_pod_to_chain_roles"></a>

アカウント B のロールを引き受ける Pod のアプリケーションコードは、`account_b_role` と `account_a_role` の 2 つのプロファイルを使用します。`account_b_role` プロファイルでは、ソースとして `account_a_role` プロファイルを使用します。AWS CLI では、`~/.aws/config` ファイルは以下のようになります。

```
[profile account_b_role]
source_profile = account_a_role
role_arn=arn:aws:iam::444455556666:role/account-b-role

[profile account_a_role]
web_identity_token_file = /var/run/secrets/eks.amazonaws.com/serviceaccount/token
role_arn=arn:aws:iam::111122223333:role/account-a-role
```

他の AWS SDK の連鎖されたプロファイルを指定するには、使用する SDK のドキュメントを参照してください。詳細については、「[AWS で構築するツール](https://aws.amazon.com/developer/tools/)」を参照してください。

# AWS SDK で IRSA を使用する
<a name="iam-roles-for-service-accounts-minimum-sdk"></a>

**認証情報の使用**  
サービスアカウントの IAM ロール (IRSA) の認証情報を使用するために、コードで任意の AWS SDK を使用して SDK を含む AWS サービスのクライアントを作成できます。デフォルトでは、SDK は使用する AWS Identity and Access Management 認証情報を一連の場所で検索します。クライアントの作成時や SDK の初期化時に認証情報プロバイダーを指定しなかった場合は、サービスアカウントの認証情報用の IAM ロールが使用されます。

これがうまくいくのは、サービスアカウント用の IAM ロールがデフォルトの認証情報チェーンのステップとして追加されたからです。現在、ワークロードが認証情報チェーンの前にある認証情報を使用している場合は、同じワークロードのサービスアカウントに IAM ロールを設定しても、その認証情報は引き続き使用されます。

SDK は、`AssumeRoleWithWebIdentity` アクションを使用してサービスアカウント OIDC トークンを AWS Security Token Service からの一時的な認証情報と自動的に交換します。Amazon EKS とこの SDK アクションは、有効期限が切れる前に一時認証情報を更新することで、引き続きローテーションを行います。

[サービスアカウントの IAM ロール](iam-roles-for-service-accounts.md)を使用すると、Pod 内のコンテナは、OpenID Connect ウェブ ID トークンファイルを介した IAM ロールの引き受けをサポートする AWS SDK バージョンを使用する必要があります。お使いの AWS SDK には、必ず次のバージョン以降を使用してください。
+ Java (バージョン 2) – [2.10.11](https://github.com/aws/aws-sdk-java-v2/releases/tag/2.10.11) 
+ Java – [1.12.782](https://github.com/aws/aws-sdk-java/releases/tag/1.12.782) 
+  AWS SDK for Go v1 – [1.23.13](https://github.com/aws/aws-sdk-go/releases/tag/v1.23.13) 
+  AWS SDK for Go v2 – すべてのバージョンがサポートされています
+ Python (Boto3) – [1.9.220](https://github.com/boto/boto3/releases/tag/1.9.220) 
+ Python (botocore) – [1.12.200](https://github.com/boto/botocore/releases/tag/1.12.200) 
+  AWS CLI – [1.16.232](https://github.com/aws/aws-cli/releases/tag/1.16.232) 
+ ノード - [2.525.0](https://github.com/aws/aws-sdk-js/releases/tag/v2.525.0) と [3.27.0](https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.27.0) 
+ Ruby – [3.58.0](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md#3580-2019-07-01) 
+ C\$1\$1 – [1.7.174](https://github.com/aws/aws-sdk-cpp/releases/tag/1.7.174) 
+ .NET - [3.3.659.1](https://github.com/aws/aws-sdk-net/releases/tag/3.3.659.1) - `AWSSDK.SecurityToken` も含めることを確認します。
+ PHP – [3.110.7](https://github.com/aws/aws-sdk-php/releases/tag/3.110.7) 

[Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)、[AWS Load Balancer Controller を使用してインターネットトラフィックをルーティングする](aws-load-balancer-controller.md)、[Amazon VPC CNI plugin for Kubernetes](cni-iam-role.md) など、一般的な Kubernetes アドオンの多くは、サービスアカウントの IAM ロールをサポートしています。

サポートされている SDK を使用していることを確認するには、コンテナを構築する際に、「[AWS での構築ツール](https://aws.amazon.com/tools/)」で、希望する SDK のインストール手順に従ってください。

## 考慮事項
<a name="_considerations"></a>

### Java
<a name="_java"></a>

Java を使用する場合は、クラスパスに `sts` を含める*必要があります*。詳細については、Java SDK ドキュメントの「[WebIdentityTokenFileCredentialsProvider](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/WebIdentityTokenFileCredentialsProvider.html)」を参照してください。

# OIDC トークンを検証するための署名キーを取得する
<a name="irsa-fetch-keys"></a>

Kubernetes は、`ProjectedServiceAccountToken` を各 Kubernetes サービスアカウントに発行します。このトークンは OIDC トークンであり、さらに JSON ウェブトークン (JWT) の一種でもあります。Amazon EKS は、外部システムでトークンを検証できるように、トークンの署名キーを含むクラスターごとにパブリック OIDC エンドポイントをホストします。

`ProjectedServiceAccountToken` を検証するには、JSON ウェブキーセット (JWKS) とも呼ばれる OIDC パブリック署名キーを取得する必要があります。アプリケーションでこれらのキーを使用してトークンを検証します。例えば、[PyJWT Python ライブラリ](https://pyjwt.readthedocs.io/en/latest/)を使用して、これらのキーを使用してトークンを検証できます。`ProjectedServiceAccountToken` の詳細については、「[IAM、Kubernetes、OpenID Connect (OIDC) の背景情報](iam-roles-for-service-accounts.md#irsa-oidc-background)」を参照してください。

## 前提条件
<a name="_prerequisites"></a>
+ クラスターの既存の AWS Identity and Access Management (IAM) OpenID Connect (OIDC) プロバイダー。既に存在しているかどうかを確認する、または作成するには「[クラスターの IAM OIDC プロバイダーを作成するには](enable-iam-roles-for-service-accounts.md)」を参照してください。
+  **AWS CLI** – Amazon EKS など AWS のサービスを操作するためのコマンドラインツールです。詳細については、AWS コマンドラインインターフェイスユーザーガイドの「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」を参照してください。AWS CLI のインストール後は設定も行っておくことをお勧めします。詳細については、AWS コマンドラインインターフェイスユーザーガイドの「[aws configure を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config)」を参照してください。

## 手順
<a name="_procedure"></a>

1. AWS CLI を使用して、Amazon EKS クラスターの OIDC URL を取得します。

   ```
   $ aws eks describe-cluster --name my-cluster --query 'cluster.identity.oidc.issuer'
   "https://oidc.eks.us-west-2.amazonaws.com/id/8EBDXXXX00BAE"
   ```

1. curl または同様のツールを使用して、パブリック署名キーを取得します。結果は [JSON ウェブキーセット (JWKS)](https://www.rfc-editor.org/rfc/rfc7517#section-5) です。
**重要**  
Amazon EKS は、OIDC エンドポイントへの呼び出しをスロットリングします。パブリック署名キーをキャッシュする必要があります。レスポンスに含まれる `cache-control` ヘッダーを考慮します。
**重要**  
Amazon EKS は、OIDC 署名キーを 7 日ごとにローテーションします。

   ```
   $ curl https://oidc.eks.us-west-2.amazonaws.com/id/8EBDXXXX00BAE/keys
   {"keys":[{"kty":"RSA","kid":"2284XXXX4a40","use":"sig","alg":"RS256","n":"wklbXXXXMVfQ","e":"AQAB"}]}
   ```