EKS Pod Identity の関連付け - Eksctl ユーザーガイド
前提条件Pod Identity の関連付けの作成Pod Identity の関連付けの取得Pod Identity の関連付けの更新Pod Identity の関連付けの削除EKS アドオンによるポッド ID の関連付けのサポート既存の iamservice アカウントとアドオンをポッド ID の関連付けに移行するクロスアカウント Pod ID のサポートその他のリファレンス

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

EKS Pod Identity の関連付け

Amazon EKS は、クラスター管理者がクラスター外の AWS サービスに接続するために必要な IAM アクセス許可を受け取るように Kubernetes アプリケーションを設定するために、Pod Identity Association と呼ばれる新しい拡張メカニズムを導入しました。Pod Identity Association は IRSA を活用していますが、EKS API から直接設定できるため、IAM API を完全に使用する必要がなくなります。

その結果、IAM ロールは OIDC プロバイダーを参照する必要がなくなり、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 信頼ポリシーの例を以下に示します。

# Error: No files found with UUID: 44d1085a-03ca-431a-9774-b786a9774200

代わりに、既存のロールの ARN を create コマンドに提供しない場合、 eksctlはバックグラウンドでロールを作成し、上記の信頼ポリシーを設定します。

Pod Identity の関連付けの作成

ポッド ID の関連付けを操作するために、 eksctlは iam.podIdentityAssociationsに新しいフィールドを追加しました。例:

iam:
  podIdentityAssociations:
  - namespace: <string> #required
    serviceAccountName: <string> #required
    createServiceAccount: true #optional, default is false
    roleARN: <string> #required if none of permissionPolicyARNs, permissionPolicy and wellKnownPolicies is specified. Also, cannot be used together with any of the three other referenced fields.
    roleName: <string> #optional, generated automatically if not provided, ignored if roleARN is provided
    permissionPolicy: {} #optional
    permissionPolicyARNs: [] #optional
    wellKnownPolicies: {} #optional
    permissionsBoundaryARN: <string> #optional
    tags: {} #optional

完全な例については、pod-identity-associations.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 (単一の関連付けを削除するには) CLI フラグ--service-account-nameを介して --namespaceと を渡します。

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 設定を使用して引き続き提供されます。

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 の関連付けに移行するための eksctlutils コマンドがあります。つまり、

eksctl utils migrate-to-pod-identity --cluster my-cluster --approve

バックグラウンドでは、 コマンドは次のステップを適用します。

  • クラスターでまだアクティブでない場合は、eks-pod-identity-agentアドオンをインストールする

  • iamservice アカウントに関連付けられているすべての 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 ID のサポート

eksctl は EKS Pod Identity クロスアカウントアクセスをサポートしています。この機能を使用すると、EKS クラスターで実行されているポッドは、別の AWS アカウントの AWS リソースにアクセスできます。

使用方法

クロスアカウントアクセスでポッド ID の関連付けを作成するには、まず、ソース AWS アカウント (クラスターを使用) からターゲット AWS アカウント (クラスターがアクセスできるリソースを使用) へのアクセスを許可する IAM ロールとポリシーを設定します。この例については、「Amazon EKS Pod Identity がクロスアカウントアクセスを合理化する」を参照してください。

各アカウントで 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 サポート

ポッドアイデンティティの関連付けに関する AWS 公式ブログ投稿

Pod Identity Associations の公式 AWS ユーザードキュメント