AWS EKS의 Pod Identity vs IRSA

쿠버네티스에서 Pod가 AWS 리소스에 접근할 때, “IAM 권한을 어떻게 붙일 것인가”는 EKS 운영에서 거의 빠지지 않는 주제입니다.

여기서 보통 두 가지 방식이 나옵니다.

IRSA(IAM Roles for Service Accounts)
EKS Pod Identity

둘 다 “Pod 단위로 IAM Role을 쓴다”는 점은 같지만, 실제 구조는 꽤 다릅니다.

특히 운영을 하다 보면 이런 질문들이 한 번에 이어집니다.

IRSA와 Pod Identity는 실제 인증 흐름이 어떻게 다른가?
OIDC Provider는 왜 클러스터마다 만들어야 하는가?
Pod Identity는 왜 OIDC Provider가 없어도 되는가?
pods.eks.amazonaws.com은 어디서 나온 서비스 프린시펄인가?
EKS Auth API는 정확히 뭐고, IAM OIDC Provider와는 무엇이 다른가?
Trust Policy의 Condition에 쓰는 세션 태그는 누가 만드는가?
ServiceAccount annotation에 Role ARN을 넣는 것과 Association을 등록하는 것은 무엇이 다른가?

이 글은 위 질문을 한 흐름으로 묶어서, IRSA의 구조 → IRSA의 한계 → Pod Identity가 이를 어떻게 바꾸는지 → 실제 인증/인가 흐름 → 세션 태그 → 운영과 마이그레이션 포인트 순서로 정리합니다. EKS Pod Identity는 EKS in-cloud 환경에서 동작하는 EKS 전용 메커니즘이고, IRSA는 OIDC 기반의 보다 범용적인 구조입니다.

참고 링크

Amazon EKS Pod Identity: a new way for applications on EKS to obtain IAM credentials

Learn how EKS Pod Identity grants pods access to AWS services

Understand how EKS Pod Identity works

Create IAM role with trust policy required by EKS Pod Identity

Grant Pods access to AWS resources based on tags

AssumeRoleForPodIdentity - Amazon EKS Auth API

Create an IAM OIDC provider for your cluster

IAM roles for service accounts

Granting AWS IAM permissions to workloads on Amazon EKS clusters

EKS Pod Identity Associations - eksctl User Guide

Set up the Amazon EKS Pod Identity Agent

1. Pod가 AWS 리소스에 접근하려면 결국 “IAM 자격증명”이 필요하다

Pod 안에서 S3를 읽거나, DynamoDB를 조회하거나, SQS에 메시지를 보내려면 결국 AWS API 요청을 서명할 IAM 자격증명이 필요합니다. 예전에는 노드의 Instance Role을 그대로 쓰거나, Access Key를 Secret에 넣는 방식이 흔했지만, 이 방식은 권한 격리가 약하고 키 유출 시 피해 범위가 커집니다. 그래서 지금은 ServiceAccount 단위로 IAM Role을 연결해서 Pod가 임시 자격증명을 받아 쓰는 방식이 표준에 가깝습니다. EKS 문서도 IRSA와 Pod Identity를 모두 이 목적의 메커니즘으로 설명합니다.

핵심은 “Pod가 직접 AWS 장기 키를 들고 있는 것”이 아니라, Pod가 자기 ServiceAccount와 연결된 Role에 대한 임시 자격증명을 필요할 때 받아서 쓰는 구조로 바꾸는 것입니다. 여기서 IRSA와 Pod Identity는 같은 문제를 풀지만, “누가 검증하고, 누가 STS를 호출하느냐”가 다릅니다.

2. IRSA는 어떻게 동작하는가?

2.1 IRSA의 핵심 아이디어

IRSA는 이름 그대로 Kubernetes ServiceAccount에 IAM Role을 연결하는 방식입니다. Pod는 ServiceAccount 토큰을 들고 있고, AWS SDK는 이 토큰을 사용해 STS의 AssumeRoleWithWebIdentity를 호출합니다. 그 뒤 STS는 IAM에 등록된 OIDC Provider를 통해 토큰 발급자를 신뢰할 수 있는지 확인하고, Trust Policy의 조건을 만족하면 임시 자격증명을 발급합니다.

즉 IRSA의 본질은 다음입니다.

