1. K8S / EKS IAM 기초 지식

개요

• Kubernetes는 API 중심 구조임
• 모든 요청은 API Server를 통해 처리됨
• 전체 흐름은 Authentication → Authorization → Admission Control → etcd 저장 순서임

Kubernetes 인증/인가 기본

• Authentication은 요청 주체의 신원을 확인하는 단계임
• Authorization은 인증된 주체의 권한을 확인하는 단계임
• Admission Control은 인가 이후 요청을 검증하거나 변경하는 단계임
• Auditing은 요청 이력을 기록하는 단계임

인증 방식

• X.509 인증서
• Bearer Token
• OIDC
• Webhook 인증

인가 방식

방식	특징
RBAC	Kubernetes 표준 권한 모델
Node	kubelet/노드 전용 인가
Webhook	외부 시스템에 인가 위임
ABAC	비권장

RBAC 핵심

• Role은 리소스와 verbs 조합으로 권한을 정의함
• RoleBinding은 사용자, 그룹, 서비스어카운트를 Role에 연결함
• ClusterRole / ClusterRoleBinding은 클러스터 범위 권한에 사용함

Verb	의미
get	조회
list	목록 조회
watch	변경 감시
create	생성
update	수정
patch	일부 수정
delete	삭제
deletecollection	여러 리소스 삭제

---

EKS 인증/인가 흐름

전체 흐름

1. aws eks get-token 으로 인증 토큰 생성
2. kubectl이 Bearer Token을 포함해 EKS API Server 호출
3. kube-apiserver가 TokenReview로 인증 수행
4. 인증 Webhook이 토큰 내부의 Pre-signed URL 추출
5. AWS STS GetCallerIdentity 호출로 서명 검증
6. IAM 주체를 Kubernetes subject로 매핑
7. 인가 수행 후 실제 API 요청 실행

토큰 구조

항목	내용
Prefix	k8s-aws-v1
본문	Base64 인코딩 문자열
실제 의미	STS GetCallerIdentity용 Pre-signed URL
만료	짧은 수명

• 이 토큰은 단순 세션 토큰이 아니라 이미 서명된 AWS 요청임

SigV4 핵심

• Secret Access Key는 직접 전송되지 않음
• SigV4로 서명된 요청만 전달됨
• 날짜/리전/서비스에 종속된 키로 서명함
• AWS STS가 동일 계산으로 검증함

SecretKey → DateKey → RegionKey → ServiceKey → SigningKey → Signature

인증 결과

• username: IAM ARN

• groups: system:authenticated

• extra: principalId, arn, accessKeyId 등

• EKS 생성 principal은 내부적으로 높은 권한을 가질 수 있음

• 하지만 응답에 그 권한이 항상 그대로 노출되는 것은 아님

인가 방식 비교

항목	Access Entry (EKS API)	aws-auth ConfigMap
저장 위치	AWS 관리형 API	Kubernetes ConfigMap
관리 방식	AWS API/콘솔	YAML 직접 수정
인가 처리	Access Policy + Webhook 가능	RBAC 중심
상태	권장	deprecated

인가 동작

• Access Entry 방식은 AWS가 관리형으로 IAM 주체를 매핑하고 Access Policy로 인가 가능함
• aws-auth 방식은 IAM 주체를 K8S 그룹으로 매핑한 뒤 RBAC으로 최종 인가함
• EKS API 방식은 AWS Webhook 인가까지 포함하는 구조임
• 정책이 없으면 RBAC fallback 구조로 이해하면 됨

노드 인증/인가

• 워커 노드는 보통 system:nodes, system:bootstrappers 그룹과 연결됨
• eks:node-bootstrapper 권한과 연계됨
• 일부 동작은 단순 RBAC이 아니라 Node Authorizer / Node Restriction 맥락도 함께 봐야 함

운영 리스크

• aws-auth ConfigMap 잘못 수정 시 클러스터 장애 발생 가능
• 대표 사례: system:nodes 제거 → 전체 노드 NotReady

kubeconfig 이해

• clusters: API 서버 정보

• users: 인증 정보

• contexts: cluster + user 조합

• EKS에서는 kubeconfig에 exec: aws eks get-token 구조가 들어감

ServiceAccount Token Projection

• 기존 secret 기반 토큰은 만료 제어와 audience 지정 측면에서 한계가 있음
• projected volume / bound token 방식이 권장됨

구성	역할
serviceAccountToken	인증 토큰
configMap	CA 번들
downwardAPI	namespace 등 메타데이터

Admission Control

