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