실제 EKS를 구축하고 나면, kubectl과 AWS CLI를 통해 클러스터를 관리하게 된다. 이때 AWS CLI를 사용하기 위해서는 aws configure 명령어로 IAM 자격 증명을 등록하고, 해당 자격 증명을 기반으로 EKS Cluster에 접근할 수 있다. 그러나 이때 팀원 모두가 Admin 권한 계정을 사용하고 있다면 아래와 같은 문제점이 발생할 수 있다.
- 팀원 전원이 Admin 권한을 가지고 있기에 보안상으로 좋지 않음.
- 관리 계정이 여러 개로 분산되어 있어 통합 관리가 어려움.
따라서 이러한 문제점을 해결하기 위해, 내가 실제로 구성해 본 방법을 공유해보려고 한다. 나는 아래 두 가지 원칙을 기준으로 EKS 운영 구조를 설계하였다.
1. 운영 계정 분리 및 최소 권한(Least Privilege) 적용
- EKS 전용 IAM 사용자 생성
- 콘솔 로그인은 불가능하도록 설정
- EKS 운영에 필요한 권한만 부여
2. Bastion 서버 기반 접근 제어 및 IP 제한
- IAM 정책에 Bastion 서버 Elastic IP를 명시
- 해당 서버 외의 환경에서는 접근 불가하도록 제한
여기서 주의할 점은, Bastion 서버의 퍼블릭 IP는 인스턴스를 중지 후 재시작할 때마다 변경되기 때문에, 반드시 Elastic IP를 할당해 고정된 IP로 운영해야 한다.
EKS 전용 운영 정책 생성
우선, Bastion 서버의 IP에서만 접근이 가능하도록 제한된 EKS 전용 IAM 정책을 생성할 것이다. 아래 정책에서 "aws:SourceIp"에는 Bastion 서버에 할당한 Elastic IP를 입력하면 된다.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "FullEKSFromBastionOnly",
"Effect": "Allow",
"Action": [
"eks:*",
"ec2:Describe*",
"iam:PassRole",
"iam:GetRole",
"iam:ListRoles",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogStreams",
"cloudformation:Describe*",
"autoscaling:Describe*"
],
"Resource": "*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "43.202.179.57/32" // ELP를 할당한 Bastion server의 퍼블릭 IP
}
}
}
]
}

사용자 생성
다음 단계로, 앞서 생성한 정책을 연결할 IAM 사용자를 생성한다. 해당 계정은 CLI에서만 사용할 예정이므로 콘솔 로그인 옵션은 비활성화한다.

사용자에 정책 연결
사용자 생성을 완료했다면, 앞에서 만든 EKS 전용 IAM 정책을 해당 사용자에게 연결한다.

액세스 키 발급
Bastion 서버에서 AWS CLI를 사용하기 위해 운영용 IAM 사용자 계정에 액세스 키를 발급한다. 해당 계정은 콘솔 로그인이 불가능하도록 설정했으므로, CLI 인증을 위해 액세스 키가 필요하다. 아래와 같이 Command Line Interface(CLI) 용도로 액세스 키를 생성한다.

Bastion 서버에서 액세스 키 등록
SSH로 Bastion 서버에 접속한 뒤 `aws configure` 명령어를 실행해 앞에서 발급한 액세스 키를 입력한다. 설정이 정상적으로 적용되었는지는 `aws sts get-caller-identity` 명령어를 통해 확인할 수 있다. 참고로, 나는 Bastion 서버 접속은 MobaXterm을 이용하였다.
aws sts get-caller-identity
{
"Account": "xxxxxx",
"UserId": "xxxxxx",
"Arn": "arn:aws:iam::xxxxxx:user/<운영용 IAM 계정>"
}
EKS 클러스터 연결 (kubeconfig 설정)
AWS CLI 자격 증명 설정이 완료되었으면, 이제 Bastion 서버에서 EKS 클러스터에 접근할 수 있도록 kubeconfig를 구성한다. 아래 명령어를 실행하면 해당 계정 정보가 kubeconfig 파일에 저장되어 kubectl을 통해 클러스터에 접근할 수 있게 된다.
aws eks update-kubeconfig --region ap-northeast-2 --name <클러스터명>
이렇게 해서 Bastion 서버에서만 접근 가능한 전용 IAM 계정을 통해 EKS를 안전하게 관리할 수 있는 환경 구성을 완료하였다. Admin 계정 사용을 줄이고 최소 권한 원칙을 적용함으로써, 보다 안전한 운영 환경을 구축할 수 있었다. 이후에도 이 계정을 사용해 EKS를 지속적으로 관리하고 운영하였다.
'Kubernetes' 카테고리의 다른 글
| VMware Fusion에 k3s 멀티 노드 클러스터 구축하기 (0) | 2026.05.02 |
|---|---|
| 디플로이먼트(Deployment) 스케일링과 업데이트의 동작방식 (0) | 2026.04.05 |
| 쿠버네티스의 Pod와 Deployment에 관하여 (0) | 2026.04.03 |
| Kubernetes Service는 왜 필요할까? (0) | 2026.01.06 |
| Ansible을 이용해 Kubernetes Cluster 구축해보기 (0) | 2025.12.25 |