0Pricing
AWS Solutions Architect · 강의

서비스 계정을 위한 IAM 역할(IRSA)

IRSA를 사용해 세분화된 IAM 역할을 Kubernetes 서비스 계정에 연결하고, 노드 수준 권한 없이 파드가 AWS 서비스에 액세스하도록 합니다.

서비스 계정을 위한 IAM 역할(IRSA)은(는) CoddyKit의 무료 AWS Solutions Architect 강의입니다. 이것은 4개 중 4번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 AWS Solutions Architect 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. AWS Solutions Architect 강의에는 총 4개의 강의가 포함되어 있습니다.

Pod의 IAM 문제

EKS에서 실행 중인 pod가 AWS API를 호출해야 하는 경우(예: S3에서 읽거나 DynamoDB에 쓰는 경우) AWS 자격 증명이 필요합니다. 단순한 방법은 IAM 사용자를 생성하고 해당 액세스 키를 환경 변수로 하드코딩하는 것입니다. 하지만 같은 노드의 모든 pod가 자격 증명을 공유하므로 이는 안전하지 않으며 최소 권한 원칙에도 위배됩니다. 서비스 계정용 IAM 역할(IRSA)은 세분화된 IAM 역할을 Kubernetes 서비스 계정에 직접 연결하여 이 문제를 해결합니다.

IRSA 작동 방식: OIDC 연합

IRSA는 OpenID Connect (OIDC) 연합을 통해 작동합니다. EKS는 클러스터에 대한 OIDC 공급자를 생성합니다. pod가 IAM 역할 ARN으로 주석이 지정된 서비스 계정을 참조하면 EKS는 서명된 투영된 서비스 계정 토큰을 pod에 주입합니다. pod의 AWS SDK는 AWS STS의 AssumeRoleWithWebIdentity API를 사용하여 이 토큰을 임시 AWS 자격 증명으로 교환하므로 장기 키가 필요하지 않습니다.

# View the OIDC issuer URL for your cluster
aws eks describe-cluster \
  --name my-cluster \
  --query 'cluster.identity.oidc.issuer' \
  --output text

# Example output:
# https://oidc.eks.us-east-1.amazonaws.com/id/EXAMPLEIDSTRING

1단계: OIDC 공급자 연결

IRSA를 사용하기 전에 EKS OIDC 발급자를 AWS 계정에서 신뢰할 수 있는 자격 증명 공급자로 연결해야 합니다. 그러면 AWS STS가 인식하는 IAM OIDC 공급자 리소스가 생성됩니다. eksctl 명령이 이 작업을 자동으로 처리합니다. 생성이 완료되면 IAM 콘솔의 자격 증명 공급자에서 이를 확인할 수 있습니다.

# Associate the OIDC provider using eksctl (simplest method)
eksctl utils associate-iam-oidc-provider \
  --region us-east-1 \
  --cluster my-cluster \
  --approve

# Verify the provider was created
aws iam list-open-id-connect-providers \
  --query 'OpenIDConnectProviderList[].Arn'

2단계: IAM 역할 생성

IRSA용 IAM 역할에는 OIDC 공급자가 해당 역할을 맡을 수 있도록 허용하는 신뢰 정책이 있어야 하며, 이 정책의 범위는 특정 Kubernetes 네임스페이스와 서비스 계정으로 제한되어야 합니다. 조건에서는 OIDC 토큰의 sub 클레임을 사용하며, 이 값은 system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME으로 설정됩니다. 따라서 클러스터의 어떤 pod가 아니라 해당 서비스 계정을 사용하는 pod만 역할을 맡을 수 있습니다.

# Trust policy for the IRSA role (JSON)
# {
#   "Version": "2012-10-17",
#   "Statement": [{
#     "Effect": "Allow",
#     "Principal": {
#       "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLEID"
#     },
#     "Action": "sts:AssumeRoleWithWebIdentity",
#     "Condition": {
#       "StringEquals": {
#         "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLEID:sub":
#           "system:serviceaccount:production:s3-reader"
#       }
#     }
#   }]
# }

