翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # EKS Pod Identity の関連付け AWS EKS は、クラスター管理者がクラスター外の AWS サービスに接続するために必要な IAM アクセス許可を受け取るように Kubernetes アプリケーションを設定するために、Pod Identity Association と呼ばれる新しい拡張メカニズムを導入しました。Pod Identity Association は IRSA を活用しますが、EKS API から直接設定できるため、IAM API を完全に使用する必要がなくなります。 その結果、IAM ロールは [OIDC プロバイダー](iamserviceaccounts.md#iam-how-works)を参照する必要がなくなり、1 つのクラスターに関連付けられなくなります。つまり、IAM ロールを複数の EKS クラスターで使用できるようになりました。新しいクラスターが作成されるたびにロールの信頼ポリシーを更新する必要はありません。これにより、ロールの重複が不要になり、IRSA を完全に自動化するプロセスが簡素化されます。 ## 前提条件 バックグラウンドでは、ポッドアイデンティティの関連付けの実装は、ワーカーノードでデーモンセットとしてエージェントを実行しています。クラスターで前提条件エージェントを実行するために、EKS は EKS Pod Identity Agent と呼ばれる新しいアドオンを提供します。したがって、ポッド ID の関連付け (一般的に と `eksctl`) を作成するには、`eks-pod-identity-agent`クラスターにアドオンがプリインストールされている必要があります。このアドオンは、他のサポートされているアドオンと同じ方法で `eksctl` を使用して作成できます。 ``` eksctl create addon --cluster my-cluster --name eks-pod-identity-agent ``` さらに、ポッド ID 関連付けの作成時に既存の IAM ロールを使用する場合は、新しく導入された EKS サービスプリンシパル () を信頼するようにロールを設定する必要があります`pods.eks.amazonaws.com`。IAM 信頼ポリシーの例を以下に示します。 ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } ``` 代わりに、既存のロールの ARN を create コマンドに提供しない場合、 `eksctl`はバックグラウンドでロールを作成し、上記の信頼ポリシーを設定します。 ## Pod Identity の関連付けの作成 ポッド ID の関連付けを操作するために、 `eksctl`は `iam.podIdentityAssociations`に新しいフィールドを追加しました。例: ``` iam: podIdentityAssociations: - namespace: #required serviceAccountName: #required createServiceAccount: true #optional, default is false roleARN: #required if none of permissionPolicyARNs, permissionPolicy and wellKnownPolicies is specified. Also, cannot be used together with any of the three other referenced fields. roleName: #optional, generated automatically if not provided, ignored if roleARN is provided permissionPolicy: {} #optional permissionPolicyARNs: [] #optional wellKnownPolicies: {} #optional permissionsBoundaryARN: #optional tags: {} #optional ``` 完全な例については、[pod-identity-associations.yaml](https://github.com/eksctl-io/eksctl/blob/main/examples/39-pod-identity-association.yaml) を参照してください。 **注記** `permissionPolicy` がインラインポリシードキュメントとして使用されるのとは別に、他のすべてのフィールドには CLI フラグが付きます。 ポッド ID の関連付けは、次の方法で作成できます。クラスターの作成時に、設定ファイルの一部として目的のポッド ID の関連付けを指定し、以下を実行します。 ``` eksctl create cluster -f config.yaml ``` クラスターの作成後、 などの設定ファイルを使用します。 ``` eksctl create podidentityassociation -f config.yaml ``` OR CLI フラグの使用例: ``` eksctl create podidentityassociation \ --cluster my-cluster \ --namespace default \ --service-account-name s3-reader \ --permission-policy-arns="arn:aws:iam::111122223333:policy/permission-policy-1, arn:aws:iam::111122223333:policy/permission-policy-2" \ --well-known-policies="autoScaler,externalDNS" \ --permissions-boundary-arn arn:aws:iam::111122223333:policy/permissions-boundary ``` **注記** 一度にサービスアカウントに関連付けることができる IAM ロールは 1 つだけです。したがって、同じサービスアカウントに 2 番目のポッド ID の関連付けを作成しようとすると、エラーが発生します。 ## Pod Identity の関連付けの取得 特定のクラスターのすべてのポッド ID の関連付けを取得するには、次のいずれかのコマンドを実行します。 ``` eksctl get podidentityassociation -f config.yaml ``` OR ``` eksctl get podidentityassociation --cluster my-cluster ``` さらに、特定の名前空間内のポッド ID の関連付けのみを取得するには、 `--namespace`フラグを使用します。例: ``` eksctl get podidentityassociation --cluster my-cluster --namespace default ``` 最後に、特定の K8s サービスアカウントに対応する単一の関連付けを取得するには、上記のコマンド`--service-account-name`に も含めます。つまり、 ``` eksctl get podidentityassociation --cluster my-cluster --namespace default --service-account-name s3-reader ``` ## Pod Identity の関連付けの更新 1 つ以上のポッド ID 関連付けの IAM ロールを更新するには、新しい `roleARN(s)`を 設定ファイルに渡します。例: ``` iam: podIdentityAssociations: - namespace: default serviceAccountName: s3-reader roleARN: new-role-arn-1 - namespace: dev serviceAccountName: app-cache-access roleARN: new-role-arn-2 ``` と を実行します。 ``` eksctl update podidentityassociation -f config.yaml ``` OR (単一の関連付けを更新するため) は CLI フラグ`--role-arn`を介して新しい を渡します。 ``` eksctl update podidentityassociation --cluster my-cluster --namespace default --service-account-name s3-reader --role-arn new-role-arn ``` ## Pod Identity の関連付けの削除 1 つ以上のポッド ID の関連付けを削除するには、 `namespace(s)`と `serviceAccountName(s)`を 設定ファイルに渡します。例: ``` iam: podIdentityAssociations: - namespace: default serviceAccountName: s3-reader - namespace: dev serviceAccountName: app-cache-access ``` と を実行します。 ``` eksctl delete podidentityassociation -f config.yaml ``` OR (単一の関連付けを削除) は、 `--namespace`と を CLI フラグ`--service-account-name`経由で渡します。 ``` eksctl delete podidentityassociation --cluster my-cluster --namespace default --service-account-name s3-reader ``` ## EKS アドオンによるポッド ID の関連付けのサポート EKS アドオンは、EKS Pod Identity Associations を介した IAM アクセス許可の受信もサポートしています。設定ファイルには、これらを設定できる 3 つのフィールド `addon.podIdentityAssociations`、`addonsConfig.autoApplyPodIdentityAssociations`、 が公開されています`addon.useDefaultPodIdentityAssociations`。を使用して目的のポッド ID の関連付けを明示的に設定するか`addon.podIdentityAssociations`、 `addonsConfig.autoApplyPodIdentityAssociations`または を使用して推奨ポッド ID 設定`eksctl`を自動的に解決 (および適用) できます`addon.useDefaultPodIdentityAssociations`。 **注記** すべての EKS アドオンが起動時にポッド ID の関連付けをサポートするわけではありません。この場合、必要な IAM アクセス許可は [IRSA 設定](addons.md#addons-create)を使用して引き続き提供されます。 ### IAM アクセス許可を使用したアドオンの作成 IAM アクセス許可を必要とするアドオンを作成する場合、 `eksctl` はまず、ポッド ID の関連付けまたは IRSA 設定が設定ファイルの一部として明示的に設定されているかどうかを確認し、設定されている場合は、そのいずれかを使用してアドオンのアクセス許可を設定します。例: ``` addons: - name: vpc-cni podIdentityAssociations: - serviceAccountName: aws-node permissionPolicyARNs: ["arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"] ``` と の実行 ``` eksctl create addon -f config.yaml 2024-05-13 15:38:58 [ℹ] pod identity associations are set for "vpc-cni" addon; will use these to configure required IAM permissions ``` **注記** ポッド ID と IRSA の両方を同時に設定することは許可されず、検証エラーが発生します。 ポッド ID をサポートする EKS アドオンの場合、 `eksctl`はアドオンの作成時に推奨される IAM アクセス許可を自動的に設定するオプションを提供します。これは、設定ファイル`addonsConfig.autoApplyPodIdentityAssociations: true`で を設定するだけで実現できます。例: ``` addonsConfig: autoApplyPodIdentityAssociations: true # bear in mind that if either pod identity or IRSA configuration is explicitly set in the config file, # or if the addon does not support pod identities, # addonsConfig.autoApplyPodIdentityAssociations won't have any effect. addons: - name: vpc-cni ``` と の実行 ``` eksctl create addon -f config.yaml 2024-05-13 15:38:58 [ℹ] "addonsConfig.autoApplyPodIdentityAssociations" is set to true; will lookup recommended pod identity configuration for "vpc-cni" addon ``` 同様に、 などの CLI フラグを使用しても同じことができます。 ``` eksctl create addon --cluster my-cluster --name vpc-cni --auto-apply-pod-identity-associations ``` 推奨される IAM ポリシーでポッド ID を使用するように既存のアドオンを移行するには、 を使用します。 ``` addons: - name: vpc-cni useDefaultPodIdentityAssociations: true ``` ``` eksctl update addon -f config.yaml ``` ### IAM アクセス許可を使用したアドオンの更新 アドオンを更新する場合、 を指定する`addon.PodIdentityAssociations`と、更新オペレーションが完了した後にアドオンが持つべき状態の 1 つの信頼できるソースを表します。バックグラウンドでは、目的の状態を達成するためにさまざまなタイプのオペレーションが実行されます。つまり、 + 設定ファイルには存在するが、クラスターには存在しないポッドアイデンティティを作成する + 設定ファイルから削除された既存のポッド ID と関連する IAM リソースを削除する + 設定ファイルにも存在し、IAM アクセス許可のセットが変更された既存のポッド ID を更新する **注記** EKS アドオンが所有するポッド ID 関連付けのライフサイクルは、EKS アドオン API によって直接処理されます。 Amazon EKS アドオンで使用される関連付けに `eksctl update podidentityassociation` (IAM アクセス許可を更新するために) または `eksctl delete podidentityassociations` (関連付けを削除するために) を使用することはできません。代わりに、 `eksctl update addon`または `eksctl delete addon` が使用されます。 アドオンの初期ポッド ID 設定を分析することから、上記の例を見てみましょう。 ``` eksctl get podidentityassociation --cluster my-cluster --namespace opentelemetry-operator-system --output json [ { ... "ServiceAccountName": "adot-col-prom-metrics", "RoleARN": "arn:aws:iam::111122223333:role/eksctl-my-cluster-addon-adot-podident-Role1-JwrGA4mn1Ny8", # OwnerARN is populated when the pod identity lifecycle is handled by the EKS Addons API "OwnerARN": "arn:aws:eks:us-west-2:111122223333:addon/my-cluster/adot/b2c7bb45-4090-bf34-ec78-a2298b8643f6" }, { ... "ServiceAccountName": "adot-col-otlp-ingest", "RoleARN": "arn:aws:iam::111122223333:role/eksctl-my-cluster-addon-adot-podident-Role1-Xc7qVg5fgCqr", "OwnerARN": "arn:aws:eks:us-west-2:111122223333:addon/my-cluster/adot/b2c7bb45-4090-bf34-ec78-a2298b8643f6" } ] ``` 次に、次の設定を使用します。 ``` addons: - name: adot podIdentityAssociations: # For the first association, the permissions policy of the role will be updated - serviceAccountName: adot-col-prom-metrics permissionPolicyARNs: #- arn:aws:iam::aws:policy/AmazonPrometheusRemoteWriteAccess - arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy # The second association will be deleted, as it's been removed from the config file #- serviceAccountName: adot-col-otlp-ingest # permissionPolicyARNs: # - arn:aws:iam::aws:policy/AWSXrayWriteOnlyAccess # The third association will be created, as it's been added to the config file - serviceAccountName: adot-col-container-logs permissionPolicyARNs: - arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy ``` と の実行 ``` eksctl update addon -f config.yaml ... # updating the permission policy for the first association 2024-05-14 13:27:43 [ℹ] updating IAM resources stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-prom-metrics" for pod identity association "a-reaxk2uz1iknwazwj" 2024-05-14 13:27:44 [ℹ] waiting for CloudFormation changeset "eksctl-opentelemetry-operator-system-adot-col-prom-metrics-update-1715682463" for stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-prom-metrics" 2024-05-14 13:28:47 [ℹ] waiting for CloudFormation stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-prom-metrics" 2024-05-14 13:28:47 [ℹ] updated IAM resources stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-prom-metrics" for "a-reaxk2uz1iknwazwj" # creating the IAM role for the second association 2024-05-14 13:28:48 [ℹ] deploying stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-container-logs" 2024-05-14 13:28:48 [ℹ] waiting for CloudFormation stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-container-logs" 2024-05-14 13:29:19 [ℹ] waiting for CloudFormation stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-container-logs" # updating the addon, which handles the pod identity config changes behind the scenes 2024-05-14 13:29:19 [ℹ] updating addon # deleting the IAM role for the third association 2024-05-14 13:29:19 [ℹ] deleting IAM resources for pod identity service account adot-col-otlp-ingest 2024-05-14 13:29:20 [ℹ] will delete stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-otlp-ingest" 2024-05-14 13:29:20 [ℹ] waiting for stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-otlp-ingest" to get deleted 2024-05-14 13:29:51 [ℹ] waiting for CloudFormation stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-otlp-ingest" 2024-05-14 13:29:51 [ℹ] deleted IAM resources for addon adot ``` ポッド ID 設定が正しく更新されたことを確認するようになりました ``` eksctl get podidentityassociation --cluster my-cluster --output json [ { ... "ServiceAccountName": "adot-col-prom-metrics", "RoleARN": "arn:aws:iam::111122223333:role/eksctl-my-cluster-addon-adot-podident-Role1-nQAlp0KktS2A", "OwnerARN": "arn:aws:eks:us-west-2:111122223333:addon/my-cluster/adot/1ec7bb63-8c4e-ca0a-f947-310c4b55052e" }, { ... "ServiceAccountName": "adot-col-otlp-ingest", "RoleARN": "arn:aws:iam::111122223333:role/eksctl-my-cluster-addon-adot-podident-Role1-1k1XhAdziGzX", "OwnerARN": "arn:aws:eks:us-west-2:111122223333:addon/my-cluster/adot/1ec7bb63-8c4e-ca0a-f947-310c4b55052e" } ] ``` アドオンからすべてのポッド ID の関連付けを削除するには、 `[]`を明示的に に設定`addon.PodIdentityAssociations`する必要があります。例: ``` addons: - name: vpc-cni # omitting the `podIdentityAssociations` field from the config file, # instead of explicitly setting it to [], will result in a validation error podIdentityAssociations: [] ``` と の実行 ``` eksctl update addon -f config.yaml ``` ### IAM アクセス許可を持つアドオンの削除 アドオンを削除すると、アドオンに関連付けられているすべてのポッド ID も削除されます。クラスターを削除すると、すべてのアドオンで同じ効果が得られます。によって作成されたポッド ID の IAM ロールは`eksctl`、すべて削除されます。 ## 既存の iamservice アカウントとアドオンをポッド ID の関連付けに移行する サービスアカウントの既存の IAM ロールをポッド ID の関連付けに移行するための `eksctl`utils コマンドがあります。つまり、 ``` eksctl utils migrate-to-pod-identity --cluster my-cluster --approve ``` バックグラウンドでは、 コマンドは次のステップを適用します。 + クラスターでまだアクティブでない場合は、`eks-pod-identity-agent`アドオンをインストールする + iamserviceaccounts に関連付けられているすべての IAM ロールを識別する + ポッド ID の関連付けをサポートする EKS アドオンに関連付けられているすべての IAM ロールを識別する + 識別されたすべてのロールの IAM 信頼ポリシーを、新しい EKS サービスプリンシパルを指す追加の信頼されたエンティティで更新します (オプションで、出現する OIDC プロバイダーの信頼関係を削除します）。 + iamserviceaccounts に関連付けられたフィルタリングされたロールのポッド ID 関連付けを作成する + ポッド ID を使用して EKS アドオンを更新する (EKS API はバックグラウンドでポッド ID を作成します) `--approve` フラグなしでコマンドを実行すると、上記のステップを反映した一連のタスクで構成される計画のみが出力されます。例: ``` [ℹ] (plan) would migrate 2 iamserviceaccount(s) and 2 addon(s) to pod identity association(s) by executing the following tasks [ℹ] (plan) 3 sequential tasks: { install eks-pod-identity-agent addon, ## tasks for migrating the addons 2 parallel sub-tasks: { 2 sequential sub-tasks: { update trust policy for owned role "eksctl-my-cluster--Role1-DDuMLoeZ8weD", migrate addon aws-ebs-csi-driver to pod identity, }, 2 sequential sub-tasks: { update trust policy for owned role "eksctl-my-cluster--Role1-xYiPFOVp1aeI", migrate addon vpc-cni to pod identity, }, }, ## tasks for migrating the iamserviceaccounts 2 parallel sub-tasks: { 2 sequential sub-tasks: { update trust policy for owned role "eksctl-my-cluster--Role1-QLXqHcq9O1AR", create pod identity association for service account "default/sa1", }, 2 sequential sub-tasks: { update trust policy for unowned role "Unowned-Role1", create pod identity association for service account "default/sa2", }, } } [ℹ] all tasks were skipped [!] no changes were applied, run again with '--approve' to apply the changes ``` 既存の OIDC プロバイダーの信頼関係は、EKS アドオンに関連付けられた IAM ロールから常に削除されています。さらに、iamserviceaccounts に関連付けられた IAM ロールから既存の OIDC プロバイダーの信頼関係を削除するには、 `--remove-oidc-provider-trust-relationship`フラグを使用して コマンドを実行します。例: ``` eksctl utils migrate-to-pod-identity --cluster my-cluster --approve --remove-oidc-provider-trust-relationship ``` ## クロスアカウント Pod Identity サポート eksctl は [EKS Pod Identity クロスアカウントアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)をサポートしています。この機能を使用すると、EKS クラスターで実行されているポッドは、別の AWS アカウントの AWS リソースにアクセスできます。 ### 使用方法 クロスアカウントアクセスでポッド ID の関連付けを作成するには、まずソース AWS アカウント (クラスターを使用) からターゲット AWS アカウント (クラスターがアクセスできるリソースを使用) へのアクセスを許可する IAM ロールとポリシーを設定します。この例については、[「Amazon EKS Pod Identity がクロスアカウントアクセスを合理化する」を参照してください。](https://aws.amazon.com/blogs/containers/amazon-eks-pod-identity-streamlines-cross-account-access/) 各アカウントで IAM ロールを設定したら、eksctl を使用してポッド ID の関連付けを作成します。 ``` apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: # The cluster name and service account name should match the target # account policy's trust relationship. name: my-cluster region: us-west-2 version: "1.32" addons: - name: vpc-cni - name: coredns - name: kube-proxy - name: eks-pod-identity-agent iam: podIdentityAssociations: - namespace: default serviceAccountName: demo-app-sa createServiceAccount: true # The source role in the same account as the cluster roleARN: arn:aws:iam::1111111111:role/account-a-role # The target role in a different account targetRoleARN: arn:aws:iam::2222222222:role/account-b-role # Optional: Disable session tags disableSessionTags: false managedNodeGroups: - name: my-cluster instanceType: m6a.large privateNetworking: true minSize: 2 desiredCapacity: 2 maxSize: 3 ``` ## その他のリファレンス [ポッド ID の EKS アドオンの公式 AWS Userdocs サポート](https://docs.aws.amazon.com/eks/latest/userguide/add-ons-iam.html) [ポッドアイデンティティの関連付けに関する AWS 公式ブログ投稿](https://aws.amazon.com/blogs/aws/amazon-eks-pod-identity-simplifies-iam-permissions-for-applications-on-amazon-eks-clusters/) [Pod Identity Associations の公式 AWS ユーザードキュメント](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html)