[AWS EKS] EKS Security 6 - EKS IRSA & Pod Identity

주영·2025년 3월 15일
POD Identityawseksirsakubernetessecurity보안쿠버네티스
0

AWS EKS Workshop Study 3기

목록 보기
23/31

이 글은 CloudNet@팀의 AWS EKS Workshop Study(AEWS) 3기 스터디 내용을 바탕으로 작성되었습니다.
AEWS는 CloudNet@의 '가시다'님께서 진행하는 스터디로, EKS를 학습하는 과정입니다.
EKS를 깊이 있게 이해할 기회를 주시고, 소중한 지식을 나눠주시는 가시다님께 다시 한번 감사드립니다.
이 글이 EKS를 학습하는 분들께 도움이 되길 바랍니다.

1. Kubernetes Service Account 및 OIDC 기반 인증 실습

Kubernetes에서는 각 Pod에 Service Account가 자동으로 할당되며, 이 Service Account는 Kubernetes API와의 인증을 위해 JWT(JSON Web Token) 토큰을 생성합니다.

이 실습은 Kubernetes의 Service Account와 JWT 토큰이 어떻게 생성 및 활용되는지 확인하는 실습입니다.

EKS에서 제공하는 OIDC(OpenID Connect) Provider를 통해 인증된 토큰이 Kubernetes API 및 AWS API와 어떻게 연계될 수 있는지를 살펴봅니다.

1.1 Service Account가 자동 할당되는 파드 생성

# 파드2 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: eks-iam-test2
spec:
  containers:
    - name: my-aws-cli
      image: amazon/aws-cli:latest
      command: ['sleep', '36000']
  restartPolicy: Never
  terminationGracePeriodSeconds: 0
EOF

# 파드 상태 확인
kubectl get pod
kubectl describe pod
kubectl get pod eks-iam-test2 -o yaml
  • amazon/aws-cli:latest 컨테이너에서 AWS CLI를 실행합니다.
  • command: ['sleep', '36000'] → 파드를 유지하기 위해 10시간 동안 대기하도록 설정합니다.
  • 서비스 어카운트 토큰이 자동으로 /var/run/secrets/kubernetes.io/serviceaccount/token에 마운트됩니다.

1.2 Service Account 및 JWT 토큰 확인

# Service Account 토큰 확인 
kubectl exec -it eks-iam-test2 -- ls /var/run/secrets/kubernetes.io/serviceaccount
kubectl exec -it eks-iam-test2 -- cat /var/run/secrets/kubernetes.io/serviceaccount/token ;echo

1.3 AWS API 접근 테스트

# aws 서비스 사용 시도
kubectl exec -it eks-iam-test2 -- aws s3 ls

1.3 JWT 토큰 분석 및 OIDC Provider 확인

# 서비스 어카운트 토큰 확인
SA_TOKEN=$(kubectl exec -it eks-iam-test2 -- cat /var/run/secrets/kubernetes.io/serviceaccount/token)
echo $SA_TOKEN

# JWT 토큰 디코딩
# jwt 혹은 아래 JWT 웹 사이트 이용 https://jwt.io/
jwt decode $SA_TOKEN --json --iso8601
...

# 헤더
{
  "alg": "RS256",
  "kid": "1a8fcaee12b3a8f191327b5e9b997487ae93baab"
}