Kubernetes가 ServiceAccount 토큰을 발급한다.
Pod 안의 AWS SDK가 그 토큰을 사용해 STS를 직접 호출한다.
STS가 IAM OIDC Provider와 Trust Policy를 바탕으로 토큰을 검증한다.
통과하면 임시 자격증명을 돌려준다.

2.2 Pod 안에서는 무엇이 주입되나?

IRSA를 사용할 때는 EKS control plane 쪽 mutating webhook이 Pod spec을 변형해서 AWS_ROLE_ARN 과 AWS_WEB_IDENTITY_TOKEN_FILE 같은 값을 주입합니다. AWS 문서도 이 Webhook이 Pod에 Role ARN과 web identity token file 경로를 환경변수로 넣는다고 설명합니다. Pod 안의 SDK는 이 값을 보고 기본 credential provider chain 안에서 web identity provider 경로를 탑니다.

개념적으로는 이런 형태입니다.

env:
  - name: AWS_ROLE_ARN
    value: arn:aws:iam::111122223333:role/MyRole
  - name: AWS_WEB_IDENTITY_TOKEN_FILE
    value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token

그리고 실제 Role 연결 정보는 보통 ServiceAccount annotation에 들어갑니다. AWS 문서와 eksctl 문서 모두 eks.amazonaws.com/role-arn annotation 방식을 사용합니다.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: default
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/MyRole

2.3 OIDC Provider는 왜 필요한가?

여기서 중요한 점은 토큰을 발급하는 주체와, 그 토큰을 신뢰하는 주체가 다르다는 것입니다.

토큰 발급: EKS 클러스터의 Kubernetes control plane
토큰 검증/신뢰: IAM / STS 경로

EKS 클러스터에는 OIDC issuer URL이 붙어 있고, IRSA를 쓰려면 IAM에 이 issuer URL에 대한 IAM OIDC Provider 를 등록해야 합니다. AWS 공식 문서도 “서비스 계정에 IAM 역할을 사용하려면 클러스터의 OIDC 발급자 URL에 IAM OIDC 제공자가 있어야 한다”고 명시합니다.

즉, IAM OIDC Provider는 토큰을 발급하는 시스템이 아니라, “STS가 이 issuer가 발급한 JWT를 믿어도 되는가?”를 정의하는 신뢰 앵커입니다. 그래서 IRSA를 쓰려면 클러스터별 issuer URL을 IAM에 등록해야 합니다.

2.4 Trust Policy에서는 무엇을 검사하나?

IRSA Role의 Trust Policy는 보통 아래 두 값을 함께 검사합니다.

aud = sts.amazonaws.com
sub = system:serviceaccount:<namespace>:<serviceaccount>

AWS 공식 예제도 정확히 이 패턴을 사용합니다.

{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.ap-northeast-2.amazonaws.com/id/ABC123"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.ap-northeast-2.amazonaws.com/id/ABC123:aud": "sts.amazonaws.com",
          "oidc.eks.ap-northeast-2.amazonaws.com/id/ABC123:sub": "system:serviceaccount:kube-system:aws-load-balancer-controller"
        }
      }
    }
  ]
}

여기서 역할은 분명합니다.

OIDC Provider 등록: 이 issuer를 신뢰할 것인가?
Trust Policy Condition: 그 issuer가 발급한 토큰 중 어떤 ServiceAccount만 허용할 것인가?

3. IRSA는 왜 운영이 불편해지는가?

IRSA의 장점은 표준 OIDC 기반이라 구조가 명확하다는 점입니다. 하지만 운영 관점에서는 클러스터와 IAM 신뢰 관계가 강하게 결합됩니다. AWS 문서도 IRSA의 OIDC provider ARN은 클러스터별로 고유하며, 새 클러스터에서 기존 Role을 재사용하려면 Trust Policy를 업데이트해야 한다고 설명합니다.

즉 클러스터가 늘어나면 보통 이런 일이 생깁니다.

클러스터마다 IAM OIDC Provider를 새로 등록해야 한다.
각 IAM Role의 Trust Policy에 새 OIDC issuer를 추가해야 한다.
IAM 관리자 권한이 필요한 작업이 늘어난다.
Blue/Green 클러스터 교체나 DR 테스트 때도 Trust를 다시 만져야 한다.
Kubernetes manifest 안에 AWS Role ARN annotation이 들어가서 환경 종속성이 생긴다.

