AWS IRSA 개념과 적용 방법

1. IRSA란

IRSA는 AWS의 OpenID Connect(OIDC) 공급자와 EKS의 통합을 활용하여 Kubernetes 서비스 계정(Service Account)이 IAM 역할을 수행할 수 있도록 지원하는 기능이다. 이를 통해 공유 자격 증명이나 광범위한 권한을 가진 EC2 인스턴스 역할(Node Role)에 의존할 필요가 없어진다.

각 서비스 계정은 특정 AWS 권한을 정의하는 IAM 역할에 바인딩된다. 파드는 이 서비스 계정을 통해 자신에게 허용된 AWS 리소스에만 접근할 수 있게 되며, 다음과 같은 이점을 얻는다.

• 강화된 보안: 정적 AWS 자격 증명이나 과도한 권한이 부여된 인스턴스 역할을 제거한다.
• 세분화된 권한 제어: 각 파드는 역할에 따라 전용 최소 권한 액세스만 획득한다.
• 향상된 감사 기능: 파드 단위로 수행된 API 호출을 CloudTrail에서 추적할 수 있다.
• 간소화된 관리: kiam이나 kube2iam 같은 별도의 도구 없이 AWS 방식으로 권한을 관리한다.

 

2. 상황 예시

IRSA의 필요성을 이해하기 위해 어떤 서비스에 두 종류의 파드가 있다고 가정

1. Image-Pod: 사용자 프로필 사진을 AWS S3에 업로드한다.
2. Order-Pod: 주문 내역을 AWS DynamoDB에 기록한다.

IRSA 적용 전

기존에는 워커 노드(EC2) 자체에 IAM 역할을 부여하여 권한을 제어. 노드 하나에 실행되는 모든 파드가 노드의 권한을 공유하기 때문에 다음과 같은 문제가 발생한다.

• 설정: 노드에 'S3 쓰기'와 'DynamoDB 쓰기' 권한을 모두 부여한다.
• 문제점: Image-Pod는 S3 권한만 필요함에도 불구하고, 노드의 권한을 상속받아 DynamoDB에도 접근이 가능하다. 만약 Image-Pod만 노출되어도, 공격자는 DynamoDB까지 접근가능

IRSA 적용 후

IRSA를 적용하면 파드별로 필요한 권한만 할당할 수 있다.

• Image-Pod: S3 접근 권한만 부여된 IAM Role 사용
• Order-Pod: DynamoDB 접근 권한만 부여된 IAM Role 사용

 

3. IRSA 적용 예시

Image-Pod가 S3 버킷에 접근할 수 있도록 권한을 부여하는 과정을 예시로 설명한다.

Step 1. AWS IAM 정책 및 역할 생성

먼저 S3 접근 권한을 가진 IAM Role을 생성한다. 핵심은 신뢰 관계(Trust Relationship) 설정이다. 이 역할은 특정 EKS 클러스터의 특정 Service Account만이 수행할 수 있도록 제한해야 한다.

 

trust-policy.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<ACCOUNT_ID>:oidc-provider/<OIDC_PROVIDER>"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "<OIDC_PROVIDER>:sub": "system:serviceaccount:<NAMESPACE>:<SERVICE_ACCOUNT>"
        }
      }
    }
  ]
}

위 정책 파일(trust-policy.json)을 사용하여 IAM 역할을 생성한다.

aws iam create-role --role-name my-irsa-role --assume-role-policy-document file://trust-policy.json

 

Step 2. Kubernetes Service Account 생성

Kubernetes 클러스터 내에 Service Account를 생성하고, 앞서 만든 IAM Role의 ARN을 Annotation으로 연결한다.

 

serviceaccount.yaml

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

 

Step 3. 파드(Pod) 배포

파드 배포 시 spec.serviceAccountName 필드에 위에서 생성한 Service Account를 지정한다.

 

apiVersion: v1
kind: Pod
metadata:
  name: image-pod
  namespace: <NAMESPACE>
spec:
  serviceAccountName: <SERVICE_ACCOUNT>
  containers:
  - name: uploader
    image: my-upload-app:1.0

 

4. 파드 내부의 작동 원리

설정을 마치고 파드가 생성되면, EKS와 AWS SDK는 다음과 같이 동작하여 별도의 키 관리 없이 인증을 수행한다.

1. 환경 변수: EKS는 파드 내부에 AWS_ROLE_ARN(사용할 IAM 역할)과 AWS_WEB_IDENTITY_TOKEN_FILE(인증 토큰 경로) 환경 변수를 자동으로 주입한다.
2. 토큰 교환: 파드 내부의 애플리케이션이 AWS SDK를 사용하면, SDK는 위 환경 변수를 감지하고 토큰 파일을 읽어 AWS STS(Security Token Service)에 전송한다.
3. 임시 자격 증명 획득: STS는 토큰을 검증하고 임시 보안 자격 증명(Access Key, Secret Key, Session Token)을 발급한다.
4. API 호출: 애플리케이션은 발급받은 임시 키를 사용하여 S3 등 AWS 리소스에 접근한다.

Python boto3 예시

import boto3

# 별도의 키 설정 불필요, 자동으로 환경변수를 감지하여 인증 수행
s3 = boto3.client('s3')
s3.list_buckets()

 

5. 요약

구성 요소	역할 및 설명
IAM Role	S3, DynamoDB 등 실제 리소스 접근 권한을 가진 AWS 역할. Trust Policy를 통해 특정 K8s Service Account만 이 역할을 사용할 수 있도록 제한한다.
Service Account	IAM Role의 ARN이 Annotation으로 명시된 Kubernetes 계정. 파드와 IAM 역할을 연결하는 매개체 역할을 한다.
Pod	Service Account를 사용하여 실행되는 애플리케이션. AWS SDK가 내부적으로 토큰을 사용하여 자동으로 인증을 수행한다.
OIDC Provider	AWS IAM이 EKS 클러스터에서 온 요청의 신원을 확인할 수 있도록 돕는 신원 보증 기관.