[Infra] EKS 환경에서 Springboot에 IRSA 적용해보기

안녕하세요! zerone-code입니다.

 

대부분의 개발자들이 사용하고 있는 Springboot, 그리고 요즘 MSA환경으로 전환 혹은 개발한다고 하면 빠질 수 없는 EKS에 관련된 이야기를 해보려고 합니다.

 

바로 EKS 환경에서 Springboot Application에 IRSA(IAM Role for Service Account)를 적용하는 방법에 대해 정리해 보도록 하겠습니다.

 

궁금한 부분은 댓글로 남겨주시면 아는 만큼 성심성의껏 답변해 드리도록 하겠습니다.

잘 읽으셨다면 많은 공감과 구독 부탁드립니다!

---

AWS 환경에서 동작하는 Springboot Application에서는 Secrets Value들을 Parameter Store 혹은 Secrets Manager를 사용해서 많이 사용하고 합니다. EC2나 ECS 등의 환경에서 Parameter Store 혹은 Secrets Manager를 사용하기 위해서는 IAM Role에 권한을 부여해서 사용하고는 합니다.

 

이 과정은 이전에 썼던 블로그 내용을 한번 참조해보시면 좋을 것 같습니다.

[Infra] Springboot에 AWS Secrets Manager 적용해보기(2)

EKS도 마찬가지 입니다. 하지만 EKS에서는 Node 단위의 IAM Role 이 아닌 Pod 단위의 IAM Role을 사용해서 각 서비스 별로 접근할 수 있는 Secrets Value들이 달라야 합니다.

 

A라는 서비스가 돌고 있는 Pod와 B라는 서비스가 돌고 있는 Pod가 있다고 가정해보겠습니다. 서로 다른 서비스이지만 같은 EKS Cluster안에 돈다고 가정하면, 같은 Node에 뜰 수도 있게 되고 Node 단위의 IAM Role을 사용하게 된다면 A 서비스와 B 서비스는 같은 IAM Role을 사용하기 때문에 각 서비스의 Secrets Value들을 볼 수 있게 됩니다. 

 

이런 상황에서는 Security best practices in IAM에 어긋나게 됩니다. 따라서 우리는!! Best Practice를 지향하는 개발자들이기 때문에 가만히 있을 수 없겠죠? 따라서 Pod 별로 IAM Role을 사용해야 합니다. 

 

Pod 별로 IAM Role을 사용하기 위해서는? 바로 Servcie Account를 통해 적용해 줄 수 있습니다. 이를 사용할 수 있게 만든게 바로 IRSA(IAM Role for Service Account)입니다.

 

이를 적용하기 위해 Application 수준에서의 설정과 Infra(EKS) 수준에서의 설정으로 나눠서 설명해 보도록 하겠습니다.

 

1. Application 수준에서의 설정

기존에 EC2나 ECS에서 설정한대로 Springboot Application을 Docker Image 형태로 빌드한 후, Pod로 배포하게 된다면 다음과 같은 Error를 맞이하게 됩니다.

바로 Application에서 Secrets Manager를 사용해서 application.yml에 지정된 Secrets Value를 가져와야 하는데 Secrets Manager에 접근을 할 수 없다는 뜻입니다.

 

이 문제는 바로 Application에서 사용하고 있는 Library의 문제입니다.

Spring Cloud AWS 공식 문서에 따르면 SpringBoot Auto Configuration Library를 Dependency로 지정해 주게 되면 아래와 같은 순서로 DefaultAWSCredentialsProviderChain을 타게 되는데, 아래 세 가지 경우에 해당하는 값이 아무것도 없기 때문에 문제가 발생하게 됩니다.

그럼 도대체 어떻게 적용하는거지? 라는 생각이 드는 와중 공식문서에서 조금 위로 가보도록 하겠습니다. 위에 정답이 있었네요. 친절하게도 EKS환경에서 IRSA설정을 사용하기 위해서는 아래와 같은 추가 설정을 해야지만 ServiceAccount로 생성된 WebIdentity Token을 사용할 수 있게 됩니다. 이 부분은 Springboot 2.3.1부터 추가된 부분입니다.

그리고 이를 적용하게 되면 아래와 같이 정상적으로 지정한 Spring profile에 맞는 Secrets Manager 값들이 로딩되는 것을 확인해 볼 수 있습니다.

2. Infra(EKS) 수준에서의 설정

이번엔 EKS 수준에서 지정해줘야 할 부분에 대해 알아보도록 하겠습니다.

먼저 IRSA를 사용하기 위해서 IAM Role의 Trusted entities부분에 사용할 EKS와 신뢰 관계를 아래 사진처럼 맺어주도록 합니다.

그다음은 실제로 사용되는 ServiceAccount를 만들어야겠죠? 아래의 yaml의 형태로 생성해 주도록 합니다.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: <ServiceAccount Name>
  namespace: <NameSpace>
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::<aws-account-id>:role/<iam-role-name>
---
apiVersion: v1
kind: Pod
metadata:
  name: service-pod
  namespace: <NameSpace>
spec:
  serviceAccount: <ServiceAccount Name>
  containers:
    name: <service name>
    image: <service image>
    imagePullPolicy: Always
    ...

위와 같이 ServiceAccount를 생성하고, 해당 ServiceAccount를 Pod에 지정하게 되면 EKS 내부에 설치된 pod-identity-webhook에 의해 배포되는 Pod의 manifest가 변형(mutation)되어 ServiceAccount에서 사용되는 Token이 mount 됩니다. 

마무리

지금까지 해본 내용을 정리해보도록 하겠습니다.

1. Application 수준에서는 SpringBoot Auto Configuration 외에 aws-java-sdk-sts library를 추가로 지정해준다.
   1-1. Docker Image를 새로 빌드해준다.

2. Infra(EKS)수준에서는 IAM Role의 Trusted entities를 EKS와 맺어준다.

    2-1. ServicAccount에 Annotation을 사용해서 IAM Role을 지정해서 생성해준다.
    2-2. 사용할 Deployment에 SeviceAccount를 지정해서 생성해준다.

위와 같은 과정으로 EKS 환경에서 SpringBoot Application을 사용하는 서비스에서 IRSA를 사용하는 과정을 살펴봤습니다.

글이 길어지는 관계로 생성하려는 Pod가 pod-identity-webhook에 의해 변형(mutation)되는 부분에 대해서는 자세히 언급하지는 않았지만, 아래 참고 자료를 같이 읽어보시면 좋을거 같습니다.

 

글을 읽어 보시는 것 뿐만 아니라 직접 해보시면 더 빠른 이해가 되실 것이라고 생각됩니다.

 

궁금한 부분은 댓글로 남겨주시면 아는 만큼 성심성의껏 답변해드리도록 하겠습니다.

잘 읽으셨다면 많은 공감과 구독 부탁드립니다!

Reference

https://docs.awspring.io/spring-cloud-aws/docs/2.4.0/reference/html/index.html#sdk-credentials-configuration

Spring Cloud AWS

https://github.com/aws/amazon-eks-pod-identity-webhook

GitHub - aws/amazon-eks-pod-identity-webhook: Amazon EKS Pod Identity Webhook

https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/

Introducing fine-grained IAM roles for service accounts | Amazon Web Services