3단계: 서비스 계정에 주석 지정

대상 네임스페이스에 Kubernetes ServiceAccount를 생성하고 IAM 역할 ARN으로 주석을 지정합니다. pod가 이 서비스 계정을 참조하면 EKS는 OIDC 토큰과 두 개의 환경 변수(AWS_WEB_IDENTITY_TOKEN_FILE 및 AWS_ROLE_ARN)를 자동으로 주입합니다. AWS SDK는 이를 자동으로 감지하고 STS를 호출하여 임시 자격 증명을 가져오므로 애플리케이션 코드를 변경할 필요가 없습니다.

# Create and annotate the Kubernetes service account
kubectl create serviceaccount s3-reader -n production

kubectl annotate serviceaccount s3-reader \
  -n production \
  eks.amazonaws.com/role-arn=arn:aws:iam::111122223333:role/S3ReaderRole

# Verify the annotation
kubectl describe serviceaccount s3-reader -n production

4단계: pod에서 서비스 계정 참조

pod 또는 배포 명세에서 serviceAccountName을 주석이 지정된 서비스 계정으로 설정합니다. EKS가 pod를 스케줄링하면 OIDC 토큰을 /var/run/secrets/eks.amazonaws.com/serviceaccount/token에 자동으로 마운트하고 필요한 환경 변수를 설정합니다. pod 내부에서 이루어지는 모든 AWS SDK 호출은 별도의 자격 증명 설정 없이 매핑된 IAM 역할 자격 증명을 투명하게 사용합니다.

# Pod spec using IRSA service account
apiVersion: v1
kind: Pod
metadata:
  name: s3-app
  namespace: production
spec:
  serviceAccountName: s3-reader
  containers:
  - name: app
    image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/my-app:latest
    # AWS SDK auto-detects IRSA — no credential config needed
    # AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN are injected

IRSA와 노드 IAM 역할의 주요 차이점

노드 IAM 역할을 사용하면 노드의 모든 pod가 동일한 권한을 물려받으므로, 침해된 pod가 해당 노드에 허용된 모든 AWS 서비스에 접근할 수 있습니다. 반면 IRSA에서는 각 pod가 서비스 계정을 통해 필요한 역할만 맡습니다. 이는 pod 수준에서 최소 권한 원칙을 따르며 보안 사고가 발생했을 때 피해 범위를 제한합니다. AWS는 새 EKS 배포에서 노드 수준 역할보다 IRSA를 사용할 것을 권장합니다.

eksctl을 사용한 IRSA 역할 생성

eksctl은 create iamserviceaccount를 사용한 단일 명령으로 OIDC 연결, IAM 역할, 신뢰 정책, Kubernetes ServiceAccount 주석을 생성할 수 있습니다. 따라서 신뢰 정책 JSON을 직접 작성하지 않고 IRSA를 설정하는 가장 간단한 방법입니다. 네임스페이스, 서비스 계정 이름, 연결할 IAM 정책 ARN을 지정하면 나머지는 eksctl이 처리합니다.

# Create everything needed for IRSA in one command
eksctl create iamserviceaccount \
  --name s3-reader \
  --namespace production \
  --cluster my-cluster \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
  --approve \
  --override-existing-serviceaccounts

AWS 추가 기능에 IRSA 사용

많은 EKS 추가 기능과 컨트롤러가 작동하려면 IRSA가 필요합니다. 클러스터 자동 확장기에는 EC2 Auto Scaling API를 호출할 권한이 필요하고, AWS 로드 밸런서 컨트롤러에는 ELB 리소스를 생성하고 관리할 권한이 필요합니다. 외부 DNS에는 Route 53에 쓸 권한이 필요하며, EBS CSI 드라이버에는 EBS 볼륨을 생성하고 연결할 권한이 필요합니다. 이러한 시스템 구성 요소에는 항상 IRSA를 사용하고, 노드 IAM 역할 수준에서 권한을 부여하지 마십시오.

