METAVERSE TIMES: [AWS IRSA] IAM Roles for Service Accounts !!

IRSA는 EKS (Amazon Elastic Kubernetes Service) 환경에서 Pod 단위로 AWS 리소스 접근 권한을 안전하게 부여하기 위해 사용하는 핵심 기술입니다.

1️⃣ IRSA란?

IRSA (IAM Roles for Service Accounts) 는
EKS 클러스터에서 Kubernetes Service Account 와 AWS IAM Role 을 연결(Link) 시켜
Pod가 AWS 리소스(S3, DynamoDB, SQS 등)에 접근할 수 있도록 하는 권한 관리 메커니즘입니다.

기존에는 EC2 노드 단위로 IAM Role을 부여했지만,
IRSA는 Pod 단위로 세밀한 권한 제어가 가능하도록 개선되었습니다.

2️⃣ IRSA 도입 배경

EKS 이전 세대에서는 모든 Pod 가 EC2 노드의 IAM Role 을 공유했습니다.

항목	기존 방식 (EC2 Role)	IRSA 방식
권한 부여 단위	Node (EC2 인스턴스)	Pod (Service Account)
보안성	낮음 (모든 Pod가 동일 권한 가짐)	높음 (Pod별 최소 권한 적용 가능)
관리 복잡도	높음	낮음
세분화된 접근 제어	불가능	가능

➡ 즉, IRSA는 “Least Privilege(최소 권한 원칙)” 을 Kubernetes 환경에서도 구현하기 위한 기능입니다.

3️⃣ IRSA 동작 원리

IRSA는 OIDC(OpenID Connect) 기반의 연합 인증 (Federation) 을 사용합니다.
즉, AWS가 EKS 클러스터의 Service Account를 신뢰하도록 설정하고,
Pod가 해당 SA(ServiceAccount)로 실행될 때 AWS 자격 증명을 임시로 발급받는 구조입니다.

IRSA의 구성 요소

OIDC Provider
- AWS IAM에서 EKS 클러스터의 OIDC 엔드포인트를 신뢰하도록 설정합니다.
- 예: https://oidc.eks.ap-northeast-2.amazonaws.com/id/EXAMPLE123456
IAM Role (with Trust Policy)
- 해당 OIDC Provider에서 특정 Service Account만 Role을 Assume하도록 허용합니다.
Kubernetes Service Account (SA)
- eks.amazonaws.com/role-arn 주석(annotation)으로 IAM Role을 연결합니다.
Pod
- 연결된 SA를 사용하여 실행되면, STS(보안 토큰 서비스)를 통해 임시 자격 증명을 발급받고 AWS API에 접근합니다.

4️⃣ IRSA 동작 순서 (흐름도 이해)

관리자가 EKS 클러스터에 OIDC Provider 등록
→ eksctl utils associate-iam-oidc-provider 명령어 사용

관리자가 IAM Role 생성 및 Trust Policy 설정


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<ACCOUNT_ID>:oidc-provider/oidc.eks.ap-northeast-2.amazonaws.com/id/EXAMPLE123456"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.ap-northeast-2.amazonaws.com/id/EXAMPLE123456:sub": "system:serviceaccount:default:my-service-account"
        }
      }
    }
  ]
}

해당 Role을 사용할 Kubernetes Service Account 생성


apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: default
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::<ACCOUNT_ID>:role/my-irsa-role

Pod가 위 Service Account를 사용하여 실행됨


apiVersion: v1
kind: Pod
metadata:
  name: s3-access-pod
spec:
  serviceAccountName: my-service-account
  containers:
    - name: s3
      image: amazon/aws-cli
      command: ["aws", "s3", "ls"]

Pod 내부의 AWS SDK 또는 CLI는 자동으로 STS를 통해 임시 인증 토큰을 획득하고 AWS API 호출을 수행함

5️⃣ IRSA 장점

항목	설명
보안 강화	Pod 단위로 세밀한 권한 부여 가능 (노드 Role 공유 불필요)
IAM 자격증명 노출 최소화	환경 변수나 시크릿에 자격 증명을 직접 저장할 필요 없음
관리 효율성 향상	Pod/ServiceAccount 기반으로 IAM 관리 자동화 가능
감사 및 추적 용이성	CloudTrail을 통해 어떤 Pod/ServiceAccount가 어떤 Role로 접근했는지 추적 가능

6️⃣ 실무 적용 예시

예를 들어, 특정 애플리케이션이 S3 버킷 에만 접근해야 한다면:

S3 전용 정책을 가진 IAM Role 생성


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket", "s3:GetObject", "s3:PutObject"],
      "Resource": ["arn:aws:s3:::my-app-bucket/*"]
    }
  ]
}

해당 Role을 Pod의 ServiceAccount와 연결
👉 이 Pod만 S3에 접근 가능하며, 다른 Pod는 접근 불가

7️⃣ IRSA 구축 시 주의사항

OIDC Provider 등록 필수
- EKS 클러스터마다 고유한 OIDC 엔드포인트가 있으므로 클러스터 생성 후 반드시 연결해야 함.
Trust Policy Condition 정확히 지정
- namespace와 serviceaccount 식별자(sub)가 정확해야 보안상 안전함.
AWS SDK 버전 확인
- IRSA는 STS AssumeRoleWithWebIdentity API를 사용하므로, SDK 버전이 최신이어야 함.
Pod 재시작 필요
- ServiceAccount에 Role 연결 후에는 Pod를 재시작해야 새로운 IAM Role이 반영됨.

8️⃣ 정리

구분	내용
기능 요약	Pod 단위 IAM Role 연동 기능
핵심 기술	OIDC 기반 연합 인증 (Federation)
사용 목적	최소 권한 부여(Least Privilege) 실현
적용 대상	EKS Pod, ServiceAccount
장점	보안성, 관리 효율성, 추적성 모두 향상

9️⃣ 참고 명령어


# OIDC Provider 연결
eksctl utils associate-iam-oidc-provider --cluster my-cluster --approve

# IAM Role 생성 (AWS CLI)
aws iam create-role --role-name my-irsa-role \
  --assume-role-policy-document file://trust-policy.json

# IAM Policy 연결
aws iam attach-role-policy --role-name my-irsa-role \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

METAVERSE TIMES

[AWS IRSA] IAM Roles for Service Accounts !!