# 페이로드 : OAuth2에서 쓰이는 aud, exp 속성 확인! > projectedServiceAccountToken 기능으로 토큰에 audience,exp 항목을 덧붙힘
## iss 속성 : EKS OpenID Connect Provider(EKS IdP) 주소 > 이 EKS IdP를 통해 쿠버네티스가 발급한 토큰이 유요한지 검증
{
  "aud": [
    "https://kubernetes.default.svc"  # 해당 주소는 k8s api의 ClusterIP 서비스 주소 도메인명, kubectl get svc kubernetes
  ],
  "exp": 1716619848,
  "iat": 1685083848,
  "iss": "https://oidc.eks.ap-northeast-2.amazonaws.com/id/F6A7523462E8E6CDADEE5D41DF2E71F6",
  "jti": "ee823c34-f020-4f77-90f3-61fab4de244a",
  "kubernetes.io": {
    "namespace": "default",
    "node": {
      "name": "ip-192-168-1-70.ap-northeast-2.compute.internal",
      "uid": "f4fabf42-4a9c-43f0-8a1e-edeb2a8fbb42"
    },
    "pod": {
      "name": "eks-iam-test2",
      "uid": "10dcccc8-a16c-4fc7-9663-13c9448e107a"
    },
    "serviceaccount": {
      "name": "default",
      "uid": "acb6c60d-0c5f-4583-b83b-1b629b0bdd87"
    },
    "warnafter": 1685087455
  },
  "nbf": 1685083848,
  "sub": "system:serviceaccount:default:default"
}

