[AWS] MSK에서 EKS Pod Identity 적용 시 발생하는 인증 문제와 해결 방안

🧐 들어가기전

[AWS] EKS IRSA vs Pod Identity 동작 원리

해당 포스트에서 다루었던 EKS Pod Identity를 적용하여 AWS Infra를 관리하고자 하였고, 현재 우리 팀에서는 MSK를 비롯한 다양한 관리형 서비스들을 사용하고 있었다. 기존에 MSK는 IRSA방식으로 인증/인가를 진행하고 있었는데, 이번에 Pod Identity로 마이그레이션을 진행하고 하였다.

 

각 백엔드 어플리케이션은 Pod Identity를 적용한 Role을 가지도록하였고, 기존에 aws-msk-iam-auth 라이브러리로 kafka 모듈을 정의해놓았기 때문에 문제없이 연결에 성공할 수 있었다.

하지만, 문제는 1시간 후에 일어났다. 1시간 후에 카프카를 통해 이벤트를 발행하는 서비스들에서 위와 같은 무수히 많은 에러 로그가 찍히게 되었고 연결은 정상적으로 이루어지지 않았다.

 

무슨일이 일어난걸까? 

---

🔸 1. 문제의 핵심: MSK IAM 인증과 세션 이름

1.1 MSK IAM 인증의 동작 원리

GitHub - aws/aws-msk-iam-auth: Enables developers to use AWS Identity and Access Management (IAM) to connect to their Amazon Man

Amazon MSK(Managed Streaming for Apache Kafka)는 IAM 기반 인증을 지원한다. aws-msk-iam-auth 라이브러리의 GitHub 저장소를 살펴보면, 이 라이브러리는 AWS_MSK_IAM이라는 새로운 SASL 메커니즘을 제공한다.

IAMSaslClient는 Kafka 브로커에 새로운 연결을 열거나 기존 연결을 재인증할 때마다 새로 생성된다.

여기서 중요한 점은 MSK가 re-authentication 시 principal(세션 이름 포함)의 변경을 허용하지 않는다는 것이다.

1.2 EKS Pod Identity의 세션 이름 생성 방식

Amazon EKS Pod Identity: a new way for applications on EKS to obtain IAM credentials | Amazon Web Services

AWS 컨테이너 블로그에서 확인할 수 있듯이, EKS Pod Identity Agent는 AssumeRoleForPodIdentity API를 호출할 때 세션 이름을 자동으로 생성한다.

CloudTrail 로그를 살펴보면 다음과 같은 형식의 세션 이름이 생성되는 것을 확인할 수 있다:

{
    "requestParameters": {
        "roleArn": "arn:aws:iam::123456789012:role/my-pod-role",
        "roleSessionName": "eks-eks-pod-identity-secretmgr--24690dab-4c88-462f-89cc-3b77432e51ba",
        ...
    }
}

세션 이름이 eks-{cluster}-{namespace/service}-{UUID} 형식으로 생성되며, 자격 증명이 갱신될 때마다 UUID 부분이 변경된다.

1.3 문제 발생 시나리오

AWS 컨테이너 로드맵의 GitHub 이슈 #2362에서 이 문제가 명확하게 보고되었다. 실제 에러 메시지를 살펴보면:

failed authentication due to: Cannot change principals during re-authentication 
from IAM.arn:aws:sts::ACCOUNT:assumed-role/bookingApiPod/eks-k8s-wl-prd-engine-boo-064f1ed1-2349-4774-b895-9a69ccc3eeb1: 
IAM.arn:aws:sts::ACCOUNT:assumed-role/bookingApiPod/eks-k8s-wl-prd-engine-boo-875fdfcd-19cd-4ac3-8544-7077f94a6e39

두 세션 이름의 UUID 부분이 다른 것을 확인할 수 있다. MSK는 초기 인증 시 사용된 principal과 재인증 시의 principal이 일치해야 하는데, Pod Identity가 자격 증명을 갱신하면서 세션 이름이 변경되어 인증이 실패하게 된다.

여기서 한 가지 의문이 생긴다. 일반적으로 AWS SDK에서는 AWS_ROLE_SESSION_NAME 환경 변수를 설정하여 세션 이름을 고정할 수 있는데, Pod Identity에서는 왜 이 방법이 통하지 않을까?

이는 Pod Identity의 아키텍처 때문이다. Pod Identity에서는 사용자 애플리케이션이 직접 STS:AssumeRole을 호출하는 것이 아니라, eks-pod-identity-agent가 AssumeRoleForPodIdentity API를 호출한다. 따라서 사용자가 세션 이름을 제어할 수 있는 방법이 없다.

