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

🔸 1. Pod에게 AWS 권한을 부여하는 방법

EKS 클러스터에서 실행되는 애플리케이션이 S3, SQS, MSK와 같은 AWS 서비스에 접근해야 하는 경우가 많다. 이때 Pod에게 AWS 권한을 부여하는 방법은 여러 가지가 있다.

1.1 기존 방식의 한계

• EC2 Instance Profile 방식:
  노드에 IAM Role을 부여하는 방식. 이 방식은 해당 노드에서 실행되는 모든 Pod가 동일한 권한을 갖게 되어 최소 권한 원칙에 위배된다.
• Access Key 방식:
  IAM User의 Access Key를 Pod에 직접 주입하는 방식. 키 탈취 위험과 키 관리의 복잡성 때문에 프로덕션 환경에서는 지양해야 한다.

이러한 한계를 해결하기 위해 AWS는 2019년에 IRSA(IAM Roles for Service Accounts)를 도입했고, 2023년 re:Invent에서 Pod Identity를 발표했다.

---

🔸 2. IRSA (IAM Roles for Service Accounts)

2.1 IRSA 개요

IRSA는 Kubernetes의 Service Account에 IAM Role을 연결하여 Pod 단위로 AWS 권한을 부여하는 방식이다.

AWS 공식 문서에 따르면, IRSA는 OIDC(OpenID Connect)를 활용하여 Pod가 AWS STS의 AssumeRoleWithWebIdentity API를 통해 임시 자격증명을 획득한다.

---

2.2 IRSA 동작 원리

IRSA의 전체 흐름을 시퀀스 다이어그램으로 살펴보면 다음과 같다.

Pod 생성 시점

1. ServiceAccount를 지정하여 Pod 생성 요청을 Kubernetes API Server에 보낸다.
2. API Server가 Mutating Admission Webhook을 호출한다.
3. Pod Identity Webhook이 ServiceAccount에 eks.amazonaws.com/role-arn 어노테이션이 있는지 확인한다.
4. 어노테이션이 있으면 Pod Spec을 수정하여 환경변수(AWS_ROLE_ARN, AWS_WEB_IDENTITY_TOKEN_FILE)와 토큰 Volume을 주입한다.
5. Pod 생성이 완료된다.

AWS API 호출 시점

1. Pod 내 애플리케이션의 AWS SDK가 주입된 환경변수를 감지한다.
2. 마운트된 Projected Service Account Token 파일을 읽는다.
3. AWS STS에 AssumeRoleWithWebIdentity(Token, RoleARN)를 호출한다.
4. STS가 JWT의 iss(issuer) claim을 확인하여 해당 EKS OIDC Provider를 식별한다.
5. STS가 OIDC Provider의 JWKS(JSON Web Key Set) 엔드포인트에서 Public Key를 가져온다.
   • 엔드포인트: https://oidc.eks.{region}.amazonaws.com/id/{cluster-id}/keys
6. 가져온 Public Key로 JWT 서명을 검증한다. (Kubernetes API Server가 Private Key로 서명했으므로 대응되는 Public Key로 검증)
7. JWT의 claims를 확인한다.
   • iss: 발급자가 해당 EKS 클러스터의 OIDC Provider인지
   • sub: system:serviceaccount:{namespace}:{sa-name} 형식의 주체
   • aud: sts.amazonaws.com인지
8. STS가 IAM Role의 Trust Policy를 검증한다.
   • Trust Policy의 Federated Principal이 해당 OIDC Provider인지
   • Condition의 sub, aud 조건이 JWT claims와 일치하는지
9. 모든 검증이 통과하면 임시 자격증명(AccessKey, SecretKey, Token)을 반환한다.

---

2.3 핵심 구성요소 분석

2.3.1 OIDC Provider

EKS 클러스터를 생성하면 AWS는 자동으로 해당 클러스터에 대한 OIDC Provider를 생성한다. AWS 공식 문서에 따르면, Kubernetes 1.12부터 ProjectedServiceAccountToken 기능이 추가되어 OIDC JWT 토큰을 발급할 수 있게 되었다.

 

