[EKS] IRSA를 활용하여 pod에 IAM 할당하기 #1

AWS에서 쿠버네티스를 운영하다보면 파드가 S3나 DynamoDB와 같은 AWS 리소스를 이용해야 하는 경우가 종종 생깁니다. 쿠버네티스를 사용하지 않는 환경이라면 필요한 IAM 정책을 정의하고 EC2 인스터스에서 이 정책을 사용할 수 있게끔 할당해주면 간단히 해결되지만  IAM 정책은 인스턴스 단위로 사용할 수 밖에 없어 보안적인 측면에서 지켜야 하는 Principle of Least Privilege를 어길 수 있습니다.

예를 들어 flask 파드와 로그 수집을 위한 fluentbit 파드가 한 워커 노드에 올라가는 경우 kinesis를 통해 데이터 파이프라인을 구축하였다면 fluentbit는 kinesis로 데이터 전송을 해야 하므로 이와 관련된 IAM 권한이 필요할 겁니다. 만약 이 권한을 워커 노드에 할당한다면 flask와 fluentbit 파드가 모두 kinesis를 사용할 수 있는 권한을 부여받게 되는 상황이라 여러 개의 파드가 노드에 올라갈 수록 불필요한 권한이 계속 생성될 수 있습니다.

이를 해결하기 위해선 kube2iam이나 kiam와 같은 IAM controller를 활용하는 방법이 있지만 AWS의 feature인 IRSA(IAM Role for Service Account)를 사용 중이라 IRSA가 어떤 식으로 동작하는지에 대해 정리해보려고 합니다. IRSA는 간단히 요약하면 OpenID Connector(OIDC) Identity Provider와 STS를 활용하여 쿠버네티스의 Service Account에 IAM Role을 할당(?)할 수 있게 하는 방식입니다.

OIDC URL은 EKS 클러스터를 생성하면 자동으로 생성되고, 쿠버네티스 관리자는 이 OIDC를 통해 Identity Provider와 파드에서 필요한 IAM Role을 만들어주고 Service Account에 announce를 해주면 컨트롤 플레인에서 이를 참조하여 OIDC 인증을 거친 뒤에 JWT를 발급하여 이를 통해 파드의 env에 AWS_ROLE_ARN, AWS_WEB_IDENTITY_TOKEN_FILE 설정을 하여 파드가 임시 IAM 권한을 획득할 수 있게 해줍니다.

그림으로 표현하면 위와 같을 거고, 제가 참고했던 글에서는 구체적인 요청 flow를 알기 어려워 이번엔 간략하게 정리 위주의 포스팅을 진행했습니다. 다음 포스트에서는 하나의 워커 노드에 두 개의 파드를 띄운 후 특정 파드에 IAM 권한을 주는 형태의 실습을 해보려고 합니다.