결국 IRSA의 가장 큰 운영 부담은 “Pod 권한 문제”를 풀기 위해 IAM OIDC Provider와 Trust Policy를 클러스터 수만큼 관리해야 한다는 데 있습니다. 이 지점이 Pod Identity가 등장한 직접적인 배경입니다.

4. Pod Identity는 무엇을 바꿨는가?

4.1 핵심 변화: OIDC를 없앤 것이 아니라, EKS가 검증을 직접 맡는다

Pod Identity도 목표는 같습니다. ServiceAccount를 기준으로 Pod에 IAM Role을 부여합니다. 하지만 흐름은 다릅니다.

IRSA에서는 Pod 안의 SDK가 STS를 직접 호출했습니다. 반면 Pod Identity에서는 Pod 안의 SDK가 노드 로컬 Agent 에서 자격증명을 가져오고, 그 Agent가 EKS Auth API의 AssumeRoleForPodIdentity 를 호출합니다. AWS 공식 문서와 블로그는 이 API가 Pod Identity Agent 전용이며, agent가 projected token을 temporary IAM credentials로 교환한다고 설명합니다.

즉 큰 차이는 이겁니다.

IRSA: Pod → STS 직접 호출
Pod Identity: Pod → node local agent → EKS Auth API → STS

4.2 왜 OIDC Provider가 필요 없나?

Pod Identity는 IAM OIDC Provider를 사용하지 않습니다. AWS 공식 블로그도 Pod Identity가 새로운 EKS service principal과 EKS API를 도입함으로써, OIDC identity provider 생성 같은 IAM 특권 작업 없이 권한 구성이 가능해졌다고 설명합니다. AWS User Guide 역시 Pod Identity는 IRSA보다 단순하며 OIDC identity providers를 사용하지 않는다고 명시합니다.

이유는 간단합니다.

IRSA는 STS가 “외부 OIDC issuer가 발급한 토큰”을 검증해야 했습니다.
Pod Identity는 EKS가 “자기 클러스터에서 나온 토큰”을 직접 다룹니다.

즉 검증 주체가 IAM/STS + OIDC 체인에서, EKS 서비스 자체로 이동한 것입니다. 그래서 Pod Identity는 클러스터별 OIDC Provider 등록이 필요 없습니다.

4.3 pods.eks.amazonaws.com은 어디서 나온 것인가?

Pod Identity용 IAM Role의 Trust Policy에는 OIDC Provider ARN 대신 아래 서비스 프린시펄이 들어갑니다.

"Principal": {
  "Service": "pods.eks.amazonaws.com"
}

이 값은 사용자가 만드는 식별자가 아니라, AWS가 Pod Identity를 위해 정의한 서비스 프린시펄입니다. AWS 문서도 Pod Identity용 Role trust policy에 pods.eks.amazonaws.com 과 sts:AssumeRole, sts:TagSession 이 필요하다고 명시합니다.

즉 ec2.amazonaws.com, lambda.amazonaws.com 과 같은 계열이라고 보면 됩니다. Pod가 이 프린시펄로 직접 STS를 호출하는 것은 아니고, EKS Auth 서비스가 이 프린시펄로 Role을 assume하는 구조입니다.

5. Pod Identity의 실제 흐름

5.1 Pod 안에는 무엇이 주입되나?

Pod Identity를 쓰는 경우 EKS의 Pod Identity webhook은 새로 생성되는 Pod에 container credentials provider용 환경변수를 주입합니다. AWS 블로그 예시는 AWS_CONTAINER_CREDENTIALS_FULL_URI 와 AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE 이 들어가는 형태를 보여줍니다.

개념적으로는 이런 모양입니다.

env:
  - name: AWS_CONTAINER_CREDENTIALS_FULL_URI
    value: http://169.254.170.23/v1/credentials
  - name: AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE
    value: /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token

그리고 agent는 각 노드에서 DaemonSet으로 동작하며, 같은 노드의 Pod들에게만 자격증명을 제공합니다. AWS 문서에 따르면 agent는 169.254.170.23 링크-로컬 주소를 사용하고, node의 hostNetwork 위에서 동작합니다.

5.2 전체 인증 흐름

Pod Identity의 흐름을 순서대로 풀면 이렇습니다.