• 인증/인가 이후 최종 정책 단계임
• MutatingWebhook은 요청 내용을 변경함
• ValidatingWebhook은 요청을 허용/차단함

유형	역할
MutatingWebhook	요청 수정
ValidatingWebhook	요청 검증 및 차단

IRSA

• Pod 단위 IAM 권한 부여 방식임
• ServiceAccount와 IAM Role을 연결해 임시 자격 증명을 사용함
• Node IAM Role 대비 최소 권한 구현에 적합함

2. 실습

K8S 인증/인가 기초 실습

네임스페이스와 서비스 어카운트 생성 후 확인

• 파드 기동 시 서비스 어카운트 한 개가 할당되며, 서비스 어카운트 기반 인증/인가를 함, 미지정 시 기본 서비스 어카운트가 할당

• 서비스 어카운트에 자동 생성된 시크릿에 저장된 토큰으로 쿠버네티스 API에 대한 인증 정보로 사용 할 수 있다 ← 1.23 이전 버전의 경우에만 해당

# 네임스페이스(Namespace, NS) 생성 및 확인
kubectl create namespace dev-team
kubectl create ns infra-team

# 네임스페이스 확인
kubectl get ns

# 네임스페이스에 각각 서비스 어카운트 생성 : serviceaccounts 약자(=sa)
kubectl create sa dev-k8s -n dev-team
kubectl create sa infra-k8s -n infra-team

# 서비스 어카운트 정보 확인
kubectl get sa -n dev-team
kubectl get sa dev-k8s -n dev-team -o yaml

kubectl get sa -n infra-team
kubectl get sa infra-k8s -n infra-team -o yaml

서비스 어카운트를 지정하여 파드 생성 후 권한 테스트

• 각 네임스페이스에 kubectl 실행용 Pod를 생성하고, 서로 다른 ServiceAccount를 연결

• 이후 Pod 내부에 자동 주입된 서비스어카운트 토큰, 네임스페이스 정보, CA 인증서를 확인

• kubectl exec를 이용해 Pod 내부에서 직접 kubectl 명령을 실행하며 권한을 테스트

• 마지막으로 kubectl auth can-i 명령으로 해당 ServiceAccount가 실제로 어떤 권한을 가지는지 검증

각각 네임스페이스에 롤(Role)를 생성 후 서비스 어카운트 바인딩

• kubectl api-resources로 클러스터에서 제공하는 리소스와 API 그룹을 먼저 확인
• 이후 각 네임스페이스에 모든 리소스와 모든 동작을 허용하는 Role을 생성
• Role은 어떤 리소스에 어떤 작업을 허용할지 정의하는 권한 객체
• RoleBinding은 해당 Role을 각 ServiceAccount에 연결하는 객체
• 최종적으로 dev-k8s, infra-k8s가 각 네임스페이스 내 권한을 가지도록 매핑하는 과정

서비스 어카운트를 지정하여 생성한 파드에서 다시 권한 테스트

• alias를 사용해 각 Pod 내부에서 kubectl 명령을 바로 실행할 수 있도록 단축 명령 구성
• 각 ServiceAccount 권한으로 Pod 조회, 생성, 삭제 명령 실행
• kube-system 네임스페이스 조회와 nodes 조회를 통해 네임스페이스 범위를 넘는 접근 가능 여부 확인
• -v=6 옵션으로 실제 API 요청 흐름과 상세 로그 확인
• kubectl auth can-i get pods 결과를 통해 현재 ServiceAccount 권한 정상 반영 확인

리소스 삭제

K8S(EKS) Pod(SA) with IAM Role

파드에 서비스 어카운트 없이 생성해보기

• automountServiceAccountToken: false 옵션으로 Pod에 Kubernetes 서비스어카운트 토큰을 주입하지 않고 실행
• 이 방식은 Pod가 Kubernetes API를 호출할 필요가 없는 경우 불필요한 인증 정보 노출을 줄이기 위한 설정
• 예제에서는 aws-cli 컨테이너로 s3 ls를 수행하지만, IRSA나 별도 AWS 자격 증명이 없으므로 정상 접근 불가
• CloudTrail에서는 ListBuckets 호출 주체가 Pod용 IAM Role이 아닌 Node IAM Role(AssumedRole) 로 기록되고, 결과는 AccessDenied 확인
• 즉 이 실습은 서비스어카운트 토큰 미주입 상태에서는 Pod가 Kubernetes 신원이나 IRSA 기반 자격 증명을 사용하지 못함을 확인하는 과정

기본 Kubernetes API 접근용 ServiceAccount 첫번째 토큰 확인