OIDC Provider URL은 다음 명령어로 확인할 수 있다.

aws eks describe-cluster --name $CLUSTER_NAME --query "cluster.identity.oidc.issuer" --output text

출력 예시: https://oidc.eks.ap-northeast-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E

2.3.2 Pod Identity Webhook

AWS의 amazon-eks-pod-identity-webhook GitHub 레포지토리를 살펴보면, 이 Webhook은 Mutating Admission Webhook으로 동작하며 Pod 생성 시 다음 항목들을 자동으로 주입한다.

• 환경변수:
  • AWS_ROLE_ARN: 사용할 IAM Role의 ARN
  • AWS_WEB_IDENTITY_TOKEN_FILE: 토큰 파일 경로
  • AWS_STS_REGIONAL_ENDPOINTS: regional (지역 엔드포인트 사용)
• 볼륨:
  • aws-iam-token: Projected Service Account Token이 마운트되는 볼륨

env:
- name: AWS_ROLE_ARN
  value: arn:aws:iam::123456789012:role/my-role
- name: AWS_WEB_IDENTITY_TOKEN_FILE
  value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
volumeMounts:
- mountPath: /var/run/secrets/eks.amazonaws.com/serviceaccount
  name: aws-iam-token
  readOnly: true
volumes:
- name: aws-iam-token
  projected:
    sources:
    - serviceAccountToken:
        audience: sts.amazonaws.com
        expirationSeconds: 86400
        path: token

 

2.3.3 IAM Role Trust Policy

IRSA를 사용하는 IAM Role의 Trust Policy는 다음과 같은 형태를 가진다.

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

Condition의 sub 필드는 system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME 형식으로 특정 네임스페이스의 특정 Service Account만 이 Role을 Assume할 수 있도록 제한한다.

---

2.4 IRSA의 보안 취약점

IRSA에는 몇 가지 보안 고려사항이 있다.

1. Trust Policy에서 system:serviceaccount:*:*와 같이 와일드카드를 사용하면 토큰만 검증받으면 모든 Service Account가 해당 Role을 사용할 수 있게 된다.
2. OIDC 엔드포인트가 퍼블릭이기 때문에 Service Account의 토큰 값과 Role ARN만 알면 외부에서도 STS 임시자격증명 발급을 요청할 수 있다.

# 토큰과 Role ARN을 알면 외부에서도 자격증명 획득 가능
aws sts assume-role-with-web-identity \
  --role-arn $ROLE_ARN \
  --role-session-name mysession \
  --web-identity-token $IAM_TOKEN

이러한 한계점을 보완하기 위해 AWS는 Pod Identity를 출시했다.

---

🔸 3. EKS Pod Identity

3.1 Pod Identity 개요

AWS 공식 블로그에 따르면, Pod Identity는 2023년 re:Invent에서 발표된 기능으로 IRSA보다 간소화된 방식으로 Pod에 AWS 권한을 부여한다.

IRSA와의 가장 큰 차이점은 OIDC Provider를 직접 관리할 필요가 없고, Trust Policy에 클러스터별 OIDC URL을 명시할 필요가 없다는 것이다.

---

3.2 Pod Identity 아키텍처

 

1. Pod가 eks-pod-identity-token과 함께 Pod Identity Agent(169.254.170.23:80)에 자격증명을 요청한다.
2. Pod Identity Agent가 노드의 IAM 권한을 사용하여 EKS Auth API에 AssumeRoleForPodIdentity를 호출한다.
3. EKS Auth API가 토큰에서 ServiceAccount 정보를 추출하고, Pod Identity Association에서 해당 ServiceAccount와 IAM Role 매핑을 확인한다.
4. EKS Auth API가 AWS STS를 통해 임시 자격증명을 발급받아 Pod Identity Agent에게 반환한다.
5. Pod Identity Agent가 Pod에게 임시 자격증명(AccessKeyId, SecretAccessKey, Token)을 반환한다.

 

---

3.3 Pod Identity 동작 원리

Pod Identity의 동작 과정을 상세히 살펴보자.

3.3.1 Pod Identity Agent