Pod가 ServiceAccount를 사용해 생성된다.
EKS control plane의 Pod Identity webhook이 Pod spec을 변형한다.
Pod 안의 AWS SDK는 기본 credential chain에서 container credentials provider 경로를 탄다.
SDK는 169.254.170.23 의 Pod Identity Agent에 자격증명을 요청한다.
Agent는 projected token과 자신의 권한을 사용해 EKS Auth API의 AssumeRoleForPodIdentity 를 호출한다.
EKS는 association과 토큰 정보를 바탕으로 적절한 Role에 대한 임시 자격증명을 발급받아 Agent를 통해 Pod에 전달한다.

여기서 중요한 운영 포인트가 하나 더 있습니다. Pod Identity Agent는 노드 역할에 권한이 있어야 하며, AWS 문서는 AmazonEKSWorkerNodePolicy 에 eks-auth:AssumeRoleForPodIdentity 권한이 포함되어 있다고 설명합니다. 즉 Pod Identity는 “ServiceAccount에 IAM Role을 준다”는 개념이지만, 실제 호출 경로에는 노드의 agent 권한 도 관여합니다.

6. EKS Auth API는 무엇이고, IAM OIDC Provider와 무엇이 다른가?

이 둘은 비슷한 역할처럼 보이지만 사실 위치가 다릅니다.

6.1 IAM OIDC Provider의 역할

IRSA에서 IAM OIDC Provider는 외부 OIDC issuer에 대한 신뢰 설정입니다. STS는 AssumeRoleWithWebIdentity 요청을 받으면, 이 issuer가 IAM에 등록되어 있는지, 토큰 서명이 맞는지, claim이 Trust Policy를 만족하는지를 검사합니다. 즉 IAM OIDC Provider는 STS가 외부 JWT 발급자를 믿기 위한 설정입니다.

6.2 EKS Auth API의 역할

Pod Identity의 EKS Auth API는 EKS 전용의 내부 인증 교환 엔드포인트입니다. 공식 API 문서도 AssumeRoleForPodIdentity 는 EKS Pod Identity Agent만 사용하는 API라고 설명합니다. 즉 이 API는 OIDC provider처럼 범용 federation용 구성 요소가 아니라, EKS가 Pod token을 받아 Role credential로 교환하는 서비스 내부 API입니다.

비유하면:

IAM OIDC Provider는 “외부 신분증 인정 목록”
EKS Auth API는 “EKS가 자기 직원증을 직접 확인하는 창구”

정도로 이해하면 됩니다. Pod Identity에서 OIDC Provider가 필요 없는 이유도 여기서 자연스럽게 이어집니다.

7. Association은 annotation과 무엇이 다른가?

IRSA에서는 보통 ServiceAccount YAML에 Role ARN annotation을 넣습니다. 즉 Kubernetes manifest 안에 AWS 정보가 들어갑니다. AWS 공식 문서와 eksctl 문서도 이 annotation 기반 설정을 사용합니다.

반면 Pod Identity에서는 Kubernetes ServiceAccount 자체는 단순하게 두고, EKS API에 association 을 등록합니다. EKS User Guide는 association이 “특정 클러스터의 특정 namespace의 특정 service account를 IAM role에 매핑하는 정보”라고 설명합니다. 동일 애플리케이션이 여러 클러스터에 있어도 Role trust policy를 수정하지 않고 동일 association을 각 클러스터에 만들 수 있다고도 말합니다.

즉 차이는 명확합니다.

IRSA annotation: K8s 리소스 안에 AWS Role ARN이 들어간다.
Pod Identity association: AWS 쪽 EKS API에 (cluster, namespace, serviceAccount) -> role 매핑을 등록한다.

운영 관점에서는 이 차이가 큽니다. 같은 ServiceAccount manifest를 dev/staging/prod에 그대로 쓰고, 환경별 Role 연결만 EKS API에서 따로 관리할 수 있기 때문입니다. 즉 Kubernetes manifest와 AWS IAM 구성이 느슨하게 분리됩니다.

8. Pod Identity에서 인가는 어디서 일어나는가?

Pod Identity는 보통 두 단계로 보면 이해가 쉽습니다.

8.1 1차: EKS association 확인

