sequenceDiagram
participant User
participant ClientApp
participant IdentityProvider
participant ResourceServer
User->>ClientApp: 로그인 요청
ClientApp->>IdentityProvider: 인증 요청
IdentityProvider-->>User: 로그인 페이지
User->>IdentityProvider: 로그인 정보 입력
IdentityProvider->>ClientApp: Access Token 발급
ClientApp->>ResourceServer: Access Token 검증 및 리소스 요청
ResourceServer-->>ClientApp: 리소스 제공
ClientApp-->>User: 서비스 접근 허용
Pod Identity vs IRSA 비교표
비교 항목
Pod Identity (Pod Identity Agent + EKS Auth API)
IAM Role for Service Account (IRSA)
OIDC 사용 여부
X (불필요)
O
IAM Role 연결 방식
Pod Identity Association으로 ServiceAccount에 매핑
ServiceAccount 어노테이션으로 IAM Role 연결
AWS STS 호출 여부
X (EKS Auth API 호출)
O (AssumeRoleWithWebIdentity)
EKS API Server 인증 과정
Pod Identity Agent가 EKS Auth API로 자격 증명 요청
OIDC Provider 통해 STS에서 토큰 검증 후 발급
EKS 외부 접근 가능 여부
X (Agent 의존)
O (OIDC 페더레이션)
AssumeRole 시점
Pod 실행 시 Agent가 EKS Auth API로 자격 증명 획득
Pod가 OIDC 토큰으로 STS AssumeRoleWithWebIdentity 호출
사용 예시
EKS 내부 Pod가 AWS 서비스 접근 (설정 간편)
OIDC 페더레이션·EKS 외부 접근이 필요한 경우
EKS Pod Identity 인증 프로세스
sequenceDiagram
participant User as 사용자
participant Kubernetes as Kubernetes Cluster (EKS)
participant ServiceAccount as Kubernetes ServiceAccount
participant Pod as Pod (앱 컨테이너)
participant Agent as EKS Pod Identity Agent
participant EKSAuth as EKS Auth API
participant AWS_Service as AWS 서비스 (예: S3, DynamoDB)
User->>Kubernetes: Pod 실행 요청 (ServiceAccount 설정 포함)
Kubernetes->>ServiceAccount: Pod에 ServiceAccount 연결 (Pod Identity Association)
Pod->>Agent: 자격 증명 요청 (AWS_CONTAINER_CREDENTIALS_FULL_URI)
Agent->>EKSAuth: AssumeRoleForPodIdentity 호출 (OIDC 미사용)
EKSAuth->>Agent: 임시 AWS 자격 증명 반환 (AccessKey, SecretKey, Token)
Agent->>Pod: 임시 자격 증명 전달
Pod->>AWS_Service: IAM Role 기반의 인증으로 AWS 서비스 접근
AWS_Service-->>Pod: 요청된 데이터 반환
IAM Role for Service Account (IRSA) 프로세스
sequenceDiagram
participant Pod as Pod (애플리케이션 컨테이너)
participant ServiceAccount as Kubernetes ServiceAccount
participant AWS_OIDC as AWS OIDC Provider
participant IAM as AWS IAM Role
participant STS as AWS Security Token Service (STS)
participant AWS_Service as AWS 서비스 (S3, DynamoDB 등)
participant Pod_Env as Pod 내부 환경 변수
Pod->>ServiceAccount: OIDC 토큰 요청
ServiceAccount->>AWS_OIDC: OIDC 토큰을 AWS OIDC Provider에 전달
AWS_OIDC->>STS: ID 토큰 검증 요청
STS->>AWS_OIDC: 검증 완료 응답
ServiceAccount->>IAM: IAM Role과 연결된 ServiceAccount 인증
IAM->>STS: AssumeRoleWithWebIdentity 호출 (OIDC 토큰 포함)
STS->>IAM: 임시 AWS 보안 자격 증명 (AccessKey, SecretKey, Session Token) 발급
IAM->>Pod_Env: Pod 내부 환경 변수에 자격 증명 저장
Pod->>AWS_Service: AWS 서비스 요청 (IAM Role 기반 인증)
AWS_Service-->>Pod: 요청된 데이터 반환
Pod Identity 시나리오
상황
비고
OIDC Provider 설정 없이 인증하고 싶을 때
OIDC 구성 없이 Pod Identity Association만으로 ServiceAccount와 IAM Role을 연결할 수 있음
EKS 클러스터 내부 Pod에서 AWS 접근이 필요할 때
노드의 Pod Identity Agent가 자격 증명을 발급하므로 클러스터 내부에서만 동작함 (외부 접근 불가)
단기 자격 증명이 필요할 때
EKS Auth API가 발급하는 임시 자격 증명은 짧은 TTL(Time-To-Live)을 가지므로, 보안성이 향상됨
하나의 IAM Role을 여러 클러스터에서 재사용하고 싶을 때
신뢰 관계를 EKS가 관리하므로 IAM Role 신뢰 정책 수정 없이 여러 클러스터에서 사용 가능함
STS 호출 없이 자격 증명을 발급받고 싶을 때
Pod Identity Agent가 AssumeRoleForPodIdentity를 호출하여 STS 없이 자격 증명을 가져올 수 있음
Pod Identity 방식은 OIDC 설정 없이 Pod Identity Agent가 자격 증명을 발급하므로,
EKS 클러스터 내부 Pod에서 간편하게 AWS 서비스에 접근해야 하는 경우 적합
IAM Role for Service Account (IRSA) 시나리오
상황
비고
EKS 내부에서 AWS 서비스 접근이 필요할 때
Kubernetes ServiceAccount와 IAM Role을 1:1 매핑하여 AWS 리소스 접근이 가능