Pod Identity를 사용하려면 먼저 eks-pod-identity-agent 애드온을 설치해야 한다.

aws eks create-addon \
  --cluster-name $CLUSTER_NAME \
  --addon-name eks-pod-identity-agent \
  --addon-version v1.0.0-eksbuild.1

이 Agent는 DaemonSet으로 배포되어 각 노드에서 실행된다.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: eks-pod-identity-agent
  namespace: kube-system
spec:
  template:
    spec:
      hostNetwork: true
      containers:
      - name: eks-pod-identity-agent
        image: 602401143452.dkr.ecr.us-east-1.amazonaws.com/eks/eks-pod-identity-agent
        ports:
        - containerPort: 80
          hostPort: 80
        - containerPort: 2703
          hostPort: 2703

여기서 주목할 점은 hostNetwork: true 설정이다. Agent는 호스트 네트워크를 사용하며, Link-Local 주소인 169.254.170.23의 포트 80과 2703을 점유한다.

3.3.2 Link-Local 주소 169.254.170.23

그렇다면 왜 169.254.170.23이라는 특정 주소를 사용하는 걸까?

169.254.0.0/16 대역은 Link-Local 주소로, 로컬 네트워크 세그먼트 내에서만 통신이 가능하다. AWS에서는 이미 EC2 Instance Metadata Service(IMDS)가 169.254.169.254를 사용하고 있다. Pod Identity Agent는 이와 유사한 방식으로 169.254.170.23을 사용하여 동일 노드의 Pod들에게만 자격증명을 제공한다.

Agent의 init container는 pod-id-link0이라는 네트워크 인터페이스를 생성하고 라우팅 규칙을 설정한다.

# 노드에서 확인
$ ss -anltp | grep eks-pod
LISTEN 0 4096 127.0.0.1:2703    0.0.0.0:*  users:(("eks-pod-identit"...))
LISTEN 0 4096 169.254.170.23:80 0.0.0.0:*  users:(("eks-pod-identit"...))

3.3.3 자격증명 획득 과정

Pod Identity가 활성화된 Pod가 생성되면 Webhook이 다음 환경변수와 볼륨을 주입한다.

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"
volumes:
- name: eks-pod-identity-token
  projected:
    sources:
    - serviceAccountToken:
        audience: pods.eks.amazonaws.com
        expirationSeconds: 86400
        path: eks-pod-identity-token

IRSA와 비교했을 때 중요한 차이점이 있다. IRSA는 AWS_WEB_IDENTITY_TOKEN_FILE을 사용하여 SDK가 직접 STS를 호출하지만, Pod Identity는 AWS_CONTAINER_CREDENTIALS_FULL_URI를 사용하여 로컬 Agent에게 자격증명을 요청한다.

실제 자격증명 획득 과정을 시퀀스 다이어그램으로 표현하면 다음과 같다.

1. Pod 내 애플리케이션(AWS SDK)이 AWS API 호출 시 AWS_CONTAINER_CREDENTIALS_FULL_URI 환경변수를 감지한다.
2. AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE 경로에서 eks-pod-identity-token 파일을 읽는다.
3. 읽어온 토큰을 Authorization 헤더에 담아 Pod Identity Agent(169.254.170.23:80)에 GET /v1/credentials 요청을 보낸다.
4. Pod Identity Agent가 전달받은 토큰에서 Namespace, ServiceAccount 정보를 추출한다.
5. Agent가 EKS Auth API의 AssumeRoleForPodIdentity를 호출한다.
6. EKS Auth API가 해당 클러스터의 Pod Identity Association을 조회하여 ServiceAccount와 IAM Role 매핑을 확인한다.
7. 매핑된 IAM Role의 Trust Policy를 검증한다.
8. 검증이 완료되면 EKS Auth API가 임시 자격증명을 Agent에게 반환한다.
9. Agent가 애플리케이션에게 JSON 형태로 임시 자격증명(AccessKeyId, SecretAccessKey, Token, Expiration)을 응답한다.
10. 애플리케이션은 이 자격증명으로 AWS 서비스에 접근한다.

