day-log

EKS 쓰다 보면 언젠가 한 번은 부딪히는 질문. 파드가 AWS 리소스에 접근할 때 IAM을 어떻게 붙일 것인가. 예전에는 답이 하나였다. IRSA. 근데 몇 년 전 Pod Identity가 나오고, 올해 초 우리 팀은 결국 이걸로 옮겼다. 왜 옮겼는지, 뭐가 좋고 뭐가 애매한지 정리해본다.IRSA는 그동안 잘 써왔는데솔직히 IRSA에 큰 불만은 없었다. OIDC provider 만들어놓고, ServiceAccount에 어노테이션 붙이고, IAM 역할의 trust policy에 그 SA를 넣어주면 끝. 몇 년째 잘 굴러왔다.문제는 클러스터가 늘어나면서 시작됐다. 우리 팀은 dev/staging/prod로 클러스터가 세 개, 여기에 데이터 팀이 요청한 별도 클러스터 하나가 더 붙어서 총 네 개다. 각 클러..

옮기기 전에 체크할 것EKS Pod Identity가 GA된 게 2023년 말이니까 벌써 2년 반쯤 됐다. 처음 나왔을 때는 "굳이 IRSA에서 갈아탈 이유가 있나" 싶었는데, 클러스터 수가 10개를 넘어가면서 OIDC provider를 매번 등록하고 trust policy의 sub 클레임을 클러스터마다 갈아끼우는 게 슬슬 짜증나기 시작했다. 올해 들어 우리 팀도 본격적으로 옮기기 시작했고, 이제 절반쯤 마이그레이션한 상태다.이 글은 "왜 옮겨야 하나"보다는 "어떻게 옮기나"에 집중한다. 결론부터 말하면 한 번에 다 갈아엎을 필요는 없다. 같은 클러스터, 같은 네임스페이스에서 IRSA와 Pod Identity가 공존한다.먼저 마이그레이션을 시작하기 전에 확인해야 할 게 몇 가지 있다.EKS 클러스터 버전..

Pod Identity가 정식으로 나온 지 이제 2년 반쯤 됐다. 그동안 우리 팀에서는 IRSA로 굴러가는 클러스터 4개, Pod Identity로 새로 띄운 클러스터 3개를 운영해봤다. 솔직히 처음에는 "OIDC 트러스트 한 줄 더 박는 게 그렇게 귀찮은 일인가?" 싶었는데, 클러스터가 늘어나면서 생각이 좀 바뀌었다.최근 6월 기준으로 Medium에 다시 비교 글이 올라오길래(이게 또 새로 입사하는 친구들이 가장 많이 찾는 주제다) 우리 팀 내부 결정 기록을 정리해서 공유한다. 결론부터 적으면, 새 워크로드는 Pod Identity, 단 Fargate에 띄울 거면 IRSA. 그리고 둘은 같은 클러스터에서 공존시켜도 별 문제 없다.트러스트 정책의 무게IRSA의 진짜 비용은 IAM role 자체가 아니라 ..

요즘 사내 슬랙에 "Pod Identity로 갈아타야 하지 않냐"는 질문이 부쩍 늘었다. AWS가 작년부터 신규 워크로드에는 Pod Identity를 권장한다고 명시하고 있고, 최근 블로그들도 IRSA를 "레거시" 취급하는 분위기다. 그런데 막상 운영 중인 클러스터를 보면 IRSA가 멀쩡히 잘 돌아가고 있다. 굳이 옮겨야 하나?결론부터 말하면 모든 환경에 다 옮길 필요는 없다. 다만 새로 만드는 워크로드부터는 Pod Identity로 가는 게 맞고, 기존 워크로드는 옮길 만한 이유가 있을 때 옮기면 된다. 우리 팀에서 지난 두 달 동안 약 40개 ServiceAccount 중 절반쯤을 옮기면서 정리한 내용을 공유한다.IRSA, 뭐가 불편했나IRSA가 잘못된 건 아니다. OIDC provider만 등록해두..