**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# Kubernetes ワークロードに Kubernetes サービスアカウントを使用して AWS へのアクセスを許可する
[サービスアカウントの管理](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin)[サービスアカウントの IAM ロール](iam-roles-for-service-accounts.md)[EKS Pod Identity が Pod に AWS サービスへのアクセス権を付与する仕組みを学ぶ](pod-identities.md)
## サービスアカウントトークン
[BoundServiceAccountTokenVolume](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume) 機能は、Kubernetes バージョンでデフォルトで有効になっています。この機能により、Kubernetes で実行されているワークロードは、対象者、時間、および鍵に紐付けされた JSON ウェブトークンをリクエストできるようになり、サービスアカウントトークンのセキュリティが向上します。サービスアカウントトークンの有効期限は 1 時間です。Kubernetes の以前のバージョンでは、トークンに有効期限はありませんでした。つまり、これらのトークンに依存するクライアントは 1 時間以内にトークンを更新する必要があります。以下の [Kubernetes クライアント SDK](https://kubernetes.io/docs/reference/using-api/client-libraries/) は、必要な期間内にトークンを自動的に更新します。
+ Go バージョン `0.15.7` 以降
+ Python バージョン `12.0.0` 以降
+ Java バージョン `9.0.0` 以降
+ JavaScript バージョン `0.10.3` 以降
+ Ruby `master` ブランチ
+ Haskell バージョン`0.3.0.0`
+ C\$1 バージョン `7.0.5` 以降
ワークロードで古いバージョンのクライアントを使用している場合は、更新する必要があります。有効期限付きの新しいサービスアカウントトークンにクライアントがスムーズに移行できるようにするため、Kubernetes ではデフォルトの 1 時間を超えてサービスアカウントトークンの有効期限が延長されます。Amazon EKS クラスターの場合、延長できる有効期限は 90 日です。Amazon EKS クラスターの Kubernetes API サーバーでは、90 日を超えるトークンのリクエストは拒否されます。アプリケーションとその依存関係を確認し、Kubernetes クライアント SDK が前記のバージョンと同じかそれ以降であることを確認することをお勧めします。
API サーバーが 1 時間を超える古いトークンによるリクエストを受信すると、API 監査ログイベントに `annotations.authentication.k8s.io/stale-token` で注釈を付けます。注釈の値は次の例のようになります。
```
subject: system:serviceaccount:common:fluent-bit, seconds after warning threshold: 4185802.
```
クラスターで [コントロールプレーンのログ記録](control-plane-logs.md) が有効になっている場合、注釈は監査ログに記録されます。以下の [CloudWatch Log Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) クエリを使用すると、Amazon EKS クラスター内で古いトークンを使っているすべての Pod を特定できます。
```
fields @timestamp
|filter @logStream like /kube-apiserver-audit/
|filter @message like /seconds after warning threshold/
|parse @message "subject: *, seconds after warning threshold:*\"" as subject, elapsedtime
```
`subject` は、Pod が使用したサービスアカウントを示します。`elapsedtime` は、最新のトークンを読み込んでからの経過時間 (秒単位) を示します。`elapsedtime` が 90 日 (7,776,000 秒間) を超えると、API サーバーへのリクエストは拒否されます。トークンの自動更新を行う前記のバージョンのいずれかを使用するよう、アプリケーションの Kubernetes クライアント SDK をプロアクティブに更新する必要があります。使用しているサービスアカウントトークンが 90 日に近く、トークンの有効期限が切れるまでクライアント SDK のバージョンを更新するのに十分な時間がない場合、既存の Pod を終了して新しい Pod を作成できます。サービスアカウントトークンが再フェッチされるので、クライアントバージョン SDK を更新するのに 90 日が追加されたことになります。
Pod がデプロイの一部である場合、高可用性を維持しながら Pod を終了する方法として、次のコマンドによるロールアウトの実行をお勧めします。*my-deployment* をデプロイの名前で置き換えます。
```
kubectl rollout restart deployment/my-deployment
```
## クラスターアドオン
以下のクラスターアドオンが更新され、サービスアカウントトークンを自動的に再フェッチする Kubernetes クライアント SDK が使用できるようになりました。リストされているバージョン、またはそれ以降のバージョンを、 クラスターにインストールすることをお勧めします。
+ Amazon VPC CNI Plugin for Kubernetes およびメトリクスヘルパーのプラグインのバージョン `1.8.0` 以降。現在のバージョンを確認したり、更新したりするには、[Amazon VPC CNI を使用して Pod に IP を割り当てる](managing-vpc-cni.md) および [cni-metrics-helper](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/cmd/cni-metrics-helper/README.md) を参照してください。
+ CoreDNS のバージョン `1.8.4` 以降。現在のバージョンを確認したり、更新したりするには、[Amazon EKS クラスターで DNS の CoreDNS を管理する](managing-coredns.md) を参照してください。
+ AWS ロードバランサーコントローラーのバージョン `2.0.0` 以降。現在のバージョンを確認したり、更新したりするには、[AWS Load Balancer Controller を使用してインターネットトラフィックをルーティングする](aws-load-balancer-controller.md) を参照してください。
+ 現在の `kube-proxy` バージョン 現在のバージョンを確認したり、更新したりするには、[Amazon EKS クラスターで `kube-proxy` を管理する](managing-kube-proxy.md) を参照してください。
+ AWS for Fluent Bit バージョン `2.25.0` 以降。現在のバージョンを更新するには、GitHub で「[Releases](https://github.com/aws/aws-for-fluent-bit/releases)」(リリース) を参照してください。
+ Fluentd イメージバージョン [1.14.6-1.2](https://hub.docker.com/r/fluent/fluentd/tags?page=1&name=v1.14.6-1.2) 以降、および Kubernetes メタデータバージョン [2.11.1](https://rubygems.org/gems/fluent-plugin-kubernetes_metadata_filter/versions/2.11.1) 以降用の Fluentd フィルタープラグイン。
## Amazon Elastic Kubernetes Service クラスター上のワークロードへの AWS Identity and Access Management 許可の付与
Amazon EKS には、Amazon EKS クラスターで実行されるワークロードに AWS Identity and Access Management 許可を付与する方法が 2 つあります。*サービスアカウント用の IAM ロール* と *EKS Pod Identity* です。
**サービスアカウントの IAM ロール**
*サービスアカウント用の IAM ロール (IRSA) * は、Amazon S3 バケットや Amazon DynamoDB テーブルなど、他の様々な AWS リソースにアクセスするためのきめ細かい IAM アクセス許可で AWS 上で動作する Kubernetes アプリケーションを構成します。同じ Amazon EKS クラスター内で複数のアプリケーションを同時に実行し、各アプリケーションに必要な最小限のアクセス権限のみを持たせることができます。IRSA は、Amazon EKS、Amazon EKS Anywhere、AWS での Red Hat OpenShift サービス、Amazon EC2 インスタンスでのセルフマネージド型 Kubernetes クラスターなどの、AWS でサポートされるさまざまな Kubernetes デプロイオプションをサポートするように構築されました。そのため、IRSA は IAM のような基本的な AWS サービスを使用して構築されており、Amazon EKS サービスや EKS API に直接依存することはありませんでした。詳細については、[サービスアカウントの IAM ロール](iam-roles-for-service-accounts.md) を参照してください。
**EKS Pod Identity**
EKS Pod Identity は、Amazon S3 バケット、Amazon DynamoDB テーブルなどのさまざまな AWS リソースにアクセスするためのアプリケーションを認証するためのシンプルなワークフローをクラスター管理者に提供します。EKS Pod Identity は EKS 専用であるため、クラスター管理者が Kubernetes アプリケーションを設定して IAM アクセス許可を取得する方法が簡単になります。これらの権限は、AWS マネジメントコンソール、EKS API、および AWS CLI から直接行う、より少ない手順で簡単に設定できるようになり、クラスター内のどの Kubernetes オブジェクトに対しても実行する必要がありません。クラスター管理者は EKS サービスと IAM サービスを切り替えたり、特権的な IAM オペレーションを使用してアプリケーションに必要な権限を設定したりする必要がありません。新しいクラスターを作成するときにロールの信頼ポリシーを更新しなくても、IAM ロールを複数のクラスターで使用できるようになりました。EKS Pod Identity が提供する IAM 認証情報には、クラスター名、名前空間、サービスアカウント名などの属性を含むロールセッションタグが含まれます。ロールセッションタグを使用すると、管理者は一致するタグに基づいて AWS リソースへのアクセスを許可することで、複数のサービスアカウントで機能する単一のロールを作成できます。詳細については、[EKS Pod Identity が Pod に AWS サービスへのアクセス権を付与する仕組みを学ぶ](pod-identities.md) を参照してください。
### EKS Pod Identity と IRSA の比較
大まかに言うと、EKS Pod Identity と IRSA はどちらも、Kubernetes クラスター上で実行されているアプリケーションに IAM アクセス許可を付与できるようにします。ただし、設定方法、サポートされる制限、有効になる機能は根本的に異なります。以下では、両ソリューションの重要な側面をいくつか比較します。
**注記**
AWS では、可能な限り EKS Pod Identity を使用して AWS リソースへのアクセスをポッドに許可することをお勧めします。詳細については、[EKS Pod Identity が Pod に AWS サービスへのアクセス権を付与する仕組みを学ぶ](pod-identities.md) を参照してください。
| 属性 | EKS Pod Identity | IRSA |
| --- | --- | --- |
| ロール拡張性 | 新しく導入された Amazon EKS サービスプリンシパル `pods.eks.amazonaws.com` との信頼を確立するには、各ロールを一度設定する必要があります。この 1 回限りのステップを済ませると、そのロールを新しいクラスターで使用するたびにそのロールの信頼ポリシーを更新する必要がなくなります。 | 新しいクラスターでロールを使用するたびに、IAM ロールの信頼ポリシーを新しい EKS クラスター OIDC プロバイダーエンドポイントで更新する必要があります。 |
| クラスターのスケーラビリティ | EKS Pod Identity では、ユーザーが IAM OIDC プロバイダーをセットアップする必要がないため、この制限は適用されません。 | 各 EKS クラスターには、OpenID Connect (OIDC) 発行者の URL が関連付けられています。IRSA を使用するには、IAM の EKS クラスターごとに固有の OpenID Connect プロバイダーを作成する必要があります。IAM のデフォルトのグローバル制限は、AWS アカウントにつき 100 の OIDC プロバイダーです。IRSA で AWS アカウントにつき 100 を超える EKS クラスターを使用する予定の場合は、IAM OIDC プロバイダーの制限に達します。 |
| ロールのスケーラビリティ | EKS Pod Identity では、ユーザーが信頼ポリシーで IAM ロールとサービスアカウント間の信頼関係を定義する必要がないため、この制限は適用されません。 | IRSA では、IAM ロールとサービスアカウント間の信頼関係を、ロールの信頼ポリシーで定義します。デフォルトでは、信頼ポリシーの長さは `2048` です。つまり、通常、1 つの信頼ポリシーで 4 つの信頼関係を定義できます。信頼ポリシーの長さの上限を増やすことはできますが、通常、1 つの信頼ポリシー内で作成できる信頼関係は最大 8 つに制限されます。 |
| STS API クォータの使用 | EKS Pod Identity は、ポッドへの AWS 認証情報の配信を簡素化し、AWS Security Token Service (STS) でコードを直接呼び出す必要はありません。EKS サービスはロールの引き受けを処理し、ポッドが AWS STS と通信したり STS API Quota を使用したりすることなく、ポッド内の AWS SDK を使用して記述されたアプリケーションに認証情報を配信します。 | IRSA では、ポッドの AWS SDK を使用して記述されたアプリケーションは、トークンを使用して AWS Security Token Service (STS) で `AssumeRoleWithWebIdentity` API を呼び出します。AWS SDK 上のコードのロジックによっては、コードが AWS STS への不必要な呼び出しを行い、スロットリングエラーを受信する可能性があります。 |
| ロールの再利用性 | EKS Pod Identity によって提供される一時的な AWS STS 認証情報には、クラスター名、名前空間、サービスアカウント名などのロールセッションタグが含まれます。ロールセッションタグを使用すると、管理者は、アタッチされたタグに基づいて AWS リソースへのアクセスを許可することで、複数のサービスアカウントで使用できる単一の IAM ロールを作成し、そのロールを有効な権限を変えることができます。これは、属性ベースのアクセス制御 (ABAC) とも呼ばれます。詳細については、[タグに基づいてポッドに AWS リソースへのアクセス権を付与する](pod-id-abac.md) を参照してください。 | AWS STS セッションタグはサポートされていません。ロールはクラスタ間で再利用できますが、すべてのポッドにそのロールのすべての権限が付与されます。 |
| サポートされている環境 | EKS Pod Identity は Amazon EKS でのみ使用できます。 | IRSA は、Amazon EKS、Amazon EKS Anywhere、AWS での Red Hat OpenShift サービス、Amazon EC2 インスタンスでのセルフマネージド型 Kubernetes クラスターなどに使用できます。 |
| サポートされている EKS バージョン | サポート対象のすべての EKS クラスターバージョン。特定のバージョンについては、[EKS Pod Identity クラスターバージョン](pod-identities.md#pod-id-cluster-versions) を参照してください。 | サポート対象のすべての EKS クラスターバージョン。 |