Pod에서 직접 Agent에게 요청을 보내면 다음과 같은 응답을 받을 수 있다.

$ TOKEN=$(cat /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token)
$ curl 169.254.170.23/v1/credentials -H "Authorization: $TOKEN"
{
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "...",
  "Token": "...",
  "AccountId": "123456789012",
  "Expiration": "2024-01-15T18:46:49Z"
}

3.3.4 IAM Role Trust Policy

Pod Identity를 사용하는 IAM Role의 Trust Policy는 IRSA보다 훨씬 단순하다.

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

클러스터별 OIDC URL이 없기 때문에 동일한 Role을 여러 EKS 클러스터에서 재사용할 수 있다. 또한 sts:TagSession 액션을 통해 ABAC(Attribute-Based Access Control)을 구현할 수 있다.

3.3.5 Pod Identity Association

Role과 Service Account의 매핑은 AWS API를 통해 관리된다.

aws eks create-pod-identity-association \
  --cluster-name $CLUSTER_NAME \
  --namespace default \
  --service-account-name my-sa \
  --role-arn arn:aws:iam::123456789012:role/my-pod-role

어떤 Pod가 어떤 Role에 접근할 수 있는지 확인하는 것도 간단하다.

# 클러스터의 모든 Pod Identity Association 조회
aws eks list-pod-identity-associations --cluster-name $CLUSTER_NAME

# 특정 Association 상세 정보
aws eks describe-pod-identity-association \
  --cluster-name $CLUSTER_NAME \
  --association-id a-0123456789

---

🔸 4. IRSA vs Pod Identity 비교

4.1 아키텍처 비교

---

4.2 주요 차이점

구분 IRSA Pod Identity

출시 시점	2019년	2023년 (re:Invent)
OIDC Provider	클러스터별 필요	불필요
Trust Policy	클러스터 OIDC URL 명시 필요	pods.eks.amazonaws.com만 명시
Role 재사용	클러스터별 Trust Policy 수정 필요	여러 클러스터에서 그대로 사용 가능
자격증명 획득	Pod가 직접 STS 호출	Agent가 대신 호출
권한 매핑 확인	IAM Role Trust Policy 분석 필요	ListPodIdentityAssociations API
AWS SDK 요구사항	Web Identity Token 지원 버전	Container Credentials 지원 버전
ABAC 지원	미지원	sts:TagSession으로 지원

---

🪄 정리

EKS에서 Pod에게 AWS 권한을 부여하는 방식으로 IRSA와 Pod Identity 두 가지가 있다.
IRSA는 OIDC Provider를 통해 Kubernetes Service Account Token을 AWS STS가 검증하고 임시 자격증명을 발급하는 방식이다.Pod Identity는 각 노드에서 실행되는 Agent가 169.254.170.23 주소로 자격증명 요청을 받아 EKS Auth API의 AssumeRoleForPodIdentity를 호출하는 방식으로, OIDC Provider 없이도 동작하며 Trust Policy가 단순하다.
Pod Identity가 더 최신 기능이고 관리가 편리하지만, 아직 일부 AWS 컴포넌트가 지원하지 않으므로 상황에 맞게 선택해야 한다.

---

📙 출처

• AWS 공식 블로그 - Amazon EKS Pod Identity: https://aws.amazon.com/ko/blogs/korea/amazon-eks-pod-identity-simplifies-iam-permissions-for-applications-on-amazon-eks-clusters/
• AWS 공식 문서 - IAM roles for service accounts: https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html
• AWS 공식 문서 - EKS Pod Identity: https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html
• AWS 공식 문서 - How EKS Pod Identity works: https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html
• Datadog Security Labs - Deep dive into EKS Pod Identity: https://securitylabs.datadoghq.com/articles/eks-pod-identity-deep-dive/
• AWS GitHub - amazon-eks-pod-identity-webhook: https://github.com/aws/amazon-eks-pod-identity-webhook
• AWS Containers Blog - 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/
• 참고 블로그 (velog): https://velog.io/@6ain/AKES2-6주차-EKS-Security-EKS-IRSA-Pod-Identity