# Create IRSA for the EBS CSI driver
eksctl create iamserviceaccount \
  --name ebs-csi-controller-sa \
  --namespace kube-system \
  --cluster my-cluster \
  --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
  --approve \
  --role-name AmazonEKS_EBS_CSI_DriverRole

토큰 갱신 및 자격 증명 교체

IRSA 토큰은 수명이 짧으며 만료되기 전에 Kubernetes 토큰 투영 컨트롤러가 자동으로 교체합니다. 기본 토큰 대상은 sts.amazonaws.com이고 만료 시간은 24시간이지만, 컨트롤러는 수명의 80%가 지나면 토큰을 갱신합니다. IRSA를 통해 얻는 AWS STS 자격 증명도 임시 자격 증명이며 일반적으로 1시간 동안 유효합니다. 이러한 자동 교체 덕분에 장기 IAM 액세스 키를 사용할 때 발생하는 자격 증명 교체 부담이 사라집니다.

# Inspect the projected service account token inside a pod
kubectl exec -n production s3-app -- \
  cat /var/run/secrets/eks.amazonaws.com/serviceaccount/token

# Decode the JWT header and payload to see expiry and audience
# jwt.io or: base64 -d <<< "PAYLOAD_SECTION"

CloudTrail로 IRSA 사용 감사

pod가 IRSA를 통해 IAM 역할을 맡을 때마다 AWS CloudTrail은 AssumeRoleWithWebIdentity 이벤트를 기록합니다. 이 이벤트에는 맡은 역할 ARN, OIDC 토큰 주체(system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT), 원본 IP가 포함됩니다. 따라서 어떤 pod가 어떤 AWS 서비스에 언제 접근했는지에 대한 완전한 감사 추적을 확보할 수 있으며, 이는 규제가 적용되는 환경의 규정 준수와 사고 조사에 매우 중요합니다.

# Search CloudTrail for IRSA calls
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRoleWithWebIdentity \
  --start-time '2024-01-01T00:00:00Z' \
  --query 'Events[].{Time:EventTime,Role:CloudTrailEvent}' \
  --output table

빠른 확인

이 단원에서 다룬 AWS Solutions Architect (SAA-C03) 개념을 제대로 이해했는지 확인해 보십시오.

단원 요약

이 단원에서는 다음을 배웠습니다. IRSA는 OIDC 연합을 사용하여 Kubernetes 서비스 계정 토큰을 임시 AWS 자격 증명으로 교환하고, IAM 역할 신뢰 정책은 특정 네임스페이스와 서비스 계정으로 접근 범위를 제한하며, IRSA는 pod별 최소 권한을 제공하여 노드 수준 IAM 역할보다 훨씬 뛰어난 보안을 제공합니다. 다음 단원에서는 AWS 리소스를 관찰하기 위한 CloudWatch Metrics, Namespaces, Dimensions를 살펴봅니다.

자주 묻는 질문

“서비스 계정을 위한 IAM 역할(IRSA)” 강의는 무료인가요?

네 — “서비스 계정을 위한 IAM 역할(IRSA)” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 AWS Solutions Architect 강의 전체를 잠금 해제할 수 있습니다. AWS Solutions Architect 강의에는 총 4개의 강의가 포함되어 있습니다.

“서비스 계정을 위한 IAM 역할(IRSA)”에서 뭘 배우나요?

IRSA를 사용해 세분화된 IAM 역할을 Kubernetes 서비스 계정에 연결하고, 노드 수준 권한 없이 파드가 AWS 서비스에 액세스하도록 합니다. 브라우저에서 직접 실행하는 실습 코드로 AWS Solutions Architect을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

AWS Solutions Architect을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 AWS Solutions Architect은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 4번째 강의입니다.

“서비스 계정을 위한 IAM 역할(IRSA)” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 AWS Solutions Architect 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 AWS Solutions Architect 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

  1. EKS 컨트롤 플레인 및 워커 노드
  2. 서버리스 파드를 위한 Fargate 프로필
  3. EKS 네트워킹: VPC CNI 및 로드 밸런싱
  4. 서비스 계정을 위한 IAM 역할(IRSA)
← AWS Solutions Architect(으)로 돌아가기