EKS 권한 관리, 아직도 복잡하게 하세요? 🤔 Pod Identity로 갈아타야 하는 이유

안녕하세요! 오늘은 AWS EKS에서 컨테이너(Pod) 권한을 관리하는 방법에 대해 깊이 파고들어 보려고 합니다. 애플리케이션이 S3나 DynamoDB 같은 AWS 서비스에 접근해야 할 때, 어떻게 안전하고 효율적으로 권한을 부여하고 계신가요?

아마 많은 분들이 IRSA (IAM Roles for Service Accounts)를 사용하고 계실 텐데요. 그런데 IRSA를 설정하면서 복잡한 IAM 신뢰 정책 때문에 골치 아팠던 경험, 한 번쯤은 있으시죠? 🤯

최근 AWS가 이 문제를 해결하기 위해 EKS Pod Identity라는 새로운 기능을 선보였습니다. 오늘은 기존의 강자 IRSA와 새로운 도전자 EKS Pod Identity를 속 시원하게 비교하고, 어떤 상황에 무엇을 선택해야 할지 확실하게 정리해 드리겠습니다!

---

🧐 IRSA: 익숙하지만 까다로운 친구

IRSA는 쿠버네티스의 서비스 어카운트(Service Account)와 AWS의 IAM 역할을 직접 연결하는 방식입니다. EKS 클러스터가 가진 OIDC(OpenID Connect) 정보를 활용해 IAM 역할이 특정 서비스 어카운트를 신뢰하도록 설정하는 거죠.

✨ IRSA는 어떻게 작동할까요?

1. OIDC 자격 증명 공급자 설정: EKS 클러스터를 만들 때 고유한 OIDC 공급자(Provider) URL이 생성됩니다. AWS IAM이 우리 클러스터를 식별할 수 있게 해주는 신분증 같은 거예요. 🆔
2. IAM 역할 생성 및 신뢰 정책 설정: 파드에게 부여할 권한을 가진 IAM 역할을 만듭니다. 여기서 핵심은 신뢰 정책(Trust Policy)인데요, "이 역할은 EKS 클러스터의 OIDC 공급자를 믿고, my-app 네임스페이스에 있는 my-service-account라는 서비스 어카운트에게만 임시 자격 증명을 발급해 줄 거야!"라고 아주 구체적으로 명시해야 합니다.
3. 서비스 어카운트에 어노테이션 추가: 애플리케이션이 사용할 쿠버네티스 서비스 어카운트에 어떤 IAM 역할을 사용할지 어노테이션(eks.amazonaws.com/role-arn)으로 콕 집어 알려줍니다.
4. 자격 증명 획득: 파드가 실행되면 내부의 AWS SDK가 이 정보를 바탕으로 AWS에 임시 자격 증명을 요청하고, 발급받은 키로 AWS API를 호출하게 됩니다. 🚀

🔧 IRSA 설정 예시

가장 골치 아픈 부분인 IAM 역할의 신뢰 정책부터 보시죠. 정말 길고 복잡합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.ap-northeast-2.amazonaws.com/id/EXAMPLED539D4633E53BF441"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "oidc.eks.ap-northeast-2.amazonaws.com/id/EXAMPLED539D4633E53BF441:sub": "system:serviceaccount:my-namespace:my-app-sa",
                    "oidc.eks.ap-northeast-2.amazonaws.com/id/EXAMPLED539D4633E53BF441:aud": "sts.amazonaws.com"
                }
            }
        }
    ]
}

이 긴 정책에서 OIDC 주소, 네임스페이스, 서비스 어카운트 이름 중 하나라도 틀리면 권한 오류가 발생합니다. 😭

그리고 쿠버네티스 서비스 어카운트는 이렇게 설정합니다.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: my-namespace
  annotations:
    # 여기에 IAM Role의 ARN을 직접 넣어줘야 합니다!
    eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-app-s3-access-role

👍 IRSA의 장점

• 에이전트 불필요: 노드에 별도의 에이전트를 설치할 필요가 없어 구성이 깔끔합니다.
• 표준 기술 기반: OIDC라는 개방형 표준을 사용해 원리가 명확합니다.
• 명시적인 설정: 모든 권한 연결 정보가 쿠버네티스 매니페스트에 코드로 관리됩니다 (GitOps에 유리).

👎 IRSA의 단점

• 너무 복잡한 신뢰 정책: IAM 신뢰 정책이 길고 복잡해서 실수하기 쉽고 관리하기 어렵습니다.
• 강한 결합(Tight Coupling): IAM 역할의 ARN이 서비스 어카운트 YAML에 하드코딩됩니다. 역할을 바꾸려면 쿠버네티스 리소스를 다시 배포해야 하죠.
• 관리 포인트 분산: 역할이 늘어날수록 관리해야 할 IAM 신뢰 정책도 비례해서 늘어나 관리가 번거로워집니다.

---

😎 EKS Pod Identity: 단순함이 무기인 새로운 해결사

EKS Pod Identity는 IRSA의 복잡함을 해결하기 위해 등장한 구원투수입니다. 핵심은 권한 설정의 중심을 쿠버네티스에서 AWS로 옮겼다는 점입니다.

✨ EKS Pod Identity는 어떻게 작동할까요?