Association이 없으면 Pod Identity는 성립하지 않습니다. EKS는 특정 클러스터/네임스페이스/ServiceAccount 조합에 어떤 IAM Role이 매핑되어 있는지를 association으로 관리합니다. 따라서 association이 없으면 EKS Auth API 단계에서 진행 자체가 되지 않습니다. 공식 문서도 association이 역할과 서비스 계정의 매핑 단위라고 설명합니다.

8.2 2차: IAM Trust Policy 확인

EKS가 Role을 assume할 때는 여전히 IAM Trust Policy를 통과해야 합니다. Pod Identity용 Trust Policy는 기본적으로 pods.eks.amazonaws.com 을 신뢰하고 sts:AssumeRole, sts:TagSession 을 허용해야 합니다. 여기에 Condition을 붙이면 특정 namespace나 ServiceAccount만 Role을 쓸 수 있게 더 좁힐 수 있습니다. AWS 공식 예제도 aws:RequestTag/kubernetes-namespace, aws:RequestTag/kubernetes-service-account 조건을 사용하는 예시를 제공합니다.

즉 Pod Identity의 인가는 “association이 있느냐”와 “Trust Policy 조건을 만족하느냐”를 함께 보는 구조로 이해하면 됩니다.

9. 세션 태그는 누가 만들고, 왜 중요한가?

Pod Identity의 핵심 장점 중 하나가 세션 태그입니다.

AWS 문서에 따르면 EKS Pod Identity는 Role을 assume할 때 다음과 같은 미리 정의된 세션 태그를 자동으로 붙입니다.

eks-cluster-arn
eks-cluster-name
kubernetes-namespace
kubernetes-service-account
kubernetes-pod-name
kubernetes-pod-uid

중요한 점은, 이 태그는 사용자가 Pod spec에서 임의로 넣는 값이 아니라 EKS Pod Identity가 AssumeRole 요청 시 자동으로 붙이는 세션 태그라는 점입니다. AWS User Guide는 이 태그들이 자동으로 활성화되며, 별도 동작 없이 세션에 추가된다고 설명합니다.

여기서 정책을 볼 때 구분해야 할 포인트가 있습니다.

Trust Policy에서 검사할 때: aws:RequestTag/...
실제 권한 정책이나 리소스 정책에서 활용할 때: aws:PrincipalTag/...

예를 들어 Trust Policy는 “이 namespace와 service account만 assume 가능”을 막는 용도로 aws:RequestTag 를 쓰고, S3 bucket policy나 IAM permission policy에서는 “세션의 cluster-name 태그와 리소스 태그가 같을 때만 허용”처럼 aws:PrincipalTag 를 씁니다. AWS 문서가 두 패턴을 각각 예시로 제공합니다.

예를 들어 Trust Policy는 이렇게 좁힐 수 있습니다.

{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
      "Effect": "Allow",
      "Principal": {
        "Service": "pods.eks.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:RequestTag/kubernetes-namespace": ["kube-system"],
          "aws:RequestTag/kubernetes-service-account": ["aws-load-balancer-controller"]
        }
      }
    }
  ]
}

그리고 permission policy / resource policy 쪽에서는 ${aws:PrincipalTag/kubernetes-namespace} 같은 식으로 ABAC를 구성할 수 있습니다. AWS는 이 구조 덕분에 하나의 Role을 여러 ServiceAccount와 클러스터에서 재사용하면서도 리소스 접근은 태그 기반으로 더 촘촘하게 제어할 수 있다고 설명합니다.

10. 운영에서 봐야 할 실제 차이

10.1 IRSA는 클러스터 수가 늘수록 IAM 작업이 늘어난다

IRSA는 클러스터마다 issuer URL이 다르고, IAM OIDC Provider도 그 issuer 기준으로 등록해야 합니다. 그래서 새 클러스터가 생기면 OIDC Provider 등록과 Trust Policy 업데이트가 따라옵니다. AWS의 AWS Load Balancer Controller 가이드도 새 클러스터에서 기존 IRSA Role을 재사용할 때 Trust Policy에 새 OIDC provider를 추가해야 한다고 명시합니다.

10.2 Pod Identity는 trust를 한 번 열고, 클러스터별로 association만 추가한다

Pod Identity는 Role trust를 pods.eks.amazonaws.com 으로 한 번 열어두면, 이후 클러스터별 연결은 EKS API의 association으로 처리합니다. AWS User Guide는 같은 앱이 여러 클러스터에 있어도 Role trust policy를 수정하지 않고 동일 association만 만들면 된다고 설명합니다.