---

🔸 2. IRSA와 Pod Identity의 차이점

2.1 인증 흐름 비교

IRSA에서는 애플리케이션이 직접 AWS SDK를 통해 AssumeRoleWithWebIdentity를 호출한다. 이 경우 aws-msk-iam-auth 라이브러리에서 awsRoleSessionName 설정을 통해 세션 이름을 고정할 수 있다.

하지만 Pod Identity에서는 eks-pod-identity-agent DaemonSet이 중간에 개입하여 자격 증명을 관리한다. AWS 컨테이너 블로그를 살펴보면, Pod의 환경 변수에 다음과 같이 설정된다:

env:
- name: AWS_CONTAINER_CREDENTIALS_FULL_URI
  value: http://169.254.170.23/v1/credentials
- name: AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE
  value: /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token

AWS SDK는 이 환경 변수를 통해 eks-pod-identity-agent 엔드포인트에서 자격 증명을 가져오고, agent가 내부적으로 AssumeRoleForPodIdentity를 호출하여 세션 이름을 자동 생성한다.

2.2 세션 이름 제어 가능 여부

자격 증명 획득 방식	AssumeRoleWithWebIdentity	AssumeRoleForPodIdentity
세션 이름 설정	awsRoleSessionName으로 가능	불가능 (agent가 자동 생성)
세션 태그 지원	미지원	지원

---

🔸 3. 해결 방안

3.1 방안 1: MSK에만 IRSA 적용, 나머지는 Pod Identity

가장 간단한 접근 방식이다. MSK에 접근하는 부분만 IRSA를 유지하고, 나머지 AWS 서비스에 대해서는 Pod Identity를 사용한다.

AWS 블로그에서 언급된 것처럼, EKS Pod Identity 웹훅은 동일한 서비스 계정에 IRSA와 Pod Identity가 모두 설정되어 있을 때 Pod Identity를 우선시한다. 따라서 MSK 전용 서비스 계정을 별도로 분리하여 IRSA를 적용해야 한다.

이 방법의 장점은 구현이 단순하다는 것이다. 하지만 하나의 Pod에서 두 가지 자격 증명 방식을 혼용해야 하므로 관리 복잡도가 증가한다.

---

3.2 방안 2: 전체 IRSA로 전환

Pod Identity 대신 모든 서비스에 IRSA를 사용하는 방법이다.

이 방법은 MSK 호환성 문제를 완전히 해결할 수 있지만, 몇 가지 단점이 존재한다:

• OIDC Provider 관리 필요: 클러스터마다 IAM OIDC Provider를 설정해야 하며, 계정당 100개의 기본 제한이 있다.
• Trust Policy 관리 복잡도: 새 클러스터를 추가할 때마다 IAM Role의 Trust Policy를 업데이트해야 한다.
• 마이그레이션 비용: 이미 Pod Identity로 전환한 서비스들을 다시 IRSA로 롤백해야 한다. -> 그렇게 비용이 크진 않다.

---

3.3 방안 3: Kafka 클라이언트 연결 수명 조정

Kafka 클라이언트의 연결 수명을 STS 토큰의 유효 기간(기본 1시간)에 맞춰 설정하여, 재인증 시점 전에 연결을 끊고 새로 연결하는 방식이다.

# Kafka Producer/Consumer 설정
connections.max.idle.ms=3540000  # 59분

하지만 이 방법은 불안정한 측면이 있다. 네트워크 지연이나 타이밍 이슈로 인해 재인증이 발생할 수 있으며, 연결이 자주 끊어지면서 성능 저하가 발생할 수 있다.

---

⭐️ 3.4 방안 4: MSK 전용 IAM Role Chain 구성 

사실 이 해결책을 때문에 블로그 글을 작성했다.

Pod Identity가 획득한 자격 증명으로 MSK 전용 IAM Role을 assume하고, 이때 세션 이름을 고정하는 방식이다.

우선 이 해결방안에 대한 과정은 다음과 같다.

