Overview
IRSA(IAM Roles for Service Accounts)는 AWS EKS 환경에서 Kubernetes의 ServiceAccount와 AWS IAM Role을 연결하여, Pod 단위로 AWS 리소스에 대한 접근 권한을 부여할 수 있는 메커니즘이다.
이는 기존에 노출되기 쉬운 IAM Access Key를 사용하는 방식보다 훨씬 안전하며, 클라우드 네이티브 환경에 적합한 권한 관리 방식으로 자리잡고 있다.
IRSA의 핵심 구성 요소는 다음과 같다.
- ServiceAccount (Kubernetes 내부 주체)
- IAM Role (AWS 권한 주체)
- OIDC Provider (EKS에서 자동 제공하는 인증 토큰 발급자)
- AWS STS (IAM Role을 임시로 Assume해주는 역할)
이러한 요소들이 상호작용하여, Pod가 실행 중인 컨테이너 내부의 AWS SDK 또는 CLI가 자동으로
IAM Role 기반의 임시 자격 증명을 통해 S3, DynamoDB, ECR 등의 리소스에 안전하게 접근할 수 있게 해준다.
IRSA는 특히 보안 요구가 높은 기업 환경, 멀티팀 클러스터 운영, GitOps 기반 배포 환경 등에서 활용도가 높다.
📅 관련 글
2022.02.13 - [AWS] - AWS IAM (Identity and Access Management) 개요 및 설정 방법
2022.02.07 - [AWS] - AWS EC2 인스턴스 생성
2022.02.13 - [AWS] - AWS S3 (Simple Storage Service) 개요 및 활용 방법
2023.03.30 - [AWS] - AWS Secrets Manager란?(OAuth, SSO)
2023.03.29 - [AWS] - AWS CLI 정리
2023.03.28 - [AWS] - AWS IAM이란?
2023.03.28 - [AWS] - AWS S3 권한이란?
2023.03.28 - [AWS] - AWS S3란?(개념, 속성)
2023.03.30 - [AWS] - AWS Cloudfront란? / Canary 및 Blue-Green 배포
2023.04.03 - [AWS] - AWS VPC란?
2023.05.26 - [AWS] - AWS IRSA(IAM Roles for Service Accounts)란?
2024.11.07 - [AWS] - AWS Ingress Annotations 정리
2024.11.04 - [AWS] - AWS Assume Role이란?
2024.11.16 - [AWS] - AWS Network ACL vs Security Group
2024.11.21 - [AWS] - ALB access Log 활성화 → S3 권한 설정 및 로그 저장
2024.11.24 - [AWS] - EKS Pod Identity Addon
2024.11.27 - [AWS] - AWS DynamoDB란?
2025.01.03 - [AWS] - AWS DynamoDB Local 설치
AWS IRSA(IAM Roles for Service Accounts)란?
AWS IRSA(IAM Roles for Service Accounts)는 AWS EKS(Elastic Kubernetes Service)에서 관리하는 Kubernetes 클러스터에서 실행되는 파드에서 ServiceAccount를 사용하여 AWS 서비스에 대한 액세스 권한을 부여하는 방법이다.
그렇다면 ServiceAccount는 AWS의 자원이 아닌데 어떻게 IAM Role을 할당할 수 있는 걸까?
바로 OIDC라고 부르는 OpenID Connect와 STS라고 부르는 Security Token Service가 해당 기능을 수행해준다.
Service Account란?
Kubernetes Service Account는 쿠버네티스 클러스터 내에서 실행되는 팟(Pod)이 API 서버와 상호 작용할 수 있도록 권한을 부여하는 데 사용되는 자격증명이다. 서비스 어카운트는 특정 네임스페이스(namespace)에 속하며, 자동으로 생성되거나 사용자가 직접 생성할 수 있다.
AWS 에서 IAM Role 생성 + K8S에서 serviceaccount 생성
eksctl create iamserviceaccount --cluster=test-cluster --name=test-role --attach-policy-arn=arn:aws:iam::aws:policy/AmazonS3FullAccess --approve --profile <aws profile>
OIDC(OpenID Connect)란?
OIDC는 인증 서버에서 수행한 인증을 기반으로 앱이 최종 사용자의 신원을 확인할 수 있도록 하는 인증 프로토콜인 OpenID Connect의 약자이다.
OAuth 2.0 기술을 이용하여 만들어진 인증 레이어로 JSON 포맷을 이용하여 RESTful API 형식으로 인증을 하게 된다.
OpenID Connect는 OAuth 2.0 프로토콜 위에 구축되어 인증 서버가 리소스 소유자 또는 최종 사용자의 승인을 받아 타사 애플리케이션에 대한 액세스 토큰을 발급할 수 있다. 애플리케이션은 액세스 토큰을 사용하여 최종 사용자를 대신하여 API에 인증할 수 있으며, OIDC는 OAuth 2.0을 확장하여 ID 토큰을 도입하여 인증을 추가한다.
EKS OIDC 생성
eksctl utils associate-iam-oidc-provider --region=ap-northeast-2 --cluster=test-cluster --approve
EKS OIDC 조회
aws eks describe-cluster --name luxon --query "cluster.identity.oidc.issuer" --output text --profile <profile> --region <region>
https://oidc.eks.<region>.amazonaws.com/id/554xxxxxxxxxxxxxxxxxxxxxxxxxxx
AWS STS(Security Token Service)란?
AWS 리소스에 접근할 수 있는 권한에 대해 임시자격 증명을 가져오도록 하는 서비스이다.
AWS IRSA Workflow
아래의 Workflow는 Pod에서 동작하는 Application이 AWS S3 Bucket list를 가져올때의 예시이다.
물론 EKS 내부의 다른 리소스들에 접근할 수 있는 권한 (EKS → EKS)이 있다는 가정다.
해당 권한은 보통 Kubernetes RBAC(Role-Based Access Control)로 설정한다.
- JWT와 IAM Role 의 ARN정보를 AWS STS에게 전달 한다.
- STS는 AWS IAM에게 임시 자격증명을 줄 수 있는지 확인을 요청한다.
- IAM은 IAM OIDC Provider와 통신하고, Pod에 할당된 ServiceAccount에 IAM Role 정보가 Annotate되어 있는 지 확인한 후에 IAM에게 확인 되었다는 응답을 주게 된다.
- IAM은 STS에게 권한을 줘도 된다고 응답을 주게 된다.
- AWS STS는 Pod의 AWS SDK에게 임시 자격증명을 전달합니다.
- 최종적으로 Pod의 AWS SDK는 AWS S3의 리스트를 가져올 수 있게 된다.
JWT란?
JWT는 JSON 웹 토큰(JSON Web Token)의 약자로 당사자 간에 정보를 JSON 객체로 안전하게 전송하기 위한 간결하고 독립적인 방법을 정의하는 표준(RFC 7519)이다. 디지털 서명되어 있으므로 확인하고 신뢰할 수 있다.
JWT는 비밀(HMAC 알고리즘 포함) 또는 RSA 또는 ECDSA를 사용하는 공개/개인 키 쌍을 사용하여 서명한다.
💡 실무자 추가 팁
- eksctl로 YAML 추출 가능:
--dry-run옵션을 활용하면 실제 리소스를 생성하지 않고 구성 내용을 YAML로 확인 가능 - ServiceAccount에 IAM Role 수동 할당 시 주의: eksctl 없이 수동 구성할 경우 ServiceAccount의
metadata.annotations에 정확한role-arn지정 필요 - 정책 최소화 원칙 적용:
AmazonS3FullAccess같은 광범위 정책 대신 최소 권한 원칙(Least Privilege)을 적용한 사용자 정의 정책 권장 - 다중 클러스터 OIDC 충돌 주의: 동일 계정 내 여러 클러스터 사용 시 OIDC Provider URL이 중복되지 않도록 관리 필요
- IRSA + External Secrets 연동: AWS Secrets Manager와 연계 시 IRSA는
secrets-manager:GetSecretValue권한만으로도 충분히 보안 유지 가능 - eksctl 외 helm chart 연동 고려: helm으로 배포하는 chart에 IRSA 적용 시
serviceAccount.annotations에 IAM Role을 명시해야 함
마무리: EKS에서의 권한 관리는 이제 IRSA가 표준
IRSA는 단순한 "권한 위임" 이상의 의미를 가진다.
기존의 aws configure, AccessKey 기반 인증 방식은 컨테이너 보안 측면에서 취약점이 많았고, 배포 및 운영 자동화에도 제약이 있었다.
반면 IRSA는 다음과 같은 이점을 제공한다.
- IAM Key 노출 위험 제거
- RBAC + IAM 연계로 세밀한 권한 관리
- GitOps/CI/CD 파이프라인과 자연스러운 통합
- 임시 자격 증명 기반으로 보안성 향상
즉, EKS 환경에서 AWS 리소스를 사용하는 Pod를 운영한다면, IRSA는 선택이 아닌 필수에 가깝다.
모든 구성은 eksctl, kubectl, aws sts, OIDC를 통해 구성 가능하며, 실제 운영환경에 적합한 보안/권한 설계의 기본이 된다.
앞으로 Kubernetes + AWS 환경에서 IAM 권한 분리를 고려하고 있다면 IRSA를 반드시 도입해보자.
보안, 관리, 자동화 세 마리 토끼를 모두 잡을 수 있다.
Reference
https://aws.amazon.com/ko/blogs/containers/diving-into-iam-roles-for-service-accounts/
https://kim-dragon.tistory.com/279
https://channel.io/ko/blog/tech-aws-cross-accounts-irsa
https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html
https://clarkshim.tistory.com/418
https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_credentials_temp.html
'AWS' 카테고리의 다른 글
| AWS Ingress Annotations 정리 (0) | 2024.11.07 |
|---|---|
| AWS Assume Role이란? (0) | 2024.11.04 |
| AWS VPC란? (0) | 2023.04.07 |
| AWS Cloudfront란? / Canary 및 Blue-Green 배포 (0) | 2023.04.03 |
| AWS Secrets Manager란?(OAuth, SSO) (0) | 2023.04.01 |