EKS Pod Identity vs IRSA, 옮길지 말지

 

작년에 신규 EKS 클러스터를 띄우면서 한 가지 결정을 미뤘다. 워크로드 IAM을 IRSA로 갈지 Pod Identity로 갈지. 그때는 "어차피 둘 다 지원되니까 나중에 보자"고 미뤘는데, 올해 들어 클러스터가 4개로 늘어나면서 더는 미룰 수 없는 상태가 됐다.

지난 두 달 동안 stage 환경 전체를 Pod Identity로 옮겨보고, prod의 일부 워크로드도 마이그레이션을 시작했다. 결론부터 말하면 우리 팀은 신규 워크로드는 전부 Pod Identity로, 기존 IRSA는 천천히 전환 중이다. 왜 그런 결정을 했는지, 어떤 케이스에서는 IRSA가 더 나았는지 정리해본다.

비교의 배경: 우리는 어떤 환경이었나

먼저 우리 팀 환경을 짧게 적어둔다. 비교 결과는 환경에 따라 다르게 읽힐 수 있어서다.

EKS 1.30~1.32 클러스터 4개(dev, stage, prod, data). 노드는 전부 Karpenter로 관리하고 EC2 기반이다. Fargate는 안 쓴다. 워크로드는 약 60개 마이크로서비스, IAM 역할이 필요한 게 그중 30개 정도. Terraform으로 클러스터와 IAM을 같이 관리하고 ArgoCD로 배포한다.

IRSA는 EKS 1.24 시절부터 써왔다. 익숙하다. 그런데 작년 말부터 슬슬 한계가 보이기 시작했다.

IRSA, 잘 알려진 장점과 덜 알려진 단점

IRSA의 장점은 굳이 길게 안 적겠다. OIDC provider 기반이라 EKS 외부에서도 비슷한 패턴으로 쓸 수 있고(예: GitHub Actions), 오래 써온 만큼 레퍼런스가 풍부하고, IaC 도구들의 모듈도 다 갖춰져 있다.

문제는 단점 쪽이다. 처음에는 보이지 않다가, 클러스터가 늘어나고 워크로드가 늘어나면서 점점 거슬리는 것들이다.

첫째, OIDC provider 관리가 은근히 귀찮다. 클러스터 만들 때마다 OIDC URL이 바뀌고, 그 URL을 IAM 역할 trust policy에 박아 넣어야 한다. 클러스터 4개면 trust policy도 4벌이거나 조건부로 4개 OIDC를 다 적어야 한다. 우리는 후자였는데, role 하나의 trust policy가 점점 길어지면서 가독성이 떨어졌다. 새 클러스터를 띄울 때마다 모든 IAM 역할을 한 번씩 건드려야 한다는 점도 부담이었다.

둘째, 클러스터를 재생성하면 trust policy가 깨진다. OIDC URL이 바뀌니까. 우리는 dev 클러스터를 분기에 한 번씩 갈아엎는 정책을 갖고 있었는데, 갈아엎을 때마다 IAM 역할을 전부 업데이트해야 했다. Terraform이 알아서 해준다고는 하지만, 실수로 prod 환경의 trust policy가 변경되는 PR이 나오면 무서운 게 사실이다.

셋째, 토큰 audience 설정 같은 디테일에서 가끔 발이 걸린다. 특히 외부 도구(예: AWS Load Balancer Controller, Karpenter, Cluster Autoscaler) 버전을 올릴 때 audience 처리가 미묘하게 달라지는 경우가 있어서 디버깅에 시간이 들었다.

넷째, role을 클러스터 간에 공유하기 어렵다. trust policy가 클러스터별 OIDC를 가리키기 때문에, 같은 권한을 dev/stage/prod 클러스터에서 쓰려면 trust policy를 매번 손봐야 했다. 이게 별 거 아닌 것 같지만, 30개 role × 4개 클러스터 조합이면 신경 쓸 게 꽤 된다.

다 적고 보니 단점들이 다 "운영 규모가 커지면서 드러나는" 종류다. 작은 환경이라면 IRSA로도 충분히 평화롭게 살 수 있다.

Pod Identity, 써보니까 좋은 것과 어색한 것

Pod Identity는 2023년 말에 나왔는데, 우리는 좀 늦게 진지하게 검토했다. 핵심은 OIDC를 안 거치고, EKS API 자체가 ServiceAccount-IAM Role 매핑을 알고 있다는 점이다. 노드에 Pod Identity Agent라는 데몬셋이 떠서 Pod에서 들어오는 IAM 자격증명 요청을 가로채 STS를 호출해 토큰을 돌려준다.

