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

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

# 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)