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

「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」

サービスアカウントの技術概要の IAM ロール

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

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

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

IAM ロールの設定

IAM では、クラスターの OIDC プロバイダー、サービスアカウント名前空間、および(オプションで)サービスアカウント名に限定された信頼関係を持つ IAM ロールを作成し、サービスアカウントに関連付ける IAM ポリシーをアタッチします。以下の StringEquals および StringLike 条件に複数のエントリを追加して、ロールで複数のサービスアカウントまたは名前空間を使用できます。

  • ロールを特定のサービスアカウントに絞り出すには:

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::<AWS_ACCOUNT_ID>:oidc-provider/<OIDC_PROVIDER>" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "<OIDC_PROVIDER>:sub": "system:serviceaccount:<SERVICE_ACCOUNT_NAMESPACE>:<SERVICE_ACCOUNT_NAME>" } } } ] }
  • ロールを名前空間全体にスコープするには(名前空間を境界として使用するため):

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::<AWS_ACCOUNT_ID>:oidc-provider/<OIDC_PROVIDER>" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringLike": { "<OIDC_PROVIDER>:sub": "system:serviceaccount:<SERVICE_ACCOUNT_NAMESPACE>:*" } } } ] }

サービスアカウント設定

Kubernetes では、eks.amazonaws.com/role-arn 注釈をサービスアカウントに追加することで、クラスター内のサービスアカウントに関連付ける IAM ロールを定義します。

apiVersion: v1 kind: ServiceAccount metadata: annotations: eks.amazonaws.com/role-arn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/<IAM_ROLE_NAME>

ポッドの設定

クラスターの Amazon EKSPod Identity Webhook は、この注釈を持つサービスアカウントに関連付けられているポッドを監視し、以下の環境変数をそれらに適用します。

AWS_ROLE_ARN=arn:aws:iam::<AWS_ACCOUNT_ID>:role/<IAM_ROLE_NAME> AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token
注記

クラスターでは、環境変数とトークンファイルのマウントを設定するために、mutating なウェブフックを使用する必要はありません。これらの環境変数を手動で追加するようにポッドを設定できます。

重要

変更ウェブフックを使用するか、環境変数を手動で設定するかに関係なく、リージョンのサービスアカウントに IAM ロールを使用するすべてのポッドに次の環境変数を追加する必要があります。中国

AWS_DEFAULT_REGION=<region-code>

SDK のサポートされているバージョンAWSは、最初に認証情報チェーンプロバイダーでこれらの環境変数を探します。ロールの認証情報は、この条件を満たすポッドに使用されます。

注記

ポッドがサービスアカウントに関連付けられた IAM ロールの AWS 認証情報を使用する場合、 AWS CLIまたはそのポッドのコンテナSDKs内の他のユーザーは、そのロールによって提供される認証情報を排他的に使用します。ノードIAMロールからIAMアクセス権限を継承しなくなります。

デフォルトでは、root として実行されるコンテナにのみ、Web ID トークンファイルを読み取るための適切なファイルシステムアクセス許可があります。コンテナを root として実行するか、マニフェスト内のコンテナに以下のセキュリティコンテキストを渡すことで、これらのアクセス許可を付与できます。fsGroup ID は任意であり、いずれかの有効なグループ ID を選択できます。ポッドにセキュリティコンテキストを設定することの意味の詳細については、Kubernetes ドキュメントの「Configure a Security Context for a Pod or Container」を参照してください。

apiVersion: apps/v1 kind: Deployment metadata: name: <my-app> spec: template: metadata: labels: app: <my-app> spec: serviceAccountName: <my-app> containers: - name: <my-app> image: <my-app>:latest securityContext: fsGroup: <1337> ...

はポッドに代わってトークンkubeletをリクエストして保存します。デフォルトでは、 は、合計 TTL の 80 パーセントより古い場合、またはトークンが 24 時間より古い場合、トークンkubeletを更新します。ポッド仕様の設定を使用して、デフォルトのサービスアカウント以外のすべてのアカウントの有効期限を変更できます。詳細については、Kubernetes ドキュメントの「Service Account Token Volume Projection」を参照してください。

クロスアカウント IAM アクセス許可

クロスアカウントのIAMアクセス許可を設定するには、別のアカウントのクラスターから ID プロバイダーを作成するか、連鎖AssumeRoleオペレーションを使用します。次の例では、アカウント A は、サービスアカウントの IAM ロールをサポートする Amazon EKS クラスターを所有しています。そのクラスターで実行されているポッドは、アカウント B の IAM アクセス許可を引き受ける必要があります。

例 : 別のアカウントのクラスターから ID プロバイダーを作成する

この例では、アカウント A はアカウント B にクラスターからの OIDC 発行者 URL を提供します。アカウント B は、アカウント A のクラスターからの OIDC 発行者 URL を使用して、クラスターでのサービスアカウントの IAM ロールの有効化 および サービスアカウントの IAM ロールとポリシーの作成 の手順に従います。次に、クラスター管理者は、アカウント A のクラスターのサービスアカウントに注釈を付けて、アカウント B のロールを使用します。

apiVersion: v1 kind: ServiceAccount metadata: annotations: eks.amazonaws.com/role-arn: arn:aws:iam::<ACCOUNT_B_AWS_ACCOUNT_ID>:role/<IAM_ROLE_NAME>

例 : 連鎖された AssumeRole オペレーションを使用する

この例では、アカウント B は、アカウント A のクラスターのポッドに付与するアクセス許可を持つ IAM ポリシーを作成します。アカウント B は、以下に示すように、アカウント A (111111111111) への AssumeRole アクセス許可を許可する信頼関係を持つ IAM ロールにそのポリシーをアタッチします。

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

アカウント A は、次に示すように、クラスターの OIDC 発行者 URL で作成された ID プロバイダーから認証情報を取得する信頼ポリシーを持つロールを作成します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111111111111:oidc-provider/oidc.eks.<region-code>.amazonaws.com/id/EXAMPLEC061A78C479E31025A21AC4CDE191335D05820BE5CE" }, "Action": "sts:AssumeRoleWithWebIdentity" } ] }

アカウント A は、アカウント B が作成したロールを引き受けるための以下のアクセス許可を持つポリシーをそのロールにアタッチします。

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

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

[profile account_b_role] source_profile = account_a_role role_arn=arn:aws:iam::222222222222: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::111111111111:role/account-a-role

他の AWS SDKs の連鎖されたプロファイルを指定するには、そのドキュメントを参照してください。