EKS Pod에 IAM 권한 주기 — IRSA vs Pod Identity

EKS 위에 올린 파드가 S3 에서 파일을 읽거나 SQS 에 메시지를 넣으려면 AWS 자격증명이 있어야 합니다. 액세스 키를 시크릿에 넣어 두는 방법이 제일 먼저 떠오르지만 키가 저절로 만료되지 않고 새어 나가면 회수가 늦어서, 지금은 파드에 IAM Role 을 직접 붙이는 쪽을 씁니다.

붙이는 단위는 파드가 아니라 ServiceAccount 고, 파드는 뜨고 지기를 반복해도 ServiceAccount 는 매니페스트에 그대로 남기 때문입니다. 여기에 IAM Role 을 연결해 두면 이 ServiceAccount 로 뜨는 파드가 전부 같은 권한을 받습니다.

그런데 붙이는 방법을 찾아보면 IRSA 와 EKS Pod Identity 두 개가 나옵니다. 둘 다 ServiceAccount 에 IAM Role 을 연결한다고 설명돼 있어서 하는 일이 같아 보입니다. 왜 둘이 있는지, 지금 새로 붙인다면 어느 쪽을 골라야 하는지가 먼저 걸립니다.

기본값이면 Pod가 Node의 IAM Role을 씀

아무 설정도 안 하면 파드는 자기가 올라탄 노드의 IAM Role 을 그대로 쓰고 그 노드에 뜬 파드는 전부 같은 권한을 갖습니다. S3 하나만 읽으면 되는 파드도 노드 롤에 붙은 권한을 전부 갖게 되니 최소 권한 원칙이 깨지고 노드에 뭐가 뜰지는 스케줄러가 정하기 때문에 어느 파드가 무슨 권한을 갖는지도 미리 모릅니다. 그래서 파드, 정확히는 ServiceAccount 마다 다른 IAM Role 을 주는 방법이 필요합니다.

IRSA — OIDC 기반

IRSA(IAM Roles for Service Accounts)는 OIDC 로 동작하고 EKS 클러스터 자체가 OIDC Provider 가 됩니다.

1. EKS 클러스터에 OIDC Provider 생성
2. IAM Role 의 Trust Policy 에:
   "이 OIDC Provider 의 이 ServiceAccount 만 이 Role 을 AssumeRole 가능"
3. ServiceAccount 에 annotation:
   eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-role
4. Pod 시작 시 Web Identity 토큰 파일이 자동 마운트
5. SDK 가 토큰 → STS → 임시 자격증명 교환

Pod 안에서 일어나는 일은 이렇습니다.

Pod 시작
  └── 토큰 파일 마운트
        ↓
  AWS SDK 가 토큰 감지
        ↓
  STS AssumeRoleWithWebIdentity 호출
        ↓
  임시 자격증명(1시간) 받아서 사용

동작은 잘 되지만 Trust Policy 가 번거롭습니다. “이 OIDC Provider 의 이 SA 만” 이라는 조건을 매번 정확히 써야 합니다. OIDC Provider 도 클러스터마다 따로 있어서 멀티 클러스터면 클러스터 수만큼 OIDC 설정이 늘어납니다.

EKS Pod Identity — OIDC 제거

2023년에 나온 방식이고, 클러스터마다 OIDC Provider 를 만들 필요 없이 EKS 가 노드에 Agent 를 DaemonSet 으로 띄워 같은 노드의 파드에 자격증명을 내줍니다.

1. EKS Pod Identity Agent 설치 (DaemonSet)
2. IAM Role 의 Trust Policy 에:
   "EKS Pod Identity 서비스가 이 Role 을 AssumeRole 가능" (단순)
3. EKS 콘솔/CLI 에서 ServiceAccount ↔ IAM Role 매핑
4. Pod 시작 시 SDK 가 노드의 Agent 엔드포인트에서 자격증명을 받아 감

Trust Policy 도 훨씬 단순해서 OIDC ARN 과 condition 을 쓰는 대신 EKS 서비스 principal 하나면 됩니다. 클러스터마다 OIDC 를 세팅할 필요도 없으니 같은 IAM Role 을 여러 클러스터에서 재사용할 수 있습니다.

항목별 차이 — OIDC 설정과 Trust Policy

항목	IRSA	EKS Pod Identity
출시	2019	2023
OIDC 설정	클러스터마다 필요	불필요
Trust Policy	OIDC ARN + condition	서비스 principal (단순)
자격증명 갱신	SDK 가 자동	Agent 가 자동
멀티 클러스터	클러스터마다 OIDC	Role 재사용 가능
지원 환경	Fargate·Windows 포함	Linux EC2 노드만

갈리는 건 결국 OIDC 설정을 클러스터마다 하느냐, 그리고 그 제약에 걸리는 워크로드가 있느냐입니다.

고를 때 — Fargate·Windows 가 섞여 있는지부터

Pod Identity 는 Linux EC2 워커 노드에서만 됩니다. Fargate 로 띄우는 파드는 노드에 DaemonSet 을 붙일 수가 없어 Agent 가 못 뜨고, Windows 노드도 지원 대상이 아니라서, 이쪽이 섞여 있으면 그 워크로드는 IRSA 로 가야 합니다.

그 제약에 안 걸리는 신규 클러스터면 Pod Identity 가 설정이 단순해서 낫습니다. 기존에 IRSA 로 잘 돌고 있는 환경이라면 IRSA 도 계속 지원되니 급하게 바꿀 이유는 없습니다.

IRSA 는 OIDC Trust Policy 를 직접 관리하고 Pod Identity 는 그 관리를 EKS 서비스에 넘기는 것이라, 클러스터가 여러 개일수록 이 차이가 커집니다.

참고

• EKS Pod Identity — AWS 문서