쿠버네티스[EKS] IRSA(IAM for ServiceAccount)

AWS 자원 접근 시 EC2에 IAM Role을 부여하거나 IAM Account를 생성하여 accesskey, secretkey를 발급받아 aws configure에 등록하는 방법 등이 있다.뭐 상황에 따라 적절할 수는 있지만 최소한 쿠버네티스, EKS를 사용하는 환경에서는 워커노드에 권한을 주는 것은 Least Privilege Principle에 어긋날 것이다.

 

간단한 예를 들자면 Pod A가 DynamoDB 접근 권한이 필요해 워커노드에 권한을 준다면 해당 워커노드에서 실행 중인 Pod B, Poc C에게도 동일한 권한이 주어질 것이다. 

또한 Account를 생성하여 키를 활용하는 방법은 키가 노출될 시 위험하기에 키 관리 또한 어려워질 수 있다.

따라서 EKS 공식 기능인 IRSA(IAM roles for service accounts)를 사용하여 Pod 별 최소 권한을 유지하는 방법에 대해 간략하게 설명하려고 한다. 

Pod 마다 별도 Role 부여가 가능하고 STS Token을 활용하여 키 관리가 따로 필요하지 않으며 1~12 시간 길이의 STS Token을 사용하여 키 노출 시에도 노출 범위/기간이 최소화된다.

간단히 설명하자면 IAM Role을 쿠버네티스 오브젝트인 Service Account와 연관시키고 Pod들이 해당 Service Account를 가져다 쓰도록 설정한다고 보면 될 것 같다. 

 

용어에 대해 정리해보자면 다음과 같다.

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가 해당 기능을 수행해준다.

OIDC는 인증 서버에서 수행한 인증을 기반으로 앱이 최종 사용자의 신원을 확인할 수 있도록 하는 인증 프로토콜인 OpenID Connect의 약자이다.
OpenID Connect는 OAuth 2.0 프로토콜 위에 구축되어 인증 서버가 리소스 소유자 또는 최종 사용자의 승인을 받아 타사 애플리케이션에 대한 액세스 토큰을 발급할 수 있다. 애플리케이션은 액세스 토큰을 사용하여 최종 사용자를 대신하여 API에 인증할 수 있으며, OIDC는 OAuth 2.0을 확장하여 ID 토큰을 도입하여 인증을 추가한다.

EKS Cluster 생성 시 OIDC가 자동 생성된다. 이를 조회하는 명령어는 다음과 같으며 조회되지 않을 시 OIDC 생성 명령어도 기록해두겠다.

 

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  --region 
https://oidc.eks..amazonaws.com/id/554xxxxxxxxxxxxxxxxxxxxxxxxxxx

 

 

AWS STS(Security Token Service)란?

 

AWS 리소스에 접근할 수 있는 권한에 대해 임시자격 증명을 가져오도록 하는 서비스이다.

아래의 AWS Diving into IAM Roles for Service Accounts 주제로 IRSA의 Workflow이다. (S3 접근 관련)

https://aws.amazon.com/ko/blogs/containers/diving-into-iam-roles-for-service-accounts/

순서를 정리하면 다음과 같다. 

https://aws.amazon.com/ko/blogs/containers/diving-into-iam-roles-for-service-accounts/

 

1. JWT와 IAM Role 의 ARN정보를 AWS STS에게 전달 한다.
2. STS는 AWS IAM에게 임시 자격증명을 줄 수 있는지 확인을 요청한다.
3. IAM은 IAM OIDC Provider와 통신하고, Pod에 할당된 ServiceAccount에 IAM Role 정보가 Annotate되어 있는 지 확인한 후에 IAM에게 확인 되었다는 응답을 주게 된다.
4. IAM은 STS에게 권한을 줘도 된다고 응답을 주게 된다.
5. AWS STS는 Pod의 AWS SDK에게 임시 자격증명을 전달합니다.
6. 최종적으로 Pod의 AWS SDK는 AWS S3의 리스트를 가져올 수 있게 된다.

적용은 생각보다 간단하게 진행된다.

1. 일단 생성된 Identity provider에 Audience: sts.amazonaws.com 가 적용되어있는지 확인

1. Provider type: OpenID Connect
2. Provider URL: EKS 클러스터에서 확인한 OpenID Connect provider URL
3. Audience: sts.amazonaws.com

2. IAM Role 생성 및 TrustRelationship 설정 

aud, sub 등은 OIDC id의 토큰 필드 들인데 sub (Subject Identifier): 사용자의 고유 식별자, aud (Audience): 토큰의 수신자 또는 사용 대상을 의미한다.

3. ServiceAccount에 role 적용

apiVersion: v1
kind: ServiceAccount
metadata:  name: sample-irsa-sa
  namespace: innog-dev
  annotations:    eks.amazonaws.com/role-arn: role arn

 

4. Pod에 ServiceAccount 적용

apiVersion: apps/v1
kind: Deployment
metadata:  
    name: innogdata-dev-producer-deploy
    namespace: innog-dev
spec:  
    selector:   
      matchLabels:      
    	app: innogdata-dev-producer
    replicas: 1
    template:   
  	metadata:      
        labels:        
            app: innogdata-dev-producer
    spec:      
    	serviceAccountName: innogdata-dev-producer-sa

 

이렇게 아주 간단히 적용하는 예시를 들었다. 

이를 활용하면 EKS 뿐만이 아닌 다양한 곳에서 적용이 가능하다. 예를 들자면 Github Action, Gitlab Runner 등에서도 Accesskey, SecretKey 인증이 아닌 OIDC 인증을 활용해 CICD를 구성할 수 있게 된다.