좋은 점부터.

OIDC provider가 필요 없다. 새 클러스터를 띄워도 IAM 역할의 trust policy는 그대로다. Trust policy도 단순하다. pods.eks.amazonaws.com을 신뢰하는 한 줄짜리 statement면 된다. 클러스터 4개에서 같은 role을 쓸 때 trust policy는 단 한 벌만 있으면 충분하다. 처음 봤을 때 좀 허무할 정도였다.

Service Account 어노테이션이 필요 없다. IRSA에서는 SA에 eks.amazonaws.com/role-arn 어노테이션을 박아야 했는데, Pod Identity에서는 EKS API에서 association을 만들어두면 끝이다. SA YAML이 깨끗해지는 부수 효과가 있다. ArgoCD diff에서 어노테이션 흔적이 사라져서 매니페스트 리뷰가 편해졌다.

Session tagging이 기본이다. Pod Identity Agent가 STS 호출 시 cluster-name, namespace, service-account를 기본 session tag로 넣어준다. 그래서 ABAC 정책을 짜기 정말 편하다. 예를 들어 "namespace=team-a이면 S3 버킷 prefix team-a/만 접근 가능" 같은 정책을 IAM에서 직접 표현할 수 있다. 우리는 이걸로 멀티테넌트 권한 관리를 좀 단순화했다.

자격증명 갱신이 빠르다. IRSA는 토큰 만료 1시간 전쯤 갱신하는 라이브러리를 썼는데, Pod Identity Agent는 더 짧은 주기로 알아서 갱신해준다. 장시간 도는 워크로드(예: 큐 컨슈머)에서 토큰 만료 직전 STS API 폭주 같은 작은 문제들이 사라졌다.

이제 어색했던 점.

Pod Identity Agent라는 데몬셋이 하나 더 늘어난다. 노드당 한 개 Pod이 더 떠 있다. 메모리는 적게 먹지만(우리 환경에서 약 30MB 수준) 어쨌든 추가 컴포넌트다. 이 Agent가 죽으면 그 노드의 Pod들이 IAM 자격증명을 못 받는다는 의미라, 모니터링 대상이 하나 더 늘었다.

디버깅 도구 체계가 IRSA만큼 성숙하지 않다. IRSA는 워낙 오래 써서 문제 날 때 검색하면 답이 거의 나왔는데, Pod Identity는 트러블슈팅 글이 상대적으로 적다. 우리도 한 번 association이 안 먹는 이슈가 있었는데, 알고 보니 EKS Add-on으로 Pod Identity Agent를 깔 때 cluster role 권한이 모자란 케이스였다. 이런 거 검색해도 안 나와서 직접 파야 했다.

Fargate에서는 못 쓴다. 우리는 안 쓰지만, Fargate를 쓰는 팀이라면 결국 IRSA를 같이 운영해야 한다. AWS 측에서 Fargate 지원은 아직 로드맵에 없다고 한다.

일부 외부 도구의 호환성 이슈. AWS SDK 최신 버전들은 다 알아서 Pod Identity를 인식한다. 그런데 좀 오래된 SDK나 자체 구현된 자격증명 로딩 로직을 쓰는 도구는 AWS_CONTAINER_CREDENTIALS_FULL_URI와 AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE 환경변수를 명시적으로 읽도록 처리해줘야 한다. 우리는 한 군데서 이거 때문에 자격증명을 못 읽는 이슈가 있었다.

실제로 옮겨본 케이스 두 가지

말이 길어졌으니 우리가 실제로 옮긴 두 가지 케이스를 짧게 적는다.

케이스 1: AWS Load Balancer Controller

가장 무난했다. 신규 stage 클러스터에서 처음부터 Pod Identity로 깔았다. EKS Add-on으로 Pod Identity Agent를 설치하고, Pod Identity Association을 만들고, ALB Controller Helm chart를 깔았다. trust policy는 pods.eks.amazonaws.com 한 줄.

resource "aws_eks_pod_identity_association" "alb_controller" {
  cluster_name    = aws_eks_cluster.this.name
  namespace       = "kube-system"
  service_account = "aws-load-balancer-controller"
  role_arn        = aws_iam_role.alb_controller.arn
}

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

