Terraform으로 EKS 배포하기 7. EKS 권한 주기 feat. IRSA

이대로 진행하기엔 권한에서 문제가 생길 것 같아서 한번 정리하고 들어간다.

 

EKS는 AWS에서 관리되는 "쿠버네티스" 서비스이다.

 

외부 인터넷 망과 쿠버네티스 서비스를 연결해주기만 하면(여기서도 권한이 필요하긴하지만)

 

쿠버네티스 내부의 노드/파드들에게 특별한 권한이 주어질 필요는 없다. 

 

문제는, 쿠버네티스 내부에서 AWS 리소스에 대한 접근 권한을 줘야하는 경우다.

 

AWS 리소스들에 접근하기 위해서는 파드들에게 권한을 부여해줘야 한다. 

 

쿠버네티스 파드들에게 IAM Role을 부여하는 것을 IRSA(IAM Roles for Service Accounts)이라 한다.

 

파드들에게 권한을 주기 위한 다양한 방법이 있는데 이 중에서 IRSA가 모범사례로 제시되어있다.

https://aws.github.io/aws-eks-best-practices/ko/security/docs/iam/#iam-irsa

 

IRSA 외의 다른 역할을 부여하는 방법은 악분님 블로그에 잘 정리되어 있다(도움을 많이 받고 있습니다)

https://malwareanalysis.tistory.com/723

 

테라폼으로 IRSA를 부여하기에 앞서 필요한 권한과 리소스에 대해 알아보자.

---

IAM(Identity and Access Management)

AWS 리소스를 사용할 때 가장 먼저 알아야할 권한 관리자이다.

 

이전에 정리해 둔 글이 있으니 참고 : 2023.12.10 - [개발/AWS] - AWS IAM 파헤치기 - 역할과 정책, 신뢰관계

 

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/introduction.html

---

Kubernetes Service Account

서비스 어카운트는 파드에서 실행되는 프로세스에 대한 식별자를 제공한다.

 

파드 내부의 프로세스는, 자신에게 부여된 서비스 어카운트의 식별자를 사용하여 클러스터의 API 서버에 인증할 수 있다.

 

아래는 다음장에서 다룰 로드밸런서 컨트롤러의 Service Account 이다.

 

순서는 왜인지 잘 모르겠지만, irsa module을 먼저 만들어야 한다.

(아마도 IAM Role을 만드는 부분이 module에 있어서 일듯)

resource "kubernetes_service_account" "alb_controller" {
  metadata {
    name      = "aws-load-balancer-controller"
    namespace = "kube-system"

    annotations = {
      "eks.amazonaws.com/role-arn" = module.alb_controller_irsa.iam_role_arn
    }
  }
}

참고자료 

https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/

https://kubernetes.io/ko/docs/reference/access-authn-authz/service-accounts-admin/

---

IRSA (IAM Roles for Service Accounts)

IRSA(IAM Roles for Service Accounts)는 쿠버네티스 Service Account에 IAM role을 설정해 Pod가 AWS 리소스에 접근할 수 있는 권한을 부여한다.

 

아래는 다음장에 사용될 alb 컨트롤러의 irsa인데 module에서 role_name을 지정하고

 

attach_load_balancer_controller_policy를 true로 지정하면 alb 컨트롤러를 만드는데 필요한 role을 생성해준다.

module "alb_controller_irsa" {
  source = "terraform-aws-modules/iam/aws//modules/iam-role-for-service-accounts-eks"

  role_name = "alb_controller-role"

  attach_load_balancer_controller_policy = true

  oidc_providers = {
    one = {
      provider_arn               = local.oidc_provider_arn
      namespace_service_accounts = ["kube-system:aws-load-balancer-controller"]
    }
  }
}

IRSA를 생성하기 위해서는 oidc provider가 필요하다.

 

oidc가 필요한 이유는 파드는 AWS 리소스가 아니기 때문에, 내가 사용할 리소스가 맞다는 인증을 해야한다.

 

나중에 나오겠지만 OIDC를 이용해서 JWT 토큰을 생성하고

 

AssumeRoleWithWebIdentity Role을 생성해 다른 AWS 리소스에 접근하기 위한 일시적인 Credential을 부여받는다.

 

one, two .. 파라미터로 여러 oidc provider를 추가할 수 있다.

---

OIDC(OpenID Connect)

AWS EKS 클러스터와 AWS IAM을 연결하여 Kubernetes 서비스 계정이 AWS 리소스에 안전하게 접근할 수 있도록 하는 인증 메커니즘.

 

EKS 클러스터 생성 시 자동으로 생성된다. 내용을 자세히 설명하면 너무 어려워지니 이 정도만 알고 넘어가자.

 

IAM 자격 증명 공급자에 자동으로 생김

 

---

IRSA의 동작 방식

동작 방식도 조금 어렵다.

 

요약하자면

 

1. pod 인증 과정을 위해서 OIDC Provider로 JWT 토큰을 생성함

2. JWT 토큰을 이용해 AssumeRoleWithWebIentity를 생성하고, 임시 Credential을 발급 받기 위한 인증키로 사용  

3. 발급받은 credential로 pod를 인증하고, credential 키로 참조할 IAM Role 가져와 service account의 annotation에 삽입

 

내부적으로는 굉장히 복잡한 로직이 들어가고 검증과정도 어렵지만 사용자에게 보여지는건 이정도다.

(사실 JWT 토큰을 부여받는 부분도 보이지 않는다)

 

어디까지 알아야할까 가장 고민되는 부분이었는데, 잘 정리된 글이 있어서 첨부한다.

https://malwareanalysis.tistory.com/724

---

마치며

옛날에는 더 복잡한 방식의 인증을 했던 것 같은데 IRSA가 나오면서 EKS에서는 더 편한 인증방식을 사용하게 된 것 같다.

 

클라우드 환경에서 보안과 인증도 큰 이슈인 걸로 아는데, 이런식으로나마 핥고 넘어가게 됐다.

 

보안과 인증은 깊게보면 너무 어려워지는데, 보다보니 OIDC, AssumeRole 등 더 알아야할 키워드만 자꾸 생기는 같다.

 

아직까지는 사용법에 집중하려고 한다.

 

다음은 EKS 클러스터와 외부 인터넷을 연결하는 ALB Controller에 대해 정리할 예정이다.