• Kubernetes 1.12부터 ProjectedServiceAccountToken 기능이 도입되며, Pod에는 기존 secret 기반 토큰 대신 OIDC 형식의 JWT 서비스어카운트 토큰이 마운트
• 이 토큰에는 iss, aud, exp, sub 같은 표준 클레임과 Pod, Namespace, ServiceAccount 정보가 포함되며, 대상 제한과 만료 시간을 가지는 점이 핵심
• EKS에서는 이 기능이 기본 활성화 상태이며, Pod 내부 /var/run/secrets/kubernetes.io/serviceaccount/token 경로에서 해당 토큰 확인 가능
• 다만 이 토큰만으로 바로 AWS API를 호출하는 것은 아니고, AWS의 Pod Identity Webhook이 Pod 생성 시 필요한 환경변수와 토큰 구성을 주입해 IRSA 사용 기반 제공
• 결과적으로 이 단계는 Kubernetes OIDC 토큰이 IRSA의 출발점이며, 이후 STS를 통해 AWS 임시 자격 증명으로 교환되는 구조 확인 목적

IRSA 설정 및 SA 두번째 토큰 확인

목표 1 : AWS LBC Helm 설치 시, IRSA로 LBC 파드에만 필요한 권한(ALB/NLB 제어 등)을 부여해보자!

• IRSA 설정

1. Amazon EKS 클러스터용 IAM OIDC 공급자 등록(생성) → 이미 설정되어 있음

2. Kubernetes 서비스 계정이 IAM 역할을 통해 사용할 IAM Policy 생성

3. Pod가 Kubernetes 서비스 계정을 사용하도록 구성합니다 : IAM Role 생성, K8S SA 생성, K8S SA Annonation 추가

• AWS LBC 설치 : 현재 Node IAM Role에 ELB 권한 없는 상태

• 상세 확인 : Pod Spec 주입 확인, aud 가 aws sts 확인

• (AWS LBC 동작 확인) kube-ops-view 배포 + ALB Ingress(MyDomain, HTTPS → HTTP)

목표 2 : AWS S3 읽기 전용 권한이 필요한 파드에 IRSA 설정

• 이 Role에는 S3 읽기 전용 정책만 붙음
  • aws s3 ls → 성공 (S3 ReadOnly 권한에 포함)
  • aws ec2 describe-instances → 실패 (EC2 권한 없음)
  • aws ec2 describe-vpcs → 실패 (EC2 권한 없음)

pod-identity-agent 설치 확인 : 노드 네트워크 정보 확인

eksctl 로 podidentityassociation 설정 : IAM Role 생성, K8S SA 생성

테스트용 파드 생성 및 AWS 사용 확인 : AssumeRoleForPodIdentity

심층 확인

• 파드 생성 → EKS가 JWT 토큰 마운트 → 파드(또는 SDK)가 169.254.170.23에 토큰 전달
  → Pod Identity Agent가 STS 임시 자격증명 반환 → 파드가 AWS API 호출
  → CloudTrail에 AssumeRoleForPodIdentity 이벤트 기록

실습 환경 삭제

# kube-ops-view Ingress 삭제 (ALB 제거)
kubectl delete ingress -n kube-system kubeopsview
kubectl get ingress -n kube-system

# IRSA 설정 삭제
CLUSTER_NAME=myeks
eksctl delete iamserviceaccount --cluster=$CLUSTER_NAME --namespace=kube-system --name=aws-load-balancer-controller
eksctl get iamserviceaccount --cluster $CLUSTER_NAME

# 테라폼으로 생성된 리소스 삭제
terraform destroy -auto-approve
rm -rf ~/.kube/config

3. 더 알아보기

IRSA 동작 과정

IRSA는 Pod의 ServiceAccount 토큰을 OIDC 기반으로 AWS STS에 전달해, 특정 IAM Role의 임시 자격 증명을 받아 AWS 리소스에 접근하는 구조.

• Pod 생성 시 ServiceAccount에 연결된 IAM Role 정보가 MutatingWebhook을 통해 환경변수와 토큰 볼륨 형태로 주입
• 애플리케이션의 AWS SDK가 AWS_ROLE_ARN, AWS_WEB_IDENTITY_TOKEN_FILE 정보를 읽고 AssumeRoleWithWebIdentity 호출
• AWS IAM은 JWT의 iss, sub, aud, exp와 OIDC Provider, Trust Policy, JWKS 공개키를 기준으로 토큰 유효성 검증
• 검증 통과 시 AWS STS가 임시 자격 증명을 발급하고, Pod는 이 자격 증명으로 S3 같은 AWS 서비스 접근
• 실무에서는 하드코딩된 키 대신 Default Credential Provider와 IRSA 조합 사용