ALB Controller가 SDK가 최신이라 별도 설정 없이 그냥 동작했다. 같은 role을 dev, stage, prod 모두에서 association만 만들어 재사용 가능하다는 점이 인상적이었다.

케이스 2: 자체 작성한 Go 컨슈머

이건 좀 헤맸다. 사내에서 만든 SQS 컨슈머인데 SDK 버전이 좀 오래된 v1을 쓰고 있었다. Pod Identity로 옮기니까 자격증명을 못 읽었다. 디버깅해보니 aws/credentials 패키지가 Container Credentials Provider를 자동으로 활성화하지 않는 케이스였다.

해결은 두 가지. SDK를 v2로 올리거나, 명시적으로 endpoint provider를 지정하거나. 우리는 결국 SDK를 v2로 올렸는데, 이건 Pod Identity 문제라기보다는 "어차피 올려야 했던 SDK 업그레이드를 핑계 삼아 올린" 케이스에 가깝다.

이 경험 이후로는 마이그레이션 전에 SDK 버전을 한 번씩 점검하는 단계를 추가했다.

그래서 어디에 뭘 쓸까

우리 팀의 현재 결론은 이렇다.

Pod Identity로 가는 케이스:

• 새로 만드는 모든 워크로드
• 클러스터 간 공유되는 공용 컴포넌트(ALB Controller, Karpenter, External Secrets, ArgoCD 등)
• ABAC를 적용하고 싶은 멀티테넌트 환경
• 클러스터 재생성 사이클이 짧은 환경(주로 dev)

IRSA를 그대로 두는 케이스:

• Fargate를 쓰는 팀
• SDK 업그레이드 비용이 큰 레거시 워크로드
• 이미 잘 돌아가고 있고 굳이 옮길 동기가 없는 prod 워크로드

마지막 케이스가 사실 제일 많다. "굳이 옮기지 않는다"는 선택지가 정당하다는 점을 강조하고 싶다. AWS도 IRSA deprecation 일정을 내놓지 않았고, 두 방식이 같은 클러스터에 공존해도 문제없다. 멀쩡히 도는 워크로드를 굳이 마이그레이션 리스크에 노출시킬 이유는 없다.

마이그레이션할 때 참고할 것 두어 개

옮기면서 알게 된 자잘한 팁들.

첫째, Pod Identity Agent를 EKS Add-on으로 설치하면 IAM cluster role 자동 생성 옵션이 있다. 이거 켜고 가는 게 편하다. 자체 Helm으로 깔면 cluster role 권한 누락 케이스에 빠지기 쉽다.

둘째, 같은 SA에 IRSA와 Pod Identity가 둘 다 잡혀 있으면 Pod Identity가 우선한다. 마이그레이션할 때 IRSA 어노테이션을 그대로 둬도 일단 동작은 한다는 의미. 검증 끝나고 어노테이션을 제거하는 단계로 두면 롤백이 쉽다.

셋째, Pod Identity로 옮기고 나면 IAM role의 trust policy에서 OIDC 항목을 지우고 싶은 충동이 들 텐데, 다른 클러스터의 IRSA가 같은 role을 참조하고 있을 수 있다. 모든 클러스터가 다 옮겨진 후에 정리하는 게 안전하다.

넷째, association 생성은 즉시 반영이 아니다. 새로 만든 association이 적용되려면 Pod이 재시작되어야 한다. 우리는 처음에 이걸 모르고 "왜 권한이 안 먹지?" 한참 헤맸다.

마무리

작년이라면 이 비교를 두고 "아직 IRSA가 안전한 선택"이라고 했을 것이다. 1년 정도 지난 지금은 Pod Identity가 충분히 성숙했다고 본다. 신규 워크로드는 Pod Identity로 가고, 기존 IRSA는 옮길 동기가 분명한 것부터 천천히 옮기는 게 무난해 보인다.

다만 환경마다 결론이 다를 수 있어서, 위에 적은 우리 팀의 케이스를 그대로 가져다 쓰진 마시길. 특히 Fargate가 섞인 환경, 외부에서 EKS API를 호출하기 어려운 환경, IRSA 기반 도구체인이 깊게 박혀 있는 환경은 다른 결론이 나올 수 있다.

다음 글에서는 Pod Identity로 옮기면서 함께 정리한 IAM session tag 기반 ABAC 정책 패턴을 다뤄볼 예정이다. 멀티테넌트 클러스터에서 권한을 단순화하는 데 꽤 효과가 있어서 공유할 만하다.