# 파드2 삭제
kubectl delete pod eks-iam-test2
  • aud → 토큰의 audience(대상)이며, Kubernetes API의 서비스 주소(https://kubernetes.default.svc)가 설정됨.
  • iss → 토큰 발급자(issuer)이며, EKS의 OpenID Connect Provider (OIDC) 주소
  • sub → 토큰이 속한 Kubernetes 서비스 어카운트 정보 (system:serviceaccount:default:default)

2. EKS IRSA 실습

EKS에서 IAM Roles for Service Accounts(IRSA)를 활용하여 Kubernetes 파드가 AWS API에 접근하는 과정을 실습하는 내용입니다.

이 실습에서는 OIDC(OpenID Connect) 기반의 IAM 인증을 적용하여 Kubernetes 파드가 AWS IAM 역할을 안전하게 사용하도록 설정하는 방법을 학습합니다.

2.1 IRSA 개요

🔹 IRSA 동작 원리
EKS 환경에서 Kubernetes 파드가 AWS 서비스에 접근할 때 IAM 역할을 사용할 수 있도록 지원하는 기능입니다.
IRSA는 IAM OIDC Identity Provider를 통해 Kubernetes Service Account와 IAM 역할(Role)을 연동합니다.

동작 과정

  1. Kubernetes 파드가 특정 Service Account를 사용하도록 설정됨
  2. 해당 Service Account가 AWS IAM 역할과 연동(Annotation) 되어 있음
  3. EKS Pod Identity Webhook이 자동으로 JWT 토큰을 생성하고, AWS IAM 역할 정보를 주입함
  4. AWS STS(Security Token Service)는 OIDC 토큰을 검증하여 임시 자격 증명(Temporary Credentials)을 발급함
  5. 파드 내부에서 AWS CLI 등을 통해 AWS 서비스에 접근 가능

https://aws.amazon.com/ko/blogs/containers/diving-into-iam-roles-for-service-accounts/

2.2 IRSA 설정

# Create an iamserviceaccount - AWS IAM role bound to a Kubernetes service account
eksctl create iamserviceaccount \
  --name my-sa \
  --namespace default \
  --cluster $CLUSTER_NAME \
  --approve \
  --attach-policy-arn $(aws iam list-policies --query 'Policies[?PolicyName==`AmazonS3ReadOnlyAccess`].Arn' --output text)

# 확인 >> 웹 관리 콘솔에서 CloudFormation Stack >> IAM Role 확인
# aws-load-balancer-controller IRSA는 어떤 동작을 수행할 것 인지 생각해보자!
eksctl get iamserviceaccount --cluster $CLUSTER_NAME

# Inspecting the newly created Kubernetes Service Account, we can see the role we want it to assume in our pod.
kubectl get sa
kubectl describe sa my-sa
Name:                my-sa
Namespace:           default
Labels:              app.kubernetes.io/managed-by=eksctl
Annotations:         eks.amazonaws.com/role-arn: arn:aws:iam::911283464785:role/eksctl-myeks-addon-iamserviceaccount-default-Role1-1MJUYW59O6QGH
Image pull secrets:  <none>
Mountable secrets:   <none>
Tokens:              <none>
Events:              <none>
  • --attach-policy-arn 옵션을 통해 Amazon S3 읽기 전용 액세스 정책(AmazonS3ReadOnlyAccess)을 적용합니다.
  • IRSA는 내부적으로 IAM OIDC Identity Provider와 연동된 IAM 역할을 생성하고, 해당 역할을 Kubernetes 서비스 어카운트에 바인딩합니다.
  • 서비스 어카운트에 eks.amazonaws.com/role-arn annotation이 추가되었습니다.
  • 이 annotation을 통해 해당 서비스 어카운트가 특정 IAM 역할을 가리키고 있음을 확인할 수 있습니다.

2.3 Pod에서 IRSA 사용

# 파드3번 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: eks-iam-test3
spec:
  serviceAccountName: my-sa
  containers:
    - name: my-aws-cli
      image: amazon/aws-cli:latest
      command: ['sleep', '36000']
  restartPolicy: Never
  terminationGracePeriodSeconds: 0
EOF

# 해당 SA를 파드가 사용 시 mutatingwebhook으로 Env,Volume 추가함 : AWS IAM 역할을 Pod에 자동으로 주입
kubectl get mutatingwebhookconfigurations pod-identity-webhook -o yaml

# 파드 생성 yaml에 없던 내용이 추가됨!!!!!
# Pod Identity Webhook은 mutating webhook을 통해 아래 Env 내용과 1개의 볼륨을 추가함
kubectl get pod eks-iam-test3
kubectl get pod eks-iam-test3 -o yaml
...
    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
...

kubectl exec -it eks-iam-test3 -- ls /var/run/secrets/eks.amazonaws.com/serviceaccount
token

kubectl exec -it eks-iam-test3 -- cat /var/run/secrets/eks.amazonaws.com/serviceaccount/token ; echo
...

kubectl describe pod eks-iam-test3
...
Environment:
      AWS_STS_REGIONAL_ENDPOINTS:   regional
      AWS_DEFAULT_REGION:           ap-northeast-2
      AWS_REGION:                   ap-northeast-2
      AWS_ROLE_ARN:                 arn:aws:iam::911283464785:role/eksctl-myeks-addon-iamserviceaccount-default-Role1-GE2DZKJYWCEN
      AWS_WEB_IDENTITY_TOKEN_FILE:  /var/run/secrets/eks.amazonaws.com/serviceaccount/token
    Mounts:
      /var/run/secrets/eks.amazonaws.com/serviceaccount from aws-iam-token (ro)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-69rh8 (ro)
...
Volumes:
  aws-iam-token:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  86400
  kube-api-access-sn467:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
...

# 파드에서 aws cli 사용 확인
eksctl get iamserviceaccount --cluster $CLUSTER_NAME
kubectl exec -it eks-iam-test3 -- aws sts get-caller-identity --query Arn
"arn:aws:sts::911283464785:assumed-role/eksctl-myeks-addon-iamserviceaccount-default-Role1-GE2DZKJYWCEN/botocore-session-1685179271"
  • 파드가 AWS STS를 통해 IRSA에 연동된 IAM 역할을 정상적으로 Assume(가정)하여 임시 자격 증명을 획득했음을 확인

2.4 IRSA를 통한 AWS 서비스 접근 테스트

# 되는 것고 안되는 것은 왜그런가?
kubectl exec -it eks-iam-test3 -- aws s3 ls
kubectl exec -it eks-iam-test3 -- aws ec2 describe-instances --region ap-northeast-2
kubectl exec -it eks-iam-test3 -- aws ec2 describe-vpcs --region ap-northeast-2
  • AmazonS3ReadOnlyAccess 정책만 부여했으므로, EC2 서비스 조회는 Access Denied 오류 발생

2.5 EKS Pod Identity Webhook 확인

# 파드에 볼륨 마운트 2개 확인
kubectl get pod eks-iam-test3 -o json | jq -r '.spec.containers | .[].volumeMounts'
[
  {
    "mountPath": "/var/run/secrets/kubernetes.io/serviceaccount",
    "name": "kube-api-access-sn467",
    "readOnly": true
  },
  {
    "mountPath": "/var/run/secrets/eks.amazonaws.com/serviceaccount",
    "name": "aws-iam-token",
    "readOnly": true
  }
]

# aws-iam-token 볼륨 정보 확인 : JWT 토큰이 담겨져있고, exp, aud 속성이 추가되어 있음
kubectl get pod eks-iam-test3 -o json | jq -r '.spec.volumes[] | select(.name=="aws-iam-token")'
{
  "name": "aws-iam-token",
  "projected": {
    "defaultMode": 420,
    "sources": [
      {
        "serviceAccountToken": {
          "audience": "sts.amazonaws.com",
          "expirationSeconds": 86400,
          "path": "token"
        }
      }
    ]
  }
}

#
kubectl get MutatingWebhookConfiguration
NAME                            WEBHOOKS   AGE
pod-identity-webhook            1          147m
vpc-resource-mutating-webhook   1          147m

# pod-identity-webhook 확인
kubectl describe MutatingWebhookConfiguration pod-identity-webhook 
kubectl get MutatingWebhookConfiguration pod-identity-webhook -o yaml
...
 name: iam-for-pods.amazonaws.com
# iam-for-pods.amazonaws.com은 AWS EKS에서 Pod Identity Webhook의 Mutating Webhook으로, 다음과 같은 작업을 수행합니다:
# Pod 생성 시 호출되어 ServiceAccount의 IAM 역할 정보를 확인.
# Pod에 환경 변수(AWS_ROLE_ARN, AWS_WEB_IDENTITY_TOKEN_FILE)와 토큰 볼륨을 주입.
# Pod이 AWS 리소스에 안전하고 세밀하게 접근할 수 있도록 인증 메커니즘 제공.

2.6 AWS CloudTrail 이벤트 확인

IAM 역할이 AWS STS를 통해 AssumeRoleWithWebIdentity 요청을 수행하면 CloudTrail에 이벤트가 기록됩니다.

2.7 OIDC Identity Provider 및 JWT 검증

Provider 정보

# AWS_WEB_IDENTITY_TOKEN_FILE 확인
IAM_TOKEN=$(kubectl exec -it eks-iam-test3 -- cat /var/run/secrets/eks.amazonaws.com/serviceaccount/token)
echo $IAM_TOKEN

# JWT 웹 확인 (https://jwt.io/)
{
  "aud": [
    "sts.amazonaws.com"
  ],
  "exp": 1685175662,
  "iat": 1685089262,
  "iss": "https://oidc.eks.ap-northeast-2.amazonaws.com/id/F6A7523462E8E6CDADEE5D41DF2E71F6",
  "kubernetes.io": {
    "namespace": "default",
    "pod": {
      "name": "eks-iam-test3",
      "uid": "73f66936-4d66-477a-b32b-853f7a1c22d9"
    },
    "serviceaccount": {
      "name": "my-sa",
      "uid": "3b31aa85-2718-45ed-8c1c-75ed012c1a68"
    }
  },
  "nbf": 1685089262,
  "sub": "system:serviceaccount:default:my-sa"
}

# env 변수 확인
kubectl get pod eks-iam-test3 -o json | jq -r '.spec.containers | .[].env'
[
  {
    "name": "AWS_STS_REGIONAL_ENDPOINTS",
    "value": "regional"
  },
  {
    "name": "AWS_DEFAULT_REGION",
    "value": "ap-northeast-2"
  },
  {
    "name": "AWS_REGION",
    "value": "ap-northeast-2"
  },
  {
    "name": "AWS_ROLE_ARN",
    "value": "arn:aws:iam::911283464785:role/eksctl-myeks-addon-iamserviceaccount-default-Role1-1MJUYW59O6QGH"
  },
  {
    "name": "AWS_WEB_IDENTITY_TOKEN_FILE",
    "value": "/var/run/secrets/eks.amazonaws.com/serviceaccount/token"
  }
]

# Let’s take a look at this endpoint. We can use the aws eks describe-cluster command to get the OIDC Provider URL.
IDP=$(aws eks describe-cluster --name myeks --query cluster.identity.oidc.issuer --output text)

# Reach the Discovery Endpoint
curl -s $IDP/.well-known/openid-configuration | jq -r '.'

# In the above output, you can see the jwks (JSON Web Key set) field, which contains the set of keys containing the public keys used to verify JWT (JSON Web Token). 
# Refer to the documentation to get details about the JWKS properties.
curl -s $IDP/keys | jq -r '.'
  • OIDC Provider에서 발급한 JWT 토큰을 AWS STS에서 검증할 때 사용하는 설정 정보가 출력됨
  • JWT 서명 검증에 필요한 공개 키 세트(Public Key Set)를 확인할 수 있음

2.8 IRSA의 문제점

Trust Policy에서 Principal을 와일드카드(*)로 설정하면, 모든 주체(Principal)가 해당 IAM Role을 Assume(가정)할 수 있는 권한을 가지게 됩니다.
이는 의도하지 않은 주체가 IAM Role을 획득하여 사용할 수 있는 보안 취약점으로 이어질 수 있으며, 역할 기반 접근 제어(RBAC) 및 최소 권한 원칙(Principle of Least Privilege)에 위배됩니다.

https://github.com/awskrug/security-group/blob/main/files/AWSKRUG_2024_02_EKS_ROLE_MANAGEMENT.pdf

2.9 실습 정리 및 IRSA 제거

# 실습 확인 후 파드 삭제 및 IRSA 제거
kubectl delete pod eks-iam-test3
eksctl delete iamserviceaccount --cluster $CLUSTER_NAME --name my-sa --namespace default
eksctl get iamserviceaccount --cluster $CLUSTER_NAME
kubectl get sa

3. EKS Pod Identity

3.1 기존 IAM 인증 방식(IRSA)와 문제점

Amazon EKS에서 Pod가 AWS 리소스에 접근하기 위해 기존에는 IAM Roles for Service Accounts(IRSA)를 활용했습니다. 그러나 IRSA에는 여러 가지 불편한 점이 있었습니다.

  1. 권한 부여의 복잡성

    • IRSA를 사용하려면 OpenID Connect (OIDC) Identity Provider를 설정해야 했습니다.
    • 클러스터별로 IAM 역할을 개별적으로 생성하고, 역할의 신뢰 정책(Trust Policy)을 관리해야 했습니다.
    • 클러스터 버전 업그레이드 시 새로운 OIDC Provider를 생성해야 했으며, 기존 역할의 신뢰 정책을 업데이트해야 했습니다.

  2. 보안 문제

    • IAM 역할의 신뢰 정책에서 *(와일드카드)를 사용하는 경우가 많았으며, 이는 보안 취약점을 초래할 가능성이 있었습니다.
    • 신뢰 정책을 잘못 설정하면, 의도치 않은 주체가 해당 역할을 Assume할 수 있는 보안 위험이 존재했습니다.

  3. 확장성 제한

    • AWS 계정당 IAM OIDC Provider는 최대 100개까지 생성 가능하므로, 클러스터가 많아질 경우 확장성 문제가 발생할 수 있었습니다.
    • IAM 역할 신뢰 정책의 길이 제한(2048자)으로 인해 하나의 역할에 여러 클러스터를 추가하는 것이 어려웠습니다.

3.2 새로운 IAM 인증 방식: EKS Pod Identity

AWS는 기존 IRSA의 단점을 개선하기 위해 EKS Pod Identity를 출시했습니다. EKS Pod Identity는 AWS에서 직접 IAM 인증을 처리하며, 새로운 EKS Pod Identity Agent를 활용하여 IAM 역할을 Pod에 자동으로 할당합니다.

주요 개선점

기존 방식(IRSA)개선 방식(EKS Pod Identity)
OIDC Provider 설정 필요OIDC Provider 설정 불필요
IAM 역할 신뢰 정책(Trust Policy) 관리 필요Trust Policy를 EKS 서비스에서 자동 관리
클러스터별로 개별적으로 역할 설정IAM 역할을 한 번만 설정하면 여러 클러스터에서 사용 가능
확장성 문제(OIDC Provider 100개 제한)확장성 문제 없음
IAM 신뢰 정책 길이 제한(2048자)신뢰 정책을 개별적으로 정의할 필요 없음
역할을 변경하려면 서비스 계정의 Annotation을 수정해야 함Pod Identity Association을 통해 간단하게 변경 가능

동작 방식

  • EKS Pod Identity는 기존의 OIDC Provider를 제거하고, 대신 EKS 서비스 자체에서 IAM 역할을 관리합니다.
  • 이를 위해 EKS Pod Identity Agent(데몬셋)를 클러스터에 추가하여 IAM 인증을 수행합니다.
  • Pod가 AWS 리소스에 접근할 때, Pod Identity Agent를 통해 IAM 인증이 수행되며, 이를 통해 AWS STS에서 임시 자격 증명을 발급받습니다.

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

3.3 EKS Pod Identity 구성 및 설정

3.3.1 EKS Pod Identity Agent 설치

Pod Identity를 사용하려면 클러스터에 EKS Pod Identity Agent를 설치해야 합니다.

#
ADDON=eks-pod-identity-agent
aws eks describe-addon-versions \
    --addon-name $ADDON \
    --kubernetes-version 1.31 \
    --query "addons[].addonVersions[].[addonVersion, compatibilities[].defaultVersion]" \
    --output text
v1.2.0-eksbuild.1
True
v1.1.0-eksbuild.1
False
v1.0.0-eksbuild.1
False

# 모니터링
watch -d kubectl get pod -A

# 설치
aws eks create-addon --cluster-name $CLUSTER_NAME --addon-name eks-pod-identity-agent
혹은
eksctl create addon --cluster $CLUSTER_NAME --name eks-pod-identity-agent --version 1.3.5

# 확인
eksctl get addon --cluster $CLUSTER_NAME
kubectl -n kube-system get daemonset eks-pod-identity-agent
kubectl -n kube-system get pods -l app.kubernetes.io/name=eks-pod-identity-agent
kubectl get ds -n kube-system eks-pod-identity-agent -o yaml
...
      containers: 
      - args: 
        - --port
        - "80"
        - --cluster-name
        - myeks
        - --probe-port
        - "2703"
        command: 
        - /go-runner
        - /eks-pod-identity-agent
        - server
      ....
      ports: 
        - containerPort: 80
          name: proxy
          protocol: TCP
        - containerPort: 2703
          name: probes-port
          protocol: TCP
      ...
        securityContext: 
          capabilities: 
            add: 
            - CAP_NET_BIND_SERVICE
      ...
      hostNetwork: true
...

# 네트워크 정보 확인
## EKS Pod Identity Agent uses the hostNetwork of the node and it uses port 80 and port 2703 on a link-local address on the node. 
## This address is 169.254.170.23 for IPv4 and [fd00:ec2::23] for IPv6 clusters.
for node in $N1 $N2 $N3; do ssh ec2-user@$node sudo ss -tnlp | grep eks-pod-identit; echo "-----";done
for node in $N1 $N2 $N3; do ssh ec2-user@$node sudo ip -c route; done
for node in $N1 $N2 $N3; do ssh ec2-user@$node sudo ip -c -br -4 addr; done
for node in $N1 $N2 $N3; do ssh ec2-user@$node sudo ip -c addr; done

=> hostNetwork 사용

3.3.2 Pod Identity Association 생성

Pod Identity를 활용하려면 Pod Identity Association을 생성해야 합니다.

# 
eksctl create podidentityassociation \
--cluster $CLUSTER_NAME \
--namespace default \
--service-account-name s3-sa \
--role-name s3-eks-pod-identity-role \
--permission-policy-arns arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
--region ap-northeast-2

# 확인
kubectl get sa
eksctl get podidentityassociation --cluster $CLUSTER_NAME
ASSOCIATION ARN											                                                      NAMESPACE	SERVICE ACCOUNT NAME	IAM ROLE ARN
arn:aws:eks:ap-northeast-2:911283464785:podidentityassociation/myeks/a-blaanudo8dc1dbddw	default		s3-sa			            arn:aws:iam::911283464785:role/s3-eks-pod-identity-role

aws eks list-pod-identity-associations --cluster-name $CLUSTER_NAME | jq
{
  "associations": [
    {
      "clusterName": "myeks",
      "namespace": "default",
      "serviceAccount": "s3-sa",
      "associationArn": "arn:aws:eks:ap-northeast-2:911283464785:podidentityassociation/myeks/a-pm07a3bg79bqa3p24",
      "associationId": "a-pm07a3bg79bqa3p24"
    }
  ]
}

# ABAC 지원을 위해 sts:Tagsession 추가
aws iam get-role --query 'Role.AssumeRolePolicyDocument' --role-name s3-eks-pod-identity-role | jq .
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "pods.eks.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ]
    }
  ]
}

