EKS Pod Identity 도입 가이드 - IRSA에서 갈아타기 전에

요즘 사내 슬랙에 "Pod Identity로 갈아타야 하지 않냐"는 질문이 부쩍 늘었다. AWS가 작년부터 신규 워크로드에는 Pod Identity를 권장한다고 명시하고 있고, 최근 블로그들도 IRSA를 "레거시" 취급하는 분위기다. 그런데 막상 운영 중인 클러스터를 보면 IRSA가 멀쩡히 잘 돌아가고 있다. 굳이 옮겨야 하나?

결론부터 말하면 모든 환경에 다 옮길 필요는 없다. 다만 새로 만드는 워크로드부터는 Pod Identity로 가는 게 맞고, 기존 워크로드는 옮길 만한 이유가 있을 때 옮기면 된다. 우리 팀에서 지난 두 달 동안 약 40개 ServiceAccount 중 절반쯤을 옮기면서 정리한 내용을 공유한다.

IRSA, 뭐가 불편했나

IRSA가 잘못된 건 아니다. OIDC provider만 등록해두면 ServiceAccount에 IAM 역할을 매핑할 수 있어 깔끔하다. 그런데 운영하다 보면 짜증나는 지점이 몇 가지 누적된다.

첫째, 클러스터마다 OIDC issuer URL이 다르다. IAM 역할의 trust policy에 클러스터 OIDC URL이 박혀 있어서 새 클러스터를 만들 때마다 trust policy를 다시 써야 한다. dev/stg/prod 3개 환경에 같은 권한이 필요한 워크로드가 있으면 IAM 역할도 3벌이 된다. 우리 팀은 클러스터를 분기마다 한 번씩 rebuild하는데, 그때마다 OIDC URL 바뀌고 trust policy 50개쯤 손대는 게 일이었다.

둘째, Terraform 코드가 지저분해진다. aws_iam_openid_connect_provider, OIDC URL 데이터소스 룩업, trust policy의 Condition.StringEquals 안에 sub claim... 모듈로 깔끔하게 묶기 어렵다. 처음 들어온 동료가 코드 읽다가 "이게 왜 이렇게 복잡하냐"고 물어본 게 한두 번이 아니다.

셋째, roles anywhere나 cross-account 시나리오에서 trust 체인이 점점 복잡해진다. Pod Identity는 EKS 서비스 주체가 sts:AssumeRole을 호출하는 구조라 trust policy가 한 줄이다.

마이그레이션 전에 챙겨야 할 것들

옮기기 전에 확인할 게 있다. 무지성으로 다 옮기다가 발 헛디딘 사례가 사내에도 있어서 적어둔다.

• Fargate를 쓰고 있다면 거기는 그대로 두자. Pod Identity Agent는 EC2 노드에 DaemonSet으로 뜨는데, Fargate에는 DaemonSet이 안 뜬다. 같은 클러스터 안에서 EC2 워크로드는 Pod Identity, Fargate 워크로드는 IRSA로 공존시키는 건 공식 지원 패턴이다.
• kube2iam/kiam 같은 옛날 도구를 아직 쓴다면 먼저 그것부터 걷어내는 게 우선순위다. Pod Identity는 fsGroup, hostNetwork 등 일부 조합에서 충돌이 날 수 있는데 어차피 그쪽이 더 큰 문제다.
• EKS 1.24 이상이어야 한다. addon으로 설치하는 Pod Identity Agent가 그렇다. 우리는 어차피 1.30+여서 패스했지만 1.23 이하 클러스터가 있다면 업그레이드부터 해야 한다.
• 세션 태그를 지금 IRSA로 어떻게 쓰고 있는지 확인해두자. Pod Identity는 클러스터/네임스페이스/SA 이름을 자동으로 세션 태그로 박아주는데, IAM 정책에서 aws:PrincipalTag로 필터링하던 게 있다면 키 이름을 다시 매핑해야 한다.

기존 IRSA 사용 현황 인벤토리는 이 한 줄로 빠르게 뽑을 수 있다.

kubectl get sa -A -o json | jq -r '.items[] |
  select(.metadata.annotations."eks.amazonaws.com/role-arn") |
  "\(.metadata.namespace)/\(.metadata.name) -> \(.metadata.annotations."eks.amazonaws.com/role-arn")"'

이걸 스프레드시트에 떨궈놓고 워크로드 단위로 우선순위를 매겼다. 자주 rebuild되는 환경의 것, trust policy가 꼬여 있는 것부터.

실제로 옮기는 절차

