[AWS] EKS IRSA vs Pod Identity

JeongJun Min·2026년 2월 7일

Kubernetes

목록 보기

4/4

AWS EKS 서비스를 이용하다보면 IAM, 클러스터 접근 권한, RBAC 등 여러 권한 관리 설정이 필요한데, 그 중 Pod에 대한 권한 관리 방식을 알아보고 정리하려한다.

기존의 방식

EKS에서 돌아가는 애플리케이션은 AWS 리소스와 직접 통신을 하는 경우가 많다. S3에 파일을 업로드하거나 SQS로 메시지를 소비하는 등 애플리케이션을 실행하는 최소한의 권한을 위해 Pod 단위로 권한을 부여했다.

기존에 IRSA 없이 IAM 사용자에 특정 권한을 부여하고 Credential을 발급받아 AccessKey와 SecretKey를 등록하여 서비스에 접근할 수 있었다.

하지만 위 방식은 키 유출 위험이 크고, 추적이 어렵다는 단점이 존재한다.

ServiceAccount

Kubernetes는 Pod 내부에서 실행되는 애플리케이션이 Kubernetes API 서버와 안전하게 통신하기 위해 ServiceAccount를 만든다.ServiceAccount를 사용하면 애플리케이션 단위로 세밀한 접근 권한 관리가 가능해져 보안성과 운영 안정성을 높일 수 있다.

IRSA(IAM Roles for Service Accounts)

IRSA는 Kubernetes ServiceAccount + OIDC + IAM Role을 묶어서
Pod 단위로 AWS IAM 권한을 부여하는 방식이다.

EKS 클러스터에 OIDC Provider를 연결하고 특정 ServiceAccount에 IAM Role을 매핑하여, ServiceAccount를 사용하는 Pod가 해당 IAM Role을 Assume 하도록 만든다.

OIDC(OpenID Connect)
OAuth 2.0 프로토콜을 기반으로 한 3세대 인증 표준
OAuth 2.0은 인가(Authorization)을 담당하기에 이 사용자가 누구인지를 알 수가 없기 때문에 사용자 식별 정보가 포함된 JWT 형식의 ID 토큰을 발급하여 이 사람이 누군지를 검증하는 방식이다.

IRSA의 장점

IRSA을 사용하면 다음과 같은 장점을 가질 수 있다.

최소 권한 원칙
IRSA는 Kubernetes ServiceAccount 단위로 IAM Role을 부여할 수 있어 같은 노드에서 실행되는 Pod라도 서로 다른 AWS 권한을 갖게 할 수 있다.
이를 통해 특정 Pod가 필요한 AWS 리소스에만 접근하도록 제한할 수 있으며, 불필요한 권한 확장을 구조적으로 막을 수 있다.
결과적으로 하나의 Pod가 침해되더라도 영향 범위를 해당 Pod로 최소화할 수 있다.
자격 증명 관리
IRSA는 Access Key와 Secret Key를 애플리케이션이나 컨테이너 내부에 저장하지 않고, STS를 통해 임시 자격 증명을 자동으로 발급받는 방식을 사용한다.
이로 인해 키 유출 위험이 사라지고, 주기적인 키 로테이션이나 배포 재작업이 필요 없어 운영 부담이 크게 줄어든다.
또한 AWS SDK가 자격 증명 갱신을 자동으로 처리하므로 개발자가 자격 증명 관리에 신경 쓸 필요가 없다.
감사·추적 용이
IRSA를 사용하면 AWS CloudTrail 로그에 어떤 ServiceAccount를 사용하는 Pod가 어떤 IAM Role을 Assume 했는지가 명확하게 기록된다.
이를 통해 특정 AWS API 호출이 어떤 워크로드에서 발생했는지를 정확히 추적할 수 있다.
이러한 구조는 보안 사고 분석이나 외부 감사 대응 시 책임 주체를 빠르게 식별할 수 있게 해준다.

동작 흐름

EKS 클러스터에 OIDC Provider가 등록된다.
AWS가 EKS 클러스터가 발급하는 OIDC 토큰을 신뢰하도록 미리 등록해두는 과정이다.
특정 Kubernetes ServiceAccount에 IAM Role ARN이 어노테이션으로 매핑된다.
ServiceAccount를 통해 어떤 AWS 권한을 받을 수 있는지 미리 정의한다.
Pod가 해당 ServiceAccount를 사용하여 실행된다.
Pod는 ServiceAccount라는 신분을 가지고 실행되며, 이 시점에는 아직 AWS 권한을 직접 가지고 있지 않다.
Pod 내부의 AWS SDK는 Kubernetes가 발급한 OIDC JWT 토큰을 이용해 STS의 AssumeRoleWithWebIdentity API 를 호출한다.
AWS STS는 OIDC Provider를 통해 토큰의 유효성을 검증하고,
ServiceAccount가 해당 IAM Role을 사용할 수 있는지 Trust Policy를 확인한 후
임시 IAM 자격 증명을 발급한다.
Pod는 발급받은 임시 자격 증명을 사용해
S3, SQS 등 AWS 리소스에 접근한다.

Pod Identity

EKS Pod Identity는 2023년 12월에 새로 출시된 EKS Addon이다. IRSA와 마찬가지로 최소 권한 부여 원칙을 준수한다는 점에서 유사하지만, OIDC 자격 증명 공급자를 사용하지 않는다.
즉, 복잡한 구성을 덜어내어 구성이 쉽다는 장점이 있고, 같은 계정 내 여러 EKS 클러스터에 적용도 가능하다.

Pod Identity의 장점

구성 단순화
Pod Identity는 OIDC Provider 등록, ServiceAccount 어노테이션 설정 등 IRSA에서 필요한 복잡한 초기 구성을 제거했다.
IAM Role과 ServiceAccount의 연결을 AWS CLI 명령어 하나로 관리할 수 있다.
운영 편의성
IAM Role 매핑이 AWS 측에서 중앙 관리되기 때문에, 여러 EKS 클러스터를 운영하더라도 일관된 방식으로 권한을 관리할 수 있다.
또한, IRSA에서 자주 발생하던 Trust Policy 조건 오류나 토큰 관련 디버깅 부담이 줄어든다.
보안성 유지
IRSA와 마찬가지로 Access Key를 사용하지 않으며, STS 기반의 임시 자격 증명을 사용한다.
따라서 최소 권한 원칙과 자격 증명 보안이라는 핵심 가치는 그대로 유지된다.

Pod Identity 동작 흐름

EKS 클러스터에 Pod Identity Addon이 설치된다.
(Pod Identity Agent가 각 노드에 배포됨)
IAM Role을 생성하고, 해당 Role과 Kubernetes ServiceAccount를 연결하는
Pod Identity Association을 생성한다.
Pod가 지정된 ServiceAccount를 사용해 실행된다.
Pod 내부 AWS SDK가 자격 증명을 요청하면, Pod Identity Agent가 이를 가로채어 EKS 컨트롤 플레인과 통신한다.
EKS 컨트롤 플레인은 해당 Pod + ServiceAccount + Association 정보를 검증한 뒤
STS를 통해 임시 IAM 자격 증명을 발급한다.
Pod는 별도 설정 없이 AWS SDK를 통해 AWS 리소스에 접근한다.