3.3.3 IAM 역할의 신뢰 정책(Trust Policy) 확인

IAM 콘솔에서 s3-eks-pod-identity-role의 신뢰 정책을 확인하면, pods.eks.amazonaws.com을 신뢰하는 구조로 설정됩니다.

3.3.4 EKS Pod Identity를 사용하는 Pod 실행

s3-sa 서비스 계정을 사용하는 Pod를 생성하여 IAM 역할이 정상적으로 적용되는지 확인합니다.

# 서비스어카운트, 파드 생성
kubectl create sa s3-sa

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: eks-pod-identity
spec:
  serviceAccountName: s3-sa
  containers:
    - name: my-aws-cli
      image: amazon/aws-cli:latest
      command: ['sleep', '36000']
  restartPolicy: Never
  terminationGracePeriodSeconds: 0
EOF

3.3.5 IAM 인증 확인

Pod 내부에서 aws sts get-caller-identity 명령을 실행하여 EKS Pod Identity를 통해 올바른 IAM 역할이 적용되었는지 확인할 수 있습니다.

#
kubectl get pod eks-pod-identity -o yaml | kubectl neat
kubectl exec -it eks-pod-identity -- aws sts get-caller-identity --query Arn

3.3.6 AWS 리소스 접근 확인

AmazonS3ReadOnlyAccess 정책을 부여했으므로, aws s3 ls 명령을 실행하여 S3 버킷 리스트를 조회할 수 있습니다.

kubectl exec -it eks-pod-identity -- aws s3 ls

3.3.7 사용된 환경 변수 확인

Pod 내부에서 IAM 인증 관련 환경 변수를 확인하면 AWS_CONTAINER_CREDENTIALS_FULL_URI가 설정되어 있음을 확인할 수 있습니다.

kubectl exec -it eks-pod-identity -- env | grep AWS
AWS_STS_REGIONAL_ENDPOINTS=regional
AWS_DEFAULT_REGION=ap-northeast-2
AWS_REGION=ap-northeast-2
AWS_CONTAINER_CREDENTIALS_FULL_URI=http://169.254.170.23/v1/credentials
AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE=/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token

# 토큰 정보 확인
kubectl exec -it eks-pod-identity -- ls /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/
kubectl exec -it eks-pod-identity -- cat /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token

3.3.8 실습 리소스 삭제

eksctl delete podidentityassociation --cluster $CLUSTER_NAME --namespace default --service-account-name s3-sa
kubectl delete pod eks-pod-identity
kubectl delete sa s3-sa

profile
주영
이전 포스트

[AWS EKS] EKS Security 5 - EKS 인증/인가

다음 포스트

[AWS EKS] EKS Security 7 - Kyverno

0개의 댓글