티스토리 뷰
AWS EKS 인증방식 완전 정복
안녕하세요, DevOps분들이AWS EKS(Elastic Kubernetes Service)를 도입을 하실때 사용하는 인증(Authentication) 방식에 대해 하나씩 정리해드릴게요. 이번 글에서는 'AWS가 제공하는 인증 방식'를 먼저 다루고, 이어지는 시리즈에서 보안 이슈와 대안에 대해서도 알려드릴 예정입니다.
1. AWS EKS가 제공하는 인증 방식이란?
Kubernetes는 기본적으로 클러스터에 접근할 때 인증(Authentication) 과정을 거칩니다. AWS EKS는 이 과정을 위해 IAM과 통합된 특별한 인증 방법을 제공을 하며, EKS 클러스터는 크게 아래 2가지 인증 방식을 지원합니다.
- EKS API Only
- EKS API Only + ConfigMap
2가지 방식을 지원을 하며 하나하나 내용을 확인해보겠습니다.
1.1 aws-auth
ConfigMap 방식
이 방식은 EKS 클러스터가 IAM 사용자 또는 역할(IAM Role)이 클러스터에 접근할 수 있도록 허용하는 방법입니다.
- EKS는
aws-auth
라는 Kubernetes ConfigMap을 통해 IAM과 Kubernetes 사용자 간의 매핑 정보를 유지합니다. - 이 ConfigMap은
kube-system
네임스페이스에 위치하며, 여기에 접근을 허용할 IAM Role 또는 사용자 정보를 추가해야만 클러스터에 접근 가능합니다.
예시:
mapRoles:
- rolearn: arn:aws:iam::123456789012:role/EKSNodeInstanceRole
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
장점:
- IAM 역할 기반으로 통제하므로 익숙한 AWS 환경과 잘 통합됨
- EC2 인스턴스(노드)나 사용자를 세밀하게 제어 가능
단점:
- 이 ConfigMap을 수동으로 관리해야 해서 실수나 권한 노출 위험이 있음
1.2 EKS API Only 인증 모드 (Managed 인증)
AWS는 EKS API Only
인증 모드를 제공하여 aws-auth
없이도 자동으로 인증을 처리할 수 있게 했습니다.
- Managed Node Group을 사용할 경우, 해당 노드는 자동으로 인증되어 클러스터에 등록됩니다.
- 이때 IAM Role이 자동으로 인식되어 ConfigMap 설정이 없어도 정상 작동합니다.
장점:
- ConfigMap 없이 인증 처리 가능 → 설정 편리함
- 관리형 서비스에 적합한 자동화된 방식
- ConfigMap 노출로 인한 권한 오남용 위험 없음
- IAM Role 기반 자동 인증이므로 인프라 보안 정책과 연계가 쉬움
- 인증 흐름이 명확하게 정의되어 있고, AWS의 IAM 정책과 직접 연결되어 있어 보안 설정 일관성이 높음
- IAM 기반 정책만으로 인증 및 권한 부여 가능 → 보안 감사 및 정책 통제 용이
단점:
- 노드별 세부 제어나 사용자 맞춤 권한 부여가 어려움
- 감사 추적이나 RBAC을 잘 연동하지 않으면 보안 측면에서 다소 불리할 수 있음
- 단, 한 번 클러스터 생성 시 선택한 인증 방식은 변경이 불가능하므로 주의가 필요합니다.
EKS API Only 모드에서 사용하는 IAM 정책
EKS API Only 모드를 사용할 경우, 인증과 권한 부여는 전적으로 IAM 정책을 기반으로 이루어집니다. 이때 노드 그룹이나 사용자가 클러스터에 접근하거나 인증되기 위해서는 필수 IAM 권한이 사전에 할당되어야 합니다.
대표적인 IAM 정책: AmazonEKSClusterAdminPolicy
이 정책은 EKS Cluster에 대한 모든 권한을 가지는 정책으로 최상위 권한이라고 생각을 하시면됩니다.
이외에도 AmazonEKSAdminPolicy, AmazonEKSAdminViewPolicy 등 다양한 권한을 제공을 하고 있으며 EKS API Only에 대한 상세 권한을 아래 참고 링크를 참고 부탁드립니다.
참고 링크
IAM과의 통합: 인증 흐름은 어떻게 될까?
kubectl
명령 실행 시 IAM 자격 증명을 사용하여 AWS CLI가 인증 토큰을 발급합니다.- 이 토큰이 EKS 클러스터에 전달되어, AWS IAM과 연결된 권한이 있는지 검사합니다.
- EKS는
aws-auth
ConfigMap이나 EKS API 설정을 확인해 해당 요청을 허용하거나 거부합니다.
이 구조 덕분에 AWS EKS는 IAM과 Kubernetes의 장점을 동시에 사용할 수 있어요!
EKS API Only + Configmap vs EKS API Only 요약: 인증 방식 비교 정리
항목 | EKS API Only + Configmap 방식 | EKS API Only 모드 (Managed 인증) |
관리 방식 | ConfigMap 수동 관리 필요 | 자동 인증 (ConfigMap 불필요) |
유연성 | IAM 사용자/역할 ↔ Kubernetes 유저 매핑 가능 | 자동화 중심, 노드 중심 인증 |
권한 제어 | RBAC과 연계 시 세분화된 권한 제어 가능 | IAM 정책 기반이지만 RBAC 연동은 제한적 |
보안 측면 | ConfigMap 실수로 인한 권한 노출 위험 존재 | IAM 정책 기반 → 권한 오남용 위험 감소, 감사에 유리 |
설정 변경 가능 여부 | 수시 수정 가능 | 클러스터 생성 시 설정 후 변경 불가 |
적합 대상 | 고급 사용자, 세밀한 제어가 필요한 환경 | 초급 사용자, 관리형 노드 기반 자동화 환경 |
추천 방식
- 초보자 또는 관리형 노드(MNG) 중심 환경에서는
EKS API Only 모드
로 시작해보세요.- 운영 환경에서 사용자별 권한 제어(RBAC)가 필요한 경우에는
aws-auth + RBAC
조합이 효과적입니다.
다음 글에서는 ConfigMap 보안 이슈와 RBAC과의 연동 방식에 대해 더 깊이 알아보겠습니다. 계속해서 따라와 주세요
- Total
- Today
- Yesterday