즉 운영 관점의 핵심 차이는 이것입니다.

IRSA: 클러스터 추가 시 IAM OIDC + Trust Policy 수정
Pod Identity: 클러스터 추가 시 Association 생성 중심

10.3 Pod Identity의 제약도 있다

다만 Pod Identity가 무조건 상위호환인 것은 아닙니다. AWS 문서 기준으로 Pod Identity는 EKS in-cloud 전용이고, EKS Anywhere, self-managed Kubernetes on EC2, Outposts, Fargate, Windows EC2 Pod 등은 지원하지 않습니다. Agent도 필요하고, association은 eventual consistency 특성이 있어 생성/수정 직후 몇 초 지연이 있을 수 있습니다.

즉 “범용성”은 IRSA 쪽이 더 넓고, “EKS 운영 단순화”는 Pod Identity 쪽이 더 강하다고 보는 것이 정확합니다.

11. 마이그레이션할 때 무엇을 보면 되나?

Pod Identity로 옮길 때는 보통 아래 순서로 보면 됩니다.

11.1 Pod Identity Agent 설치

먼저 클러스터에 eks-pod-identity-agent 가 있어야 합니다. AWS 문서는 이 agent가 필수이며, node role에 필요한 권한도 있어야 한다고 설명합니다.

eksctl create addon --cluster my-cluster --name eks-pod-identity-agent
kubectl get daemonset -n kube-system eks-pod-identity-agent

11.2 IAM Role trust policy 수정

기존 IRSA Role을 재사용할 수도 있지만, Pod Identity용으로는 최소한 아래 trust가 필요합니다.

{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
      "Effect": "Allow",
      "Principal": {
        "Service": "pods.eks.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ]
    }
  ]
}

이때 민감한 Role이라면 namespace / service account 조건까지 같이 넣는 것이 안전합니다. AWS User Guide도 request tag 조건으로 좁히는 예시를 제공합니다.

11.3 Association 생성

aws eks create-pod-identity-association \
  --cluster-name my-cluster \
  --namespace kube-system \
  --service-account aws-load-balancer-controller \
  --role-arn arn:aws:iam::111122223333:role/ALBControllerRole

Association은 (cluster, namespace, service account) -> role 매핑입니다. ServiceAccount YAML 자체는 AWS annotation 없이 둘 수 있습니다.

11.4 기존 Pod 재기동 및 검증

Pod Identity webhook은 새로 생성되는 Pod 에 환경변수를 주입하므로, 기존 Pod는 재생성이 필요할 수 있습니다. 또한 association은 eventual consistency가 있어 직후 몇 초간 반영 지연이 있을 수 있습니다. 검증은 kubectl describe pod 로 injected env와 token mount를 보고, 애플리케이션 로그나 aws sts get-caller-identity 로 실제 identity를 확인하는 방식이 가장 안전합니다.

11.5 eksctl 마이그레이션 명령

eksctl은 기존 iamserviceaccount 와 add-on 구성을 Pod Identity association으로 옮기는 유틸리티를 제공합니다. 문서에 따르면 이 명령은 agent 설치, 기존 role 식별, trust policy 업데이트, association 생성 등을 순서대로 수행합니다.

eksctl utils migrate-to-pod-identity --cluster my-cluster
eksctl utils migrate-to-pod-identity --cluster my-cluster --approve
eksctl utils migrate-to-pod-identity --cluster my-cluster --approve \
  --remove-oidc-provider-trust-relationship

운영에서는 한 번에 IRSA 흔적을 다 지우기보다, association 생성 → pod 재기동 → 실제 자격증명 확인 → 마지막에 OIDC trust 제거 순서가 더 안전합니다. 공식 문서도 OIDC trust 제거를 옵션으로 분리해 둡니다.

저작자표시 (새창열림)

'프로그래밍 > Kubernetes' 카테고리의 다른 글

HPA는 어떻게 메트릭을 가져와서 Pod의 Scaling을 하는걸까? (0)	2026.03.04
EKS + EBS로 이해하는 Kubernetes 스토리지 (0)	2026.02.19
Kubernetes Multi Scheduler: 기초부터 실전까지 - Part 1 (0)	2025.10.30
AmazonLinux2에 EC2에 쿠버네티스 설치하기. (0)	2023.07.02
쿠버네티스 공부 커리큘럼. (0)	2023.04.23

