개요

EKS Pod Identity로 alb controller 생성 중 에러가 발생하였습니다.

에러 내용은 다음과 같습니다.

• Error creating: pods "aws-load-balancer-controller-5bdc6f6fd4-" is forbidden: error looking up service account kube-system/aws-load-balancer-controller: serviceaccount "aws-load-balancer-controller" not found

eksctl로 생성하는 만큼 해당 리소스가 모두 생성될 것이라 생각했고 EKS에서 매핑된 것을 확인할 수 있는데 무엇이 문제인지를 찾기 시작했습니다.

Process

리소스를 순차적으로 확인하였습니다.

1. Pod Identity 확인

Pod Identity는 정상적으로 동작하고 있었습니다.

kube-system   eks-pod-identity-agent-kxzst 1/1  Running  0  23m

2. cluster config 확인

cluster eksctl config 파일을 확인했을 때 정상적으로 입력되어있고 이미지에서도 정상적으로 매핑된 것을 확인할 수 있었습니다.

iam:
  podIdentityAssociations:
  - namespace: "<karpenter_namespace>"
    serviceAccountName: karpenter
    roleName: "<karpenter_iam_role_name>"
    permissionPolicyARNs:
    - arn:aws:iam::<account_id>:policy/<karpenter_controller_policy_name>
  - namespace: kube-system
    serviceAccountName: aws-load-balancer-controller
    roleName: "<alb_controller_iam_role_name>"
    permissionPolicyARNs:
      - arn:aws:iam::<account_id>:policy/<aws_load_balancer_controller_iam_policy_name>

3. Service Account 확인

$ k get serviceaccount -n kube-system | grep aws

aws-cloud-provider                            0         97m
aws-node                                      0         91m

Service Account가 생성되지 않은 것을 확인할 수 있습니다.

Service Account 생성

podIdentityAssociations 은 EKS 내 Service Account와 IAM을 연결해주는 역할을 할 뿐 Service Account를 생성하지 않습니다.

따라서 helm 옵션 중 --set serviceAccount.create=true 을 설정하여 재생성했습니다.

# ALB Controller 설치
helm install <YOUR_RELEASE_NAME> eks/aws-load-balancer-controller -n kube-system \
  --set clusterName=<YOUR_EKS_CLUSTER_NAME> \

  --set serviceAccount.create=true \

  --set serviceAccount.name=aws-load-balancer-controller \
  --set vpcId=<YOUR_VPC_ID>

Comparison of Amazon EKS Pod Identity with IRSA

• https://aws.amazon.com/ko/blogs/containers/amazon-eks-pod-identity-a-new-way-for-applications-on-eks-to-obtain-iam-credentials/

해당 내용을 요약하자면 다음과 같습니다

IRSA(IAM Roles for Service Accounts)란?

IRSA는 Kubernetes 서비스 어카운트(Service Account)에 직접 IAM 역할을 연결하여 파드 단위로 세분화된 AWS 권한을 부여할 수 있게 해줍니다.

핵심 원리는 다음과 같습니다:

1. EKS 클러스터는 OIDC(OpenID Connect) 자격 증명 공급자로 AWS IAM에 등록됩니다.
2. 파드는 Kubernetes 서비스 어카운트 토큰을 발급받습니다
3. 토큰을 사용하여 AWS STS(Security Token Service)의 AssumeRoleWithWebIdentity API를 호출, IAM 역할에 대한 임시 자격 증명을 얻습니다.

IRSA(IAM Roles for Service Accounts) 문제점

1. IAM 역할 생성
   1. 각 역할마다 신뢰 정책(Trust Policy) 설정이 필요하며 이 신뢰 정책에는 EKS 클러스터의 OIDC 공급자 ARN과 해당 역할을 사용할 Kubernetes 서비스 어카운트의 정확한 정보(네임스페이스, 서비스 어카운트 이름)가 조건으로 명시되어야 했습니다. 이러한 결과로 인해 재사용이 어렵고 신뢰 관계가 복잡해질 수 있다는 문제가 있었습니다.
2. Kubernetes 서비스 어카운트 설정
   1. 서비스 어카운트에 특정 어노테이션(eks.amazonaws.com/role-arn)을 통해 사용할 IAM 역할의 ARN을 지정해야 했습니다.
3. 관리의 분산
   1. 수십, 수백 개의 파드가 각기 다른 역할을 사용할 경우, IAM 역할과 서비스 어카운트 간의 연결 관계를 파악하고 관리하는 것이 분산되어 있어 복잡하고 번거로웠습니다.

EKS Pod Identity란?

이러한 문제를 해결하기 위해 Pod Identity가 추가되었습니다. 파드에 IAM 역할을 할당하는 과정을 훨씬 단순화하고 중앙에서 관리할 수 있도록 제공하는 새로운 기능입니다.

이는 기존 IRSA의 강력한 보안 원리를 기반으로 하되, 사용 편의성과 관리 효율성을 크게 높인 IRSA의 진화된 형태 또는 추상화 계층을 제공합니다

IRSA와 'EKS Pod Identity'의 가장 큰 차이점을 운영 관점에서 요약한다면?

• IRSA
  • 사용자가 IAM 역할의 신뢰 정책과 Kubernetes 서비스 어카운트의 어노테이션을 직접 정확하게 구성하고 연결해야 합니다.
  • 관리가 IAM과 Kubernetes 양쪽에 분산됩니다.
• EKS Pod Identity
  • IAM 역할과 서비스 어카운트의 연결을 EKS 서비스 자체에서 (API/콘솔을 통해) 중앙 관리합니다.
  • 사용자는 복잡한 신뢰 정책을 직접 다룰 필요가 크게 줄어들고, 설정이 단순화되며, 전체적인 관계 파악이 용이해집니다.

따라서 Pod Identity는 재사용성 향상, 명확한 관계 파악이 이루어질 수 있으며 이를 통해 각 파드는 자신에게 필요한 최소한의 권한만 가진 IAM 역할을 사용할 수 있게 됩니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}

• https://medium.com/@prasad.midde3/why-aws-eks-pod-identity-is-a-better-fit-than-irsa-for-your-kubernetes-needs-beba3b8cc1ed