EKS IRSA, Pod에 AWS 권한을 나눠주는 현실적인 방법

Kubernetes에서 실행되는 애플리케이션이 S3, DynamoDB, SQS 같은 AWS 서비스에 접근해야 할 때가 많아요. 이때 가장 쉬운 방법은 노드에 넓은 IAM 권한을 주고 Pod가 그 권한을 같이 쓰게 하는 거예요.

하지만 쉬운 방법이 항상 안전한 방법은 아니예요. 하나의 노드에 여러 Pod가 올라가고, 그 Pod들이 모두 노드 IAM 역할을 공유한다면 최소 권한 원칙은 금방 무너져요.

EKS의 IRSA, IAM Roles for Service Accounts는 이 문제를 해결하기 위한 방식이예요. Pod가 사용하는 Kubernetes ServiceAccount와 AWS IAM Role을 연결해, Pod 단위로 필요한 권한만 부여할 수 있어요.

노드 IAM 역할의 문제

IRSA 이전에도 Pod에서 AWS에 접근하는 방법은 있었어요. 대표적으로 EC2 인스턴스 프로파일을 사용하는 방식이예요.

이 방식은 간단해요. EKS 워커 노드에 IAM Role을 붙이고, Pod가 AWS SDK를 통해 자격 증명을 가져오게 하면 돼요. 문제는 권한의 범위예요.

같은 노드에 배치 작업 Pod, API 서버 Pod, 모니터링 Pod가 같이 있다면 각 Pod가 필요한 권한의 합집합이 노드 역할에 붙기 쉬워요. 어떤 Pod는 S3 읽기만 필요하고, 어떤 Pod는 SQS 쓰기만 필요해도 노드에는 두 권한이 모두 붙어요.

운영이 길어질수록 노드 역할은 점점 넓어지고, 어떤 Pod가 어떤 권한을 실제로 사용하는지 추적하기 어려워져요.

IRSA의 핵심 구조

IRSA는 Kubernetes ServiceAccount를 IAM Role과 연결해요. 애플리케이션 Pod는 특정 ServiceAccount로 실행되고, AWS SDK는 웹 아이덴티티 토큰을 사용해 해당 IAM Role을 AssumeRole 해요.

흐름은 다음과 같아요.

1. EKS 클러스터에 OIDC provider를 설정해요.
2. IAM Role의 trust policy에 특정 ServiceAccount만 역할을 맡을 수 있도록 조건을 둬요.
3. Kubernetes ServiceAccount에 IAM Role ARN을 어노테이션으로 지정해요.
4. Pod가 해당 ServiceAccount로 실행돼요.
5. AWS SDK가 토큰 파일을 읽고 STS를 통해 임시 자격 증명을 받아요.

이 방식의 장점은 권한 경계가 Pod에 가까워진다는 점이예요. 노드 전체가 아니라 ServiceAccount 단위로 권한을 관리할 수 있어요.

trust policy가 실질적인 경계입니다

IRSA를 설정할 때 가장 중요한 부분은 IAM Role의 trust policy예요. 단순히 역할을 만들고 정책을 붙이는 것으로 끝나지 않아요.

trust policy에는 어떤 OIDC provider에서 온 토큰을 신뢰할지, 어떤 namespace와 ServiceAccount가 역할을 맡을 수 있는지 조건을 넣어야 해요.

예를 들어 default namespace의 reporter ServiceAccount만 S3 읽기 역할을 맡을 수 있게 만들면, 다른 ServiceAccount는 같은 클러스터 안에 있어도 그 역할을 사용할 수 없어요.

여기서 조건을 느슨하게 잡으면 IRSA의 장점이 약해져요. system:serviceaccount:*:*처럼 넓은 조건을 두면 다시 권한이 퍼질 수 있어요.

IRSA와 EKS Pod Identity

AWS는 EKS Pod Identity도 제공해요. 그래서 지금 EKS 권한 설계를 한다면 IRSA만 볼 것이 아니라 Pod Identity와 함께 비교해야 해요.

IRSA는 OIDC provider와 IAM trust policy를 직접 다루는 방식이예요. 명시적이고 이식성이 좋지만, 역할마다 trust relationship을 관리해야 해요. EKS Pod Identity는 클러스터와 IAM 역할 연결을 더 관리형에 가깝게 다루며, role association을 통해 운영 부담을 줄이는 방향이예요.

둘 중 하나가 항상 정답은 아니예요. 이미 IRSA로 잘 운영 중이고 구조가 명확하다면 그대로 유지할 수 있어요. 새 클러스터에서 대규모로 ServiceAccount 권한을 붙여야 한다면 Pod Identity도 검토할 만해요.

운영에서 확인할 것

IRSA를 적용할 때는 세 가지를 먼저 확인해야 해요.

첫째, AWS SDK 버전이예요. AWS 공식 문서는 IRSA 사용 시 SDK가 웹 아이덴티티 토큰 파일을 통한 역할 위임을 지원해야 한다고 설명해요. 오래된 SDK를 쓰면 설정은 맞아도 자격 증명을 읽지 못할 수 있어요.

둘째, ServiceAccount와 Pod의 연결이예요. 어노테이션은 ServiceAccount에 있고, Pod는 해당 ServiceAccount로 실행되어야 해요. 이름이 비슷한 ServiceAccount를 잘못 쓰면 권한이 들어오지 않아요.

셋째, IAM policy의 범위예요. IRSA는 권한을 분리하는 구조일 뿐이예요. 붙이는 정책이 *라면 여전히 위험해요.

정리

IRSA는 EKS에서 Pod 단위로 AWS 권한을 나누기 위한 현실적인 방법이예요. 노드 IAM 역할에 권한을 몰아넣는 방식보다 추적하기 쉽고, 최소 권한 원칙에 더 가까워요.

다만 IRSA의 핵심은 "ServiceAccount에 Role ARN을 붙였다"가 아니예요. OIDC provider, trust policy, ServiceAccount, Pod 실행 계정, SDK 지원이 함께 맞아야 해요.

EKS에서 AWS 권한 문제가 반복된다면 먼저 물어야 할 질문은 단순해요. 이 권한은 노드가 필요한가, 아니면 특정 Pod만 필요한가? 특정 Pod만 필요하다면 IRSA나 Pod Identity 같은 Pod 단위 권한 모델을 검토해야 해요.

참고

• Amazon EKS - IAM roles for service accounts
• Amazon EKS - Assign IAM roles to Kubernetes service accounts
• Amazon EKS - Use IRSA with the AWS SDK