HwanShell

AWS EKS의 Pod Identity vs IRSA

1. Pod가 AWS 리소스에 접근하려면 결국 “IAM 자격증명”이 필요하다

2. IRSA는 어떻게 동작하는가?

2.1 IRSA의 핵심 아이디어

2.2 Pod 안에서는 무엇이 주입되나?

2.3 OIDC Provider는 왜 필요한가?

2.4 Trust Policy에서는 무엇을 검사하나?

3. IRSA는 왜 운영이 불편해지는가?

4. Pod Identity는 무엇을 바꿨는가?

4.1 핵심 변화: OIDC를 없앤 것이 아니라, EKS가 검증을 직접 맡는다

4.2 왜 OIDC Provider가 필요 없나?

4.3 pods.eks.amazonaws.com은 어디서 나온 것인가?

5. Pod Identity의 실제 흐름

5.1 Pod 안에는 무엇이 주입되나?

5.2 전체 인증 흐름

6. EKS Auth API는 무엇이고, IAM OIDC Provider와 무엇이 다른가?

6.1 IAM OIDC Provider의 역할

6.2 EKS Auth API의 역할

7. Association은 annotation과 무엇이 다른가?

8. Pod Identity에서 인가는 어디서 일어나는가?

8.1 1차: EKS association 확인

8.2 2차: IAM Trust Policy 확인

9. 세션 태그는 누가 만들고, 왜 중요한가?

10. 운영에서 봐야 할 실제 차이

10.1 IRSA는 클러스터 수가 늘수록 IAM 작업이 늘어난다

10.2 Pod Identity는 trust를 한 번 열고, 클러스터별로 association만 추가한다

10.3 Pod Identity의 제약도 있다

11. 마이그레이션할 때 무엇을 보면 되나?

11.1 Pod Identity Agent 설치

11.2 IAM Role trust policy 수정

11.3 Association 생성

11.4 기존 Pod 재기동 및 검증

11.5 eksctl 마이그레이션 명령

'프로그래밍 > Kubernetes' 카테고리의 다른 글

댓글

티스토리툴바

AWS EKS의 Pod Identity vs IRSA

1. Pod가 AWS 리소스에 접근하려면 결국 “IAM 자격증명”이 필요하다

2. IRSA는 어떻게 동작하는가?

2.1 IRSA의 핵심 아이디어

2.2 Pod 안에서는 무엇이 주입되나?

2.3 OIDC Provider는 왜 필요한가?

2.4 Trust Policy에서는 무엇을 검사하나?

3. IRSA는 왜 운영이 불편해지는가?

4. Pod Identity는 무엇을 바꿨는가?

4.1 핵심 변화: OIDC를 없앤 것이 아니라, EKS가 검증을 직접 맡는다

4.2 왜 OIDC Provider가 필요 없나?

4.3 pods.eks.amazonaws.com은 어디서 나온 것인가?

5. Pod Identity의 실제 흐름

5.1 Pod 안에는 무엇이 주입되나?

5.2 전체 인증 흐름

6. EKS Auth API는 무엇이고, IAM OIDC Provider와 무엇이 다른가?

6.1 IAM OIDC Provider의 역할

6.2 EKS Auth API의 역할

7. Association은 annotation과 무엇이 다른가?

8. Pod Identity에서 인가는 어디서 일어나는가?

8.1 1차: EKS association 확인

8.2 2차: IAM Trust Policy 확인

9. 세션 태그는 누가 만들고, 왜 중요한가?

10. 운영에서 봐야 할 실제 차이

10.1 IRSA는 클러스터 수가 늘수록 IAM 작업이 늘어난다

10.2 Pod Identity는 trust를 한 번 열고, 클러스터별로 association만 추가한다

10.3 Pod Identity의 제약도 있다

11. 마이그레이션할 때 무엇을 보면 되나?

11.1 Pod Identity Agent 설치

11.2 IAM Role trust policy 수정

11.3 Association 생성

11.4 기존 Pod 재기동 및 검증

11.5 eksctl 마이그레이션 명령

'프로그래밍 > Kubernetes' 카테고리의 다른 글

관련글

댓글

티스토리툴바