Upgrade to Pro — share decks privately, control downloads, hide ads and more …

EKS Pod Identity における推移的な session tags

Avatar for z63d z63d
August 21, 2025

EKS Pod Identity における推移的な session tags

JAWS-UG コンテナ支部 入門編 #8

Avatar for z63d

z63d

August 21, 2025
Tweet

More Decks by z63d

Other Decks in Technology

Transcript

  1. 自己紹介 中村 海太(なかむら かいた) 株式会社 primeNumber / SRE 普段は EKS、ECS

    などを使っています 関心領域: Kubernetes、コンテナ コンテナ周りの活動: youki、runwasi などの OSS コントリビューション X (Twitter): @z63d_
  2. 話すこと EKS Pod Identity とは session tags と ABAC について

    EKS Pod Identity への移行検証中に遭遇したエラー エラーへの対応
  3. EKS Pod Identity とは Pod に AWS サービスへのアクセス権を付与する機能 IAM role

    と Kubernetes ServiceAccount を関連付けることで、Pod(Kubernetes ServiceAccount) が AWS リソースにアクセスできるようにするしくみ IAM roles for service accounts (IRSA) に比べ新しい方法 IRSA を置き換えるものではないが、IRSA が必要なケース以外では EKS Pod Identity の使用が推 奨されている "Unless you have specific usecases for IRSA, we recommend you use EKS Pod Identities when using EKS." https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html IRSA のいくつかの課題を解決している
  4. IRSA との比較 IRSA EKS Pod Identity OIDC プロバイダー 必要 不要

    クレデンシャルの取得 Pod ごとに STS 呼び出し Node の Agent が集約処理 ABAC サポートなし session tags をサポート ロールの再利用性 再利用性が低い クラスター間で共通のプリンシパルや session tags によって再利用性が高い
  5. session tags とは IAM の一時的なクレデンシャルに付与される属性タグ 特徴: AssumeRole 時に role session

    に自動的に付与される IAM policy で参照可能な属性情報 できること: Attribute-based access control(ABAC) → 属性ベースのアクセス制御 tag ベースで動的に権限を制御できるため、 単一の policy を複数の role で再利用することなどが可能
  6. EKS Pod Identity の session tags 設定される session tags eks-cluster-arn

    eks-cluster-name kubernetes-namespace kubernetes-service-account kubernetes-pod-name kubernetes-pod-uid IAM policy での session tags の参照方法 ${aws:PrincipalTag/eks-cluster-name} のような形式で tag を参照可能
  7. session tags での ABAC 活用例 - 1 クラスター名による権限制御 https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html#_sample_policy_with_tags {

    "Version": "2012-10-17", "Statement": [ (...), { "Effect": "Allow", "Action": ["s3:GetObject", "s3:GetObjectTagging"], "Resource": "*", "Condition": { "StringEquals": { "s3:ExistingObjectTag/eks-cluster-name": "${aws:PrincipalTag/eks-cluster-name}" } } } ] } S3 オブジェクトの eks-cluster-name tag とクラスターが一致する場合のみアクセス可能
  8. session tags での ABAC 活用例 - 2 Namespace による権限制御 {

    "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Resource": "*", "Action": [ "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret" ], "Condition": { "StringEquals": { "secretsmanager:ResourceTag/kubernetes-namespace": "${aws:PrincipalTag/kubernetes-namespace}" } } } ] } シークレットの kubernetes-namespace tag と Namespace が一致する場合のみアクセス可能
  9. session tags に関するエラーの発生 EKS Pod Identity の検証中に遭遇 エラー内容: sts:TagSession の実行権限エラー

    Aws::STS::Errors::AccessDenied User: arn:aws:sts::000000000000:assumed- role/role-name/session-name is not authorized to perform: sts:TagSession on resource: arn:aws:iam::111111111111:role/customer-role-name 発生箇所: ユーザーの AWS アカウント(検証環境のため、実際には EKS が存在するアカウントとは別の社内 アカウント)role を AssumeRole する必要がある処理で発生
  10. AssumeRole の流れ Kubernetes ServiceAccount AssumeRole AWS アカウント role AssumeRole ユーザー

    AWS アカウント role Access ユーザー AWS アカウント リソース アプリケーションでユーザーの IAM role を利用 ユーザーの AWS リソースにアクセスするため 2 段階の AssumeRole 1. Kubernetes ServiceAccount が AWS アカウントの role を AssumeRole 2. AWS アカウントの role がユーザー AWS アカウントの role を AssumeRole 3. ユーザー AWS リソースにアクセス
  11. なぜ session tags に関するエラーが発生したのか EKS Pod Identity における session tags

    の仕様 EKS Pod Identity の session tags は "推移的(transitive)" すべての tag が次の AssumeRole に引き継がれる クロスアカウントでも自動的に伝播 trust policy で sts:TagSession が許可されている必要がある
  12. Pod Identity における session tags の伝搬 エラー発生の流れ 1. EKS Pod

    Identity が session tags ( eks-cluster-name , kubernetes-namespace など) を自動的に付与 2. role への AssumeRole 時に tag が伝播 3. ユーザー AWS アカウント role への AssumeRole 時も session tags 伝播を試みる 4. ユーザー AWS アカウント role の trust policy で sts:TagSession が 許可されていないため AssumeRole でエラー Kubernetes ServiceAccount AssumeRole (tags 付与) AWS アカウント role + tags ユーザー AWS アカウント role + tags Access ユーザー AWS アカウント リソース AssumeRole (tags 伝搬) エラー発生
  13. エラー解決に対するアプローチ 方法 1: ユーザー AWS アカウント role の修正 ユーザー AWS

    アカウント role の trust policy に sts:TagSession を追加 方法 2: session tags の無効化 Pod Identity association で session tags を無効化して tags が伝播しないようにする 結論: 方法 2 で進めることに
  14. 方法 1: ユーザー AWS アカウント role の修正 trust policy に許可を追加

    エラーメッセージ not authorized to perform: sts:TagSession にある通り ユーザー AWS アカウント role の trust policy に sts:TagSession を追加すれば エラーは発生しない { "Version": "2012-10-17", "Statement": [ (...), { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::000000000000:root" }, "Action": "sts:TagSession" } ] }
  15. 方法 1 の問題点 ユーザー影響 ユーザーの IAM Policy 変更が必要 session tags

    を利用しないのに許可が必要 session tags による ABAC 制御は現時点では利用する予定がない 不要な情報(session tags)がユーザーに渡ってしまう 秘匿情報ではないが好ましくない
  16. 方法 2: session tags の無効化 Pod Identity association(IAM role と

    Kubernetes ServiceAccount の関連付け)の設定変更 session tags を伝播させない設定 が可能 ユーザー AWS アカウント role の修正が不要のため、ユーザー影響なしで問題を解決 Pod Identity association の設定を変更するだけ
  17. EKS Pod Identity のアップデート EKS Pod Identity association ごとに session

    tags を無効化することが可能 に 2025/6/12 に AWS のブログで言及さ れた https://aws.amazon.com/jp/blogs/containers/amazon-eks-pod-identity-streamlines-cross-account-access
  18. まとめ EKS Pod Identity で session tags を使った ABAC を利用しようとしている場合は、

    推移的な session tags の影響を受けないか確認したほうがいいかも session tags を使わない場合は無効化を検討 クロスアカウントの AssumeRole で不要な情報が伝播する可能性 使わない機能は無効化しておく方が安全