**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# サービスアカウントの IAM ロール
**ヒント**
今後開催予定の 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) の背景情報
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 トークンを検証して受け入れることができます。