K8S(EKS) API 인증/인가 방식 비교 aws-auth ConfigMap vs EKS API Access Entry

항목	aws-auth ConfigMap	EKS API Access Entry
상태	deprecated	권장
저장 위치	Kubernetes 내부 ConfigMap / etcd	AWS EKS 관리형 API
권한 부여	IAM 주체 매핑 후 RBAC 필요	Access Policy 직접 연결 가능
운영 방식	YAML 직접 수정	AWS API / 콘솔 관리
리스크	오타·삭제 시 장애 가능	상대적으로 운영 안정성 높음

• 두 방식 모두 인증 자체는 TokenReview 기반이며, 차이는 IAM 주체를 Kubernetes 권한으로 연결하는 방식

IRSA vs EKS Pod Identity 비교

항목	IRSA	EKS Pod Identity
기본 원리	OIDC 웹 아이덴티티 토큰으로 AssumeRoleWithWebIdentity 호출	EKS Auth API와 Pod Identity Agent가 임시 자격 증명 전달
사전 구성	클러스터별 OIDC Provider 필요	OIDC Provider 불필요
핵심 구성요소	ServiceAccount, projected token, IAM trust policy, Pod Identity Webhook	ServiceAccount, Pod Identity association, Pod Identity Agent
IAM 신뢰 주체	클러스터별 OIDC provider	pods.eks.amazonaws.com 서비스 주체
확장성	클러스터 수만큼 trust policy 관리가 늘어남	여러 클러스터에서 같은 principal 재사용 쉬움

• IRSA는 ServiceAccount 토큰을 OIDC JWT로 발급하고, AWS SDK가 AssumeRoleWithWebIdentity를 호출해 임시 자격 증명을 받는 구조
• Pod Identity는 OIDC Provider 없이 동작하며, EKS Pod Identity Agent가 노드 단위로 자격 증명 전달을 담당해 설정과 운영이 더 단순한 편

EKS 인증/인가 2종 + 워크로드 AWS 권한 부여 2종 비교 ConfigMap Access Entry IRSA Pod Identity

구분	대상	목적	권한 대상	핵심 특징
aws-auth ConfigMap	사람 / IAM 주체	EKS API 접근	Kubernetes 리소스	구식 방식, RBAC 의존
Access Entry	사람 / IAM 주체	EKS API 접근	Kubernetes 리소스	관리형 정책 사용 가능
IRSA	Pod / ServiceAccount	AWS API 접근	AWS 리소스	OIDC 기반
Pod Identity	Pod / ServiceAccount	AWS API 접근	AWS 리소스	EKS 관리형, Agent 기반

Amazon EKS Pod Identity streamlines cross account access 정리

• AWS EKS Pod Identity association: 소스 역할과 타깃 역할을 함께 지정해, 교차 계정 접근을 더 단순화하는 기능
• 이전에는 리소스 정책 또는 IAM role chaining을 애플리케이션이나 IAM 구성에서 더 직접 다뤄야 했지만, 이제는 EKS Pod Identity가 이 과정을 더 많이 흡수
• 이 기능은 내부적으로 IAM role chaining을 사용해 Pod에 필요한 교차 계정 임시 자격 증명을 제공하며, 애플리케이션 코드 수정 없이 동작하는 점이 핵심
• 중앙 EKS 클러스터와 별도 데이터 계정 구조, CI/CD 계정 분리 구조, 데이터 API 계정 분리 구조 같은 멀티어카운트 환경에서 특히 유용

Simplifying IAM Permissions for Amazon EKS Addons with EKS Pod Identity 정리

• EKS add-on에도 Pod Identity association을 직접 연결할 수 있게 하여, 애드온 권한 관리 단계를 줄일 수 있음
• 핵심은 add-on API에 podIdentityAssociations 파라미터가 추가되어, 클러스터 생성 시점이나 이후 운영 단계에서 add-on 권한을 한 번에 설정 가능해진 점
• 이 방식은 add-on별 ServiceAccount에 서로 다른 IAM 권한을 부여할 수 있어 최소 권한 원칙 적용에 유리
• 네트워킹, 스토리지, 컴퓨트 계열 EKS add-on이 AWS API를 호출해야 하는 상황에서, 별도 수작업보다 관리 복잡도를 줄이는 효과 큼

Announcing ASCP integration with Pod Identity 정리

• ASCP와 Pod Identity 통합, EKS에서 Secrets Manager와 SSM Parameter Store 비밀 접근 구성을 더 단순화
• 보안 강화, 구성 단순화, 운영 편의성 개선