한 워크로드를 옮기는 절차는 단순하다. 크게 세 단계.

1. Pod Identity Agent 설치

EKS addon으로 한 번만 설치하면 된다.

aws eks create-addon \
  --cluster-name prod-cluster \
  --addon-name eks-pod-identity-agent \
  --addon-version v1.3.4-eksbuild.1

DaemonSet이 kube-system에 뜨고, 각 노드에서 169.254.170.23:80 으로 IMDS-like 엔드포인트를 띄운다. SDK가 컨테이너 credential provider를 자동으로 잡아준다.

2. IAM 역할 생성과 association

trust policy가 IRSA보다 훨씬 단순하다. OIDC URL도 sub claim도 없다.

resource "aws_iam_role" "app" {
  name = "myapp-pod-identity"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = { Service = "pods.eks.amazonaws.com" }
      Action = ["sts:AssumeRole", "sts:TagSession"]
    }]
  })
}

resource "aws_eks_pod_identity_association" "app" {
  cluster_name    = "prod-cluster"
  namespace       = "default"
  service_account = "myapp"
  role_arn        = aws_iam_role.app.arn
}

trust policy 한 덩어리가 모든 클러스터에서 그대로 재사용 가능하다는 점이 핵심이다. dev/stg/prod에서 같은 role ARN을 재사용할 수 있다는 뜻은 아니지만(역할 자체는 환경별로 따로), trust policy "템플릿"이 동일해진다는 게 운영 입장에서 크다.

3. ServiceAccount annotation 제거 후 파드 재시작

IRSA를 쓰던 SA에는 eks.amazonaws.com/role-arn annotation이 박혀 있는데, Pod Identity로 옮기면 이 annotation을 빼야 한다. 안 빼면 IRSA 토큰이 우선 주입되어서 Pod Identity가 의도대로 동작하지 않는다.

kubectl annotate sa myapp eks.amazonaws.com/role-arn-
kubectl rollout restart deployment/myapp

파드 재시작 후 SDK가 어떤 credential provider를 잡는지 로그로 한 번 확인하자. AWS SDK는 정상이라면 ContainerProvider(Pod Identity)를 잡고, 환경변수 AWS_CONTAINER_CREDENTIALS_FULL_URI가 박혀 있어야 한다.

kubectl exec deploy/myapp -- env | grep AWS_CONTAINER

여기서 환경변수가 안 보이면 Pod Identity association이 잘못 잡혔거나 Agent DaemonSet이 그 노드에 안 뜬 경우다. Agent의 노드 셀렉터/톨러레이션을 확인할 것.

함정 몇 가지

마이그레이션하면서 부딪힌 것들.

SDK 버전 이슈. boto3 1.34 이하, AWS SDK for Go v1, Java SDK v1 등 오래된 버전은 Pod Identity의 credential provider를 못 잡는다. 우리는 boto3 1.26 쓰던 레거시 워커 하나 때문에 한 시간 날렸다. SDK 업그레이드를 먼저 해두는 게 정신 건강에 좋다.

CloudTrail 로그 분석할 때. IRSA는 userIdentity.sessionContext.sessionIssuer.arn이 IAM 역할이고, Pod Identity는 거기에 클러스터/네임스페이스/파드 정보가 세션 태그로 더 들어온다. 보안팀이 쿼리 짜놓은 게 있다면 양쪽 형식 다 대응되도록 손봐야 한다.

rollback 계획. annotation을 다시 박고 파드 재시작하면 IRSA로 즉시 돌아온다. Pod Identity association은 남겨둬도 IRSA가 이긴다... 가 아니라 사실 둘 다 active면 동작이 정의되어 있지 않다는 게 공식 입장에 가깝다. 그래서 우리는 마이그레이션 후 1주일은 association만 두고 annotation을 박은 채로 모니터링했다가, 멀쩡하면 한 번에 annotation 제거하고 association만 남기는 식으로 갔다.

---

전체적으로 옮기는 작업 자체는 어렵지 않다. 다만 "왜 옮기는지"가 명확하지 않으면 굳이 시간 들일 가치는 없다. 우리 팀의 경우 클러스터를 자주 rebuild하는 환경에서 trust policy 관리 부담이 컸기 때문에 옮기는 게 답이었다. 운영 클러스터가 안정적이고 IRSA가 잘 돌아가고 있다면 새 워크로드부터 Pod Identity로 시작하는 점진적 접근이 합리적이다.

다른 팀은 어떻게 옮기고 계신지 궁금하다. Fargate 비중이 큰 곳은 또 다른 고민이 있을 것 같은데.