1. Application Pod가 Pod Identity Agent에 자격 증명을 요청한다.
2. Pod Identity Agent가 AWS STS에 AssumeRoleForPodIdentity를 호출한다.
3. AWS STS가 임시 자격 증명을 반환한다. (세션: 변동 UUID)
4. Pod Identity Agent가 Application Pod에 자격 증명을 전달한다.
5. Application Pod가 MSK 전용 Role을 AssumeRole한다. (세션: "my-service-msk" 고정)
6. AWS STS가 MSK Role 자격 증명을 반환한다. (고정 세션)
7. Application Pod가 고정된 세션 이름으로 MSK Broker에 SASL 인증을 수행한다.
8. MSK Broker가 인증 성공을 반환한다.
9. 자격 증명 갱신 시에도 5~8 과정에서 세션 이름이 동일하게 유지되어 재인증이 정상 동작한다.

3.4.1 MSK 전용 IAM Role 생성

먼저 MSK 접근을 위한 전용 IAM Role을 생성한다. Trust Policy에서 Pod Identity Role이 이 Role을 assume할 수 있도록 설정한다:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/my-pod-identity-role"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

3.4.2 Pod Identity Role에 AssumeRole 권한 추가

Pod Identity Role에 MSK 전용 Role을 assume할 수 있는 권한을 추가한다:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::123456789012:role/my-msk-role"
    }
  ]
}

3.4.3 Kafka 클라이언트 설정

sasl.jaas.config=software.amazon.msk.auth.iam.IAMLoginModule required \
  awsRoleArn="arn:aws:iam::123456789012:role/my-msk-role" \
  awsRoleSessionName="my-service-msk" \
  awsStsRegion="ap-northeast-2";

 

Pod Identity가 자격 증명을 갱신할 때마다 기본 자격 증명의 세션 이름은 변경되지만

Kafka 클라이언트는 항상 my-msk-role을 assume하면서 my-service-msk라는 고정된 세션 이름을 사용한다

MSK 입장에서는 principal이 항상 동일하게 유지되므로 재인증이 정상적으로 동작한다

3.4.4 Spring Kafka 적용 예시

spring:
  kafka:
    bootstrap-servers: b-1.msk-cluster.xxxxx.kafka.ap-northeast-2.amazonaws.com:9098
    properties:
      security.protocol: SASL_SSL
      sasl.mechanism: AWS_MSK_IAM
      sasl.jaas.config: >
        software.amazon.msk.auth.iam.IAMLoginModule required
        awsRoleArn="arn:aws:iam::123456789012:role/my-msk-role"
        awsRoleSessionName="my-service-msk"
        awsStsRegion="ap-northeast-2";
      sasl.client.callback.handler.class: software.amazon.msk.auth.iam.IAMClientCallbackHandler

3.4.5 적용 결과

https://github.com/aws/containers-roadmap/issues/2362

 

이러한 구조를 통해서 Pod Identity Role은 중간에 위치한 MSK 전용 Role 덕분에 고정적인 세션이름을 가질 수 있게 되었으며, 실제로 위의 방식을 적용한 이후로 24시간동안 안정적으로 인증을 수행하며 동작하는 것을 확인할 수 있었다.

---

정리

EKS Pod Identity를 MSK와 함께 사용할 때 발생하는 인증 실패 문제는 eks-pod-identity-agent가 자격 증명을 갱신할 때마다 세션 이름을 새로운 UUID로 변경하기 때문에 발생한다. MSK는 재인증 시 principal 변경을 허용하지 않으므로, 세션 이름이 바뀌면 "Cannot change principals during re-authentication" 에러가 발생한다.
이 문제를 해결하는 가장 효과적인 방법은 MSK 전용 IAM Role을 생성하고, aws-msk-iam-auth 라이브러리의 awsRoleArn과 awsRoleSessionName 설정을 통해 Kafka 클라이언트가 항상 고정된 세션 이름으로 MSK에 접근하도록 구성하는 것이다. 이를 통해 Pod Identity의 장점을 유지하면서도 MSK와의 안정적인 연결을 보장할 수 있다.

---

📙 출처

• AWS 컨테이너 로드맵 GitHub 이슈 #2362: https://github.com/aws/containers-roadmap/issues/2362
• aws-msk-iam-auth GitHub: https://github.com/aws/aws-msk-iam-auth
• Amazon EKS Pod Identity 블로그: https://aws.amazon.com/blogs/containers/amazon-eks-pod-identity-a-new-way-for-applications-on-eks-to-obtain-iam-credentials/
• MSK IAM 인증 공식 문서: https://docs.aws.amazon.com/msk/latest/developerguide/iam-access-control.html
• aws-msk-iam-sasl-signer-js 이슈 #27: https://github.com/aws/aws-msk-iam-sasl-signer-js/issues/27