1. EKS Pod Identity Agent 설치: 클러스터에 EKS Add-on으로 에이전트를 설치합니다. 이 에이전트가 각 노드에서 실행되며 마법을 부리는 주체입니다. 🪄
2. 단순한 IAM 역할 생성: 이제 IAM 역할의 신뢰 정책이 놀랍도록 단순해집니다. "EKS Pod Identity 서비스는 나를 믿어도 좋아!" 한 줄이면 끝입니다.
3. Pod Identity Association 생성: AWS 콘솔이나 CLI를 통해 IAM 역할과 쿠버네티스 서비스 어카운트를 매핑(Association)해줍니다. 이 작업은 쿠버네티스 외부, 즉 AWS에서 이루어집니다.
4. 자격 증명 획득: 파드가 AWS 자격 증명을 요청하면, 노드에 있던 에이전트가 요청을 가로챕니다. 그리고 AWS에 설정된 매핑 정보를 확인한 후, 올바른 IAM 역할의 임시 자격 증명을 대신 받아 파드에게 전달해줍니다.

🔧 EKS Pod Identity 설정 예시

IRSA와 비교했을 때 IAM 신뢰 정책이 얼마나 간단해졌는지 보세요.

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

네, 이게 전부입니다. OIDC URL도, 네임스페이스도, 서비스 어카운트 이름도 필요 없습니다! ✨

IAM 역할과 서비스 어카운트의 연결은 AWS CLI를 통해 이렇게 한 줄로 끝낼 수 있습니다.

aws eks create-pod-identity-association \
    --cluster-name my-eks-cluster \
    --namespace my-namespace \
    --service-account my-app-sa \
    --role-arn arn:aws:iam::111122223333:role/my-app-s3-access-role

이제 개발자는 서비스 어카운트 YAML 파일에 복잡한 어노테이션을 넣을 필요 없이, 그냥 serviceAccountName: my-app-sa만 지정하면 됩니다.

👍 EKS Pod Identity의 장점

• 혁신적인 단순함: 복잡한 신뢰 정책이 사라지고, IAM 역할 관리가 매우 쉬워집니다.
• 중앙 관리 및 역할 분리: 인프라팀은 AWS에서 권한 매핑을 관리하고, 개발팀은 애플리케이션 코드에만 집중할 수 있습니다. 역할과 책임이 명확해지죠!
• 유연성과 재사용성: 하나의 IAM 역할을 여러 네임스페이스, 여러 서비스 어카운트에 쉽게 매핑할 수 있어 역할 재사용성이 극대화됩니다.
• 설정과 코드의 분리: IAM 역할 정보가 쿠버네티스 매니페스트에서 분리되어, 권한 변경 시 애플리케이션을 재배포할 필요가 없습니다.

👎 EKS Pod Identity의 단점

• 에이전트 의존성: 모든 노드에 EKS Pod Identity 에이전트 애드온을 설치하고 관리해야 합니다.
• 상대적으로 새로운 기능: IRSA에 비해 아직 커뮤니티의 사용 사례나 트러블슈팅 정보가 적을 수 있습니다.

---

🆚 IRSA vs EKS Pod Identity: 한눈에 비교하기

구분	IRSA (IAM Roles for Service Accounts)	EKS Pod Identity
작동 방식	K8s 서비스 어카운트 ↔️ IAM 역할 (OIDC 직접 연결)	파드 ➡️ 에이전트 ➡️ IAM 역할 (매핑 기반)
설정의 중심	쿠버네티스 (서비스 어카운트 어노테이션)	AWS (Pod Identity Association)
IAM 신뢰 정책	매우 복잡 😭 (OIDC, 네임스페이스, SA 조건 명시)	매우 단순 😊 ("Service": "pods.eks.amazonaws.com")
관리 편의성	낮음 (개별 정책 관리의 번거로움)	높음 (중앙에서 매핑 정보 관리)
유연성	낮음 (IAM 역할과 서비스 어카운트 1:1 강한 결합)	높음 (역할과 SA 분리, N:M 매핑 용이)

---

🎯 그래서, 당신의 선택은?

자, 이제 어떤 것을 선택해야 할지 명확해졌을 겁니다.

🚀 EKS Pod Identity를 선택하세요!

• 새로운 EKS 클러스터를 구축하거나, 이제 막 권한 설정을 시작하는 경우 (강력 추천!)
• 수많은 마이크로서비스를 운영하여 IAM 역할 관리를 단순화하고 싶은 경우
• 인프라팀과 개발팀의 역할과 책임을 명확히 분리하고 싶은 경우
• 하나의 공통된 역할을 여러 애플리케이션에서 재사용하고 싶은 경우

🤔 IRSA를 계속 사용하거나 고려할 수 있어요.

• 이미 IRSA 기반으로 모든 시스템이 안정적으로 운영되고 있고, 마이그레이션할 여력이 없는 경우
• 보안 정책 등의 이유로 노드에 추가적인 에이전트를 설치하기 곤란한 경우
• 모든 권한 설정을 쿠버네티스 매니페스트 안에서 코드로 명시적으로 관리(GitOps)하는 방식을 선호하는 경우

✨ 결론

EKS Pod Identity는 IRSA의 복잡성을 해결하고, 클라우드 네이티브 환경에 더 적합한 권한 관리 패러다임을 제시합니다. 설정의 단순함, 관리의 중앙화, 유연한 재사용성은 더 이상 거부할 수 없는 매력적인 장점입니다.

물론 IRSA가 나쁜 기술이라는 의미는 아닙니다. 하지만 더 쉽고 효율적인 길이 열렸다면, 그 길을 마다할 이유는 없겠죠? 지금 EKS 권한 관리를 고민하고 있다면, EKS Pod Identity를 적극적으로 검토해 보시길 바랍니다!

---