AWS EKS의 IRSA와 RBAC 이해하기 - Spring Boot MSA 환경의 로깅 시스템 구축 사례
이번 포스팅에서는 AWS EKS 환경에 배포된 SpringBoot 애플리케이션 로깅 구축시 필요한 IRSA와 RBAC를 사례를 통해 정리합니다.
로깅 구성시 중요하게 생각한건 확장성과 비용이었습니다. 현재 구성한 기술스택도 정답이 아니지만 중요하게 고려했던부분은 로그 저장소였습니다.
로깅 구축에 사용된 기술 스택은 다음과 같습니다.
- aws cloudwatch
- fluentbit
aws eks 환경에서 logging을 구축하기 위해서 해야할일을 크게 두가지로 나눴습니다.
- aws eks의 배포된 특정 app에 대한 로깅 수집
- 수집한 로깅을 적재하는것
ClusterRole
로깅을 수집하기 위해서는 로깅 컬렉터가 필요합니다. fluentbit은 그 역할을 합니다.
fluentbit은 DaemonSet으로 배포합니다. DaemonSet으로 구성하는 이유는 각 노드마다 하나의 FluentBit Pod이 실행되어 해당 노드의 모든 Pod 로그를 수집할 수 있기 때문입니다. 노드 자동 스케일링 시에도 자동으로 fluentbit Pod 배포됩니다.
fluentbit이 pod 로그에 접근하기 위해서는 clusterRole이 필요합니다.
IRSA
fluentbit이 로그를 cloudwatch로 적재하기 위해서는 cloudwatch에 대한 액션을 기술한 IAM Policy와 IAM ROLE 필요합니다.
fluentbit은 DaemonSet으로 구성할때는 k8s에서 service account을 통해 IAM ROLE을 연결한 service account을 설정해줍니다.이걸 IRSA라고 합니다. Service Account는 Pod가 외부 서비스나 Kubernetes API를 사용할 때 필요한 "디지털 신분증" 역할을 한다고 볼 수 있습니다.
AWS IAM을 ServiceAccount에 할당해야하는데, AWS IAM과 AWS EKS간 신뢰관계 구성이 필요합니다. 이걸 OIDC Provider를 이용해서 ServiceAccount를 구성합니다. 그리고 ClusterRoleBinding시 ServiceAccount와 ClusterRole을 연결합니다.
ClusterRoleBinding에서 ClusterRole과 ServiceAccount를 같이 설정하는 이유는 "누가"(ServiceAccount) "어떤 권한"(ClusterRole)을 가질 수 있는지 연결하기 위해서입니다.
여기서는 하나의 ServiceAccount에 아래의 두 가지 역할을 가지고 있게 됩니다.
ClusterRole을 통해 → Pod 로그 읽기 권한 획득
IAM Role을 통해 → CloudWatch 쓰기 권한 획득
이렇게 두 가지 다른 시스템(Kubernetes RBAC, AWS IAM)의 권한을 모두 가지게 됩니다.
이제 이 ServiceAccount을 fluentbit daemonset에 설정하고, fluentbit configmap을 설정해주고 배포하게 되면
fluentbit의 config대로 aws cloudwatch로 로그 그룹으로 로그가 적재되는것을 확인할수 있습니다.
OIDC (OpenID Connect)
OIDC(OpenID Connect)는 Kubernetes가 외부 클라우드 서비스나 솔루션과 인증을 수행할 때 사용하는 표준 인증 프로토콜입니다.
OIDC Provider가 EKS 클러스터와 IAM 사이의 신뢰관계를 형성하는 방식은 다음과 같습니다
- EKS 클러스터는 자체 OIDC 발급자(issuer) URL을 가짐
- OIDC Provider는 이 URL을 통해 JWT 토큰의 유효성을 검증
- Pod는 ServiceAccount의 토큰을 사용하여 AWS STS